IP Routing
https://www.ip-sa.pl/doc/dslam/maxtnt/netcfg/tntip.htm
IP Routing
Routing overview
When you power on or reset the MAX TNT, it creates an IP routing table containing all the routes it knows about, including the following:
- Routes for local active IP interfaces (configured IP-Interface profiles)
- Routes for active WAN IP connections (switched or nailed connections that are up)
- Routes for inactive switched WAN IP connections (configured Connection profiles)
- Routes defined in IP-Route profiles or RADIUS route profiles
If dynamic routing protocols are enabled on one or more interfaces, the MAX TNT adds routes it learns from routing update packets. In addition, it is continuously updating its routing table by adding routes for links that become active and removing routes for inactive connections. If a nailed connection goes down, the MAX TNT removes the route from its routing table.
Routes and interfaces
An IP route specifies a destination address, a router (gateway) to the network, and an interface that leads to the gateway. It can also specify metrics and other values associated with the route.
A route defined in a profile is a static route. A dynamic route is learned from Routing Information Protocol (RIP) or Open Shortest Path First (OSPF) updates sent by other routers. Dynamic updates provide access to many more routes than those actually configured in the MAX TNT, and are updated automatically as routes change. However, they cause additional routing overhead, so they are disabled by default.
An interface is a point of ingress or egress to the system. For example, a local interface is an Ethernet port and a WAN interface is a nailed or switched connection. An IP interface is the logical IP address that enables IP data to be sent and received.
Displaying the routing table
To view the routing table, use the Netstat command. For example:
admin> netstat
Destination Gateway IF Flg Pref Met Use Age
0.0.0.0/0 10.32.8.1 ie0 SGP 60 1 31460 1986
0.0.0.0/0 20.1.1.8 wan9 *SGP 60 8 0 0
10.4.5.0/24 10.4.5.6 wan12 SG 120 7 0 1978086
10.4.5.6/32 10.4.5.6 wan12 S 120 7 1 1978086
10.56.1.0/24 - ie0-1 C 0 0 0 4504466
10.56.1.1/32 - local CP 0 0 0 4504466
127.0.0.0/8 - bh0 CP 0 0 0 450446
127.0.0.1/32 - local CP 0 0 0 4504466
127.0.0.2/32 - rj0 CP 0 0 0 4504466
10.32.8.0/24 - ie0 C 0 0 7820 4504466
10.32.8.0/24 10.32.8.21 wan11 *SG 120 7 0 1978086
10.32.8.21/32 10.32.8.21 wan11 S 120 7 1 1978086
10.32.8.25/32 - local CP 0 0 47039 4504466
224.0.0.0/4 - mcast CP 0 0 0 4504466
224.0.0.1/32 - local CP 0 0 0 4504466
224.0.0.2/32 - local CP 0 0 0 4504466
224.0.0.5/32 - local CP 0 0 3158 4504466
224.0.0.6/32 - local CP 0 0 0 4504466
224.0.0.9/32 - local CP 0 0 14194 4504466
255.255.255.255/32 - ie0 CP 0 0 0 4504466
For each route in the table, the Destination and Gateway fields show the destination address and the address of the next-hop router used to reach that destination. The zero destination address is the default route. If the system does not find a route for a packet's destination, it forwards the packet to the default route rather than dropping the packet. Note that the router will use the most specific route (having the longest prefix) that matches a given destination. Direct routes do not show a gateway address.
An asterisk (*) in the flags column indicates a hidden route, which is not included in routing updates sent by the MAX TNT and is not used for forwarding packets. Hidden routes are used only for display purposes.
The IF field shows the name of the interface through which a packet addressed to the entry's destination will be sent. The route to the mcast interface name encapsulates the multicast forwarder for the entire class D address space. (For more information, see Setting up multicast forwarding.)
Routes to the local machine display the local interface name. Packets to the 224.0.0.1 and 224.0.0.2 interfaces can be multicasted and received like normal multicast packets, but upon receiving such a packet, the router does not forward it to another link layer device. (Effectively, these packets have an MTU of 1.)
OSPF uses 224.0.0.5 and 224.0.0.6 for inter-router communications (instead of using broadcasts, as RIP does).
Displaying the interface table
To display the interface table, use the -i option on the Netstat command line:
admin> netstat -i
Name MTU Net/Dest Address Ipkts Ierr Opkts Oerr
ie0 1500 10.32.8.0/24 10.32.8.25 1018339 1 622450 1
ie0-1 1500 10.56.1.0/24 10.56.1.1 0 0 0 0
lo0 1500 127.0.0.1/32 127.0.0.1 26622 0 26622 0
rj0 1500 127.0.0.2/32 127.0.0.2 0 0 0 0
bh0 1500 127.0.0.3/32 127.0.0.3 1 0 1 0
wanabe 1500 127.0.0.3/32 127.0.0.3 0 0 0 0
local 65535 127.0.0.1/32 127.0.0.1 233371 0 233371 0
mcast 65535 224.0.0.0/4 224.0.0.0 0 0 0 0
tunnel8 1500 10.32.8.0/24 10.32.8.25 0 0 0 0
vr0_main 1500 10.32.8.25/32 10.32.8.25 0 0 0 0
sip0 65535 - - 0 0 0 0
wan11 1500 10.32.8.21 10.32.8.25 0 0 0 0
wan12 1500 10.4.5.6 10.32.8.25 0 0 0 0
wan13 1500 - - 0 0 0 0
wan14 1500 - - 0 0 0 0
ie1-15-1 1500 - - 0 0 0 0
ie1-15-2 1500 - - 0 0 0 0
ie1-15-3 1500 - - 0 0 0 0
ie1-15-4 1500 - - 0 0 0 0
ie1-15-1-1 1500 - - 0 0 0 0
ie1-15-1-2 1500 - - 0 0 0 0
ie1-15-1-3 1500 - - 0 0 0 0
The entries named ie0 or ieN-N-N[-N ] represent Ethernet interfaces. N-N-N-N represents the shelf-number, slot-number, item-number, and logical-item number of the interface.When the logical-item number is zero (the physical interface), it does not appear in the interface name. The same sequence of numbers forms the address used to index the IP-Interface profile. For example, the default profile for 1-4-1 is indexed as follows:
IP-INTERFACE { { 1 4 1 } 0 }
When the logical-item number is not zero, it does appear in the interface name. Again, the sequence of numbers is identical to the profile index. For example, an IP-Interface profile with the following index:
IP-INTERFACE { { 1 4 1 } 3 }
has the following interface name:
ie1-4-1-3
The other names in the interface table, and their significance, are:
- The
lo0 (loopback) interface is the local loopback. - The
rj0 (reject) and bh0 (blackhole) interfaces are used in the Pool-Summary feature. - The
wanabe interface is an inactive RADIUS dialout profile. - The
local interface is the local machine. - The
mcast interface is the multicast interface, which represents the multicast forwarder for the entire class-D address space. For details, see Setting up multicast forwarding. - The
tunnel interface is a pseudo-interface that is used only when the MAX TNT is configured as an ATMP Router Home Agent. In that configuration, the MAX TNT creates a route for each registered mobile client. Regardless of how many tunnels the Home Agent may terminate, there is always a single tunnel interface. (The number terminating the tunnel interface name is an internal number which may change from one software version to the next.) - The
vr0_main interface represents the router itself. For details, see Configuring virtual routers. - The
sip0 interface is a soft IP interface. For details, see Setting a system source IP address. - The numbered WAN (
wanN ) interfaces are WAN connections, which are entered in the interface table as they become active.
Ascend notation for IP addresses
In the MAX TNT, IP addresses use dotted decimal format (not hexadecimal). If no subnet mask is specified, the MAX TNT assumes a default mask based on the address class. Table 4-1 shows address classes and the number of network bits in the default mask for each class.
Table 4-1. IP address classes
For example, a class C address, such as 198.5.248.40, has 24 network bits, leaving 8 bits for the host portion of the address. If no subnet mask is specified for a class C address, the MAX TNT assumes the default mask of 24 bits, as shown in Figure 4-1:
Figure 4-1. Class C IP address
To specify a subnet mask, the MAX TNT appends to the IP address a modifier that specifies the total number of network bits in the address. For example:
ip-address = 198.5.248.40/29
In this example, the /29 specification indicates that 29 bits of the address are used to specify the network. This is commonly referred to as a 29-bit subnet. The three remaining bits specify unique hosts.
Figure 4-2. 29-bit subnet mask and the number of supported hosts
With three bits used to specify hosts on a 29-bit subnet, eight different bit combinations are possible. Of those eight possible host addresses, two are reserved:
000 - Reserved for the network (base address)
001
010
100
110
101
011
111 - Reserved for the broadcast address of the subnet
Note: Early implementations of TCP/IP did not allow zero subnets. That is, subnets could not have the same base address that a class A, B, or C network would have. For example, the subnet 192.32.8.0/30 was illegal because it had the same base address as the class C network 192.32.8.0/24, while 192.32.8.4/30 was legal (192.32.8.0/30 is called a zero subnet, because like a class C base address, its last octet is zero). Modern implementations of TCP/IP allow subnets to have base addresses that might be identical to the class A, B, or C base addresses. Ascend's implementations of RIP-v2 and OSPF treat these so-called zero subnets the same as any other network. However, it is important that you treat zero subnets consistently throughout your network. Otherwise, you will encounter routing problems.
Table 4-2 shows standard and Ascend subnet formats for a class C network number.
Table 4-2. Standard subnet masks and Ascend notation
The broadcast address of any subnet has the host portion of the IP address set to all ones. The network address (or base address) represents the network itself, because the host portion of the IP address is all zeros. For example, if the MAX TNT configuration assigns the following address to a remote router:
198.5.248.120/29
The Ethernet attached to that router has the following address range:
198.5.248.120 - 198.5.248.127
A host route is a special-case IP address with a subnet mask of /32. For example:
198.5.248.40/32
Host routes are required for dial-in hosts. The route is to a single host, rather than to a router or subnet.
Configuring LAN IP interfaces
A LAN IP interface is an Ethernet port configured for IP. The MAX TNT creates an IP-Interface profile for an Ethernet port when it first detects the presence of the port. For example, the following output shows the default IP-Interface profiles for the shelf-controller and an Ethernet-2 card installed in slot 12:
admin> dir ip-interface
66 09/14/1998 10:13:24 { { shelf-1 controller 1 } 0 }
8 09/14/1998 11:36:32 { { shelf-1 slot-12 2 } 0 }
8 09/14/1998 11:36:32 { { shelf-1 slot-12 3 } 0 }
8 09/14/1998 11:36:32 { { shelf-1 slot-12 4 } 0 }
64 09/14/1998 11:53:12 { { shelf-1 slot-12 1 } 0 }
The profile for the first Ethernet port on a card in shelf 1, slot 12, uses the following index:
{{1 12 1} 0}
This index consist of a physical address and a logical-item number in the following format:
{{ shelf-num slot-num item-num } logical-item-num }
The logical item addresses a specific logical interface. It is zero except when multiple (virtual) interfaces have been configured on the physical port. For more details, see Example of defining virtual LAN interfaces.
Overview of LAN interface settings
Following are the parameters in an IP-Interface profile, shown with default settings:
[in IP-INTERFACE/{ { any-shelf any-slot 0 } 0 } ]
interface-address* = { { any-shelf any-slot 0 } 0 }
ip-address = 0.0.0.0/0
proxy-mode = Off
rip-mode = routing-off
route-filter = ""
rip2-use-multicast = yes
ospf = { no 0.0.0.0 normal 10 40 5 simple ******* 0 1 16777215 type-1+
multicast-allowed = no
multicast-rate-limit = 100
multicast-group-leave-delay = 0
directed-broadcast-allowed = yes
vrouter = ""
management-only = no
Example of configuring a LAN IP interface
The following commands set the IP address of the shelf-controller Ethernet port:
admin> dir ip-interface
66 09/14/1998 10:13:24 { { shelf-1 controller 1 } 0 }
admin> read ip-interface { { 1 c 1 } 0}
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } read
admin> set ip-address = 10.1.2.65/24
admin> write
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } written
In this example, the MAX TNT resides on the 10.1.2 subnet. To enable it to communicate with routers on other local subnets, it must either have a static route configuration to another router in its own subnet, or it must enable RIP. For an example of configuring a route to a local router, see Examples of configuring default routes.
After you assign an IP address, you can verify that the MAX TNT is a valid IP host on that network segment by Pinging another host, as shown in the following example:
admin> ping 10.65.212.19
PING 10.65.212.19: 56 Data bytes
64 bytes from 10.65.212.19: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 10.65.212.19: icmp_seq=3 ttl=255 time=0 ms
^C
--- 10.65.212.19: Ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
Enabling proxy ARP
When you enable proxy ARP, hosts on the local network can ARP for hosts or subnets that reside across the WAN but have an IP address on the local network. The MAX TNT responds to the ARP requests, and then routes the packets for those connections across the WAN.
You can enable Proxy-Mode by setting it to Active (respond for active WAN connections only), Inactive (respond only for inactive WAN connections), or Always (respond for all pool addresses, including those for inactive connections). If the MAX TNT is set to respond to ARP requests for inactive connections, it brings up the required WAN connection.
The following commands enable the MAX TNT to respond as proxy for ARP requests for active WAN connections:
admin> read ip-interface { { 1 c 1 } 0}
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } read
admin> set proxy-mode = active
admin> write
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } written
Enabling RIP
RIP is off by default, so the MAX TNT does not send out its routing table or receive routing information from other routers on the interface. This means that local hosts on other subnets cannot access remote hosts without static route configurations, and dial-in hosts do not have access to other routes maintained locally.
You can enable RIP to receive routing table updates, send them, or both. Receiving updates from other routers increases the size of the MAX TNT routing table. It can access more networks, but route searches are not as fast. Sending updates propagates information about remote networks to local routers.
Note: Ascend does not recommend running RIP-v2 and RIP-v1 on the same network in such a way that the routers receive each other's advertisements. RIP-v1 guesses subnet masks, while RIP-v2 handles them explicitly. Running the two versions on the same network can result in RIP-v1 guesses overriding accurate subnet information obtained via RIP-v2.
The following commands configure the MAX TNT to receive RIP-v2 updates on the multicast address:
admin> read ip-interface { { 1 c 1 } 0}
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } read
admin> set rip-mode = routing-recv-v2
admin> write
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } written
Example of defining virtual LAN interfaces
You can configure up to 16 IP-Interface profiles for each Ethernet card as a whole, with each profile specifying one IP address. The system creates the default profile for an interface and assigns it the zero logical-item number. To configure another IP address on a LAN interface, create an IP-Interface profile with a nonzero logical-item number in its interface address. For example, the following commands create a virtual interface for an Ethernet port installed in shelf 1, slot 12:
admin> new ip-int { {1 12 1 } 1}
IP-INTERFACE/{ { shelf-1 slot-12 1 } 1 } read
admin> set ip-addr = 10.9.1.212/24
admin> write
IP-INTERFACE/{ { shelf-1 slot-12 1 } 1 } written
The logical-item numbers do not have to be consecutive, but they must each be unique. The following restrictions apply to virtual LAN interfaces:
- The default IP-Interface profile (with the zero logical-item number) must have an IP address configured, or none of the other IP-Interface profiles for the same port will function. (Do not delete the default profile and expect your other configurations to work.)
- If Proxy-Mode is enabled in any of the IP-Interface profiles for a given Ethernet port, it is enabled for all ARP requests coming into the physical port.
- OSPF can be enabled on any one of a port's IP interfaces, but not on more than one interface for the same port.This is in conformance with RFC 1583.
Example of defining the interface-independent IP address
The interface-independent IP address is a soft destination address for the MAX TNT. It is soft because it is not associated with a physical port, which means that it is always accessible to inbound traffic. The interface-independent address must be unique.
Note: Do not use the IP address of a physical LAN interface for the soft interface address.
You define the interface-independent address in the IP-Interface profile with the default index ({ { any-shelf any-slot 0 } 0 }), which is reserved for that purpose. For example, the following commands set the soft interface address to 11.168.7.100:
admin> new ip-interface
IP-INTERFACE/{ { any-shelf any-slot 0 } 0 } read
admin> set ip-addr = 11.168.7.100
admin> write
IP-INTERFACE/{ { any-shelf any-slot 0 } 0 } written
To create an interface-independent address for a VRouter, create a new IP-Interface profile with the logical-item value greater than zero. For example:
admin> new ip-interface
IP-INTERFACE/{ { any-shelf any-slot 0 } 0 } read
admin> set interface-address = {{0 0 0}1}
(New index value; will save profile as IP-INTERFACE/{ { any-shelf any-
slot 0 } 1 }.)
admin> set ip-addr = 10.10.1.1
admin> write
IP-INTERFACE/{ { any-shelf any-slot 0 } 1 } written
The MAX TNT adds the soft address to its interface table with the name sip# where # is the logical-item number from the IP-Interface profile index. For more details about VRouters, see Configuring virtual routers.
If routing updates (RIP or OSPF) are enabled, the MAX TNT advertises the interface address as a host route with a mask of /32 using the loopback interface. If RIP or OSPF is not enabled, routers one hop away from the MAX TNT must have a static route to the soft address. To verify that other hosts in your network have a route to the soft address, use Ping or Traceroute from the other hosts. For example:
host1% ping 11.168.7.100
PING 11.168.7.100 (11.168.7.100): 56 Data bytes
64 bytes from 11.168.7.100: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 11.168.7.100: icmp_seq=7 ttl=255 time=0 ms
^C
--- 11.168.7.100 Ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
Example of disabling directed broadcasts
Denial-of-service attacks known as "smurf" attacks typically use ICMP Echo Request packets with a spoofed source address and the direction of packets to IP broadcast addresses. These attacks are intended to cause degraded network performance, possibly to the point that the network becomes unusable.
To prevent the MAX TNT router from being used as an intermediary in this type of denial-of-service attack launched from another network, you should disable the MAX TNT from forwarding directed broadcasts it receives from another network. The following example shows how to disable directed broadcasts that are not generated locally on all IP interfaces of a MAX TNT with a four-port Ethernet card in shelf 1, slot 12:
admin> read ip-int {{1 c 1} 0}
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } read
admin> set directed-broadcast-allowed = no
admin> write
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } written
admin> read ip-int {{1 12 1} 0}
IP-INTERFACE/{ { shelf-1 slot-12 1 } 0 } read
admin> set directed-broadcast-allowed = no
admin> write
IP-INTERFACE/{ { shelf-1 slot-12 1 } 0 } written
admin> read ip-int {{1 12 2} 0}
IP-INTERFACE/{ { shelf-1 slot-12 2 } 0 } read
admin> set directed-broadcast-allowed = no
admin> write
IP-INTERFACE/{ { shelf-1 slot-12 2 } 0 } written
admin> read ip-int {{1 12 3} 0}
IP-INTERFACE/{ { shelf-1 slot-12 3 } 0 } read
admin> set directed-broadcast-allowed = no
admin> write
IP-INTERFACE/{ { shelf-1 slot-12 3 } 0 } written
admin> read ip-int {{1 12 4} 0}
IP-INTERFACE/{ { shelf-1 slot-12 4 } 0 } read
admin> set directed-broadcast-allowed = no
admin> write
IP-INTERFACE/{ { shelf-1 slot-12 4 } 0 } written
Example of defining a management-only interface
Management-only means that incoming traffic on the interface terminates in the system itself. It is not forwarded on any other interface. In addition, only traffic generated by the system is forwarded on the management-only interface. Traffic generated externally is dropped on the interface. Setting the Management-Only parameter to Yes enforces these conditions on the port.
The following commands specify that a port on an installed card is a management-only interface:
admin> read ip-int {{ 1 12 1 } 0}
IP-INTERFACE/{ { shelf-1 slot-12 1 } 0 } read
admin> set management-only = yes
admin> write
IP-INTERFACE/{ { shelf-1 slot-12 1 } 0 } written
The Ifmgr -d command displays a Management Only field to reflect the port's status.
Configuring WAN IP interfaces
A WAN IP interface is a nailed or switched connection configured for IP. The MAX TNT creates a routed interface for local Connection profiles (if they do not use pool addresses) when the system starts up. For interfaces that use pool addresses or are defined in RADIUS user profiles, the MAX TNT creates a routing interface when a session becomes active.
Overview of WAN interface settings
You configure WAN IP interfaces in Connection profiles or RADIUS profiles. At a minimum, the profile specifies the IP address of the far end device or a pool from which the system assigns an address. You can also set a variety of routing and service parameters, as shown in the next sections.
Settings in Connection profiles
Following are the IP options (shown with default settings) in a Connection profile:
[in CONNECTION/"":ip-options]
ip-routing-enabled = yes
vj-header-prediction = yes
remote-address = 0.0.0.0/0
local-address = 0.0.0.0/0
routing-metric = 1
preference = 60
down-preference = 120
private-route = no
multicast-allowed = no
address-pool = 0
ip-direct = 0.0.0.0
rip = routing-off
route-filter = ""
source-ip-check = no
ospf-options = { no 0.0.0.0 normal 30 120 5 simple ******* 10 1000 +
multicast-rate-limit = 100
multicast-group-leave-delay = 0
client-dns-primary-addr = 0.0.0.0
client-dns-secondary-addr = 0.0.0.0
client-dns-addr-assign = yes
client-default-gateway = 0.0.0.0
[in CONNECTION/"":ip-options:tos-options]
active = no
precedence = 000
type-of-service = normal
apply-to = input
| Parameter | Specifies |
|---|
| IP-Routing-Enabled | Enables/disables IP routing for the interface. IP routing is enabled by default. |
| VJ-Header-Prediction | Enables/disables Van Jacobsen prediction for TCP packets on incoming calls using encapsulation protocols that support this feature. The default setting is Yes. |
| Remote-Address | IP address of the calling device, which can include a subnet specification. If it does not include a subnet mask, the router assumes the default subnet mask based on address class. |
| Local-Address | IP address assigned to the local side of a numbered-interface connection. (For details, see Examples of a numbered-interface connection.) |
| Routing-Metric | RIP metric for the specified route (a number between 1 to 15, default 1). If preference values are equal, the higher the metric, the less likely that the MAX TNT will use the route. |
| Preference | Preference value for the route.Valid values are from 0 to 255. For details, see Setting static route preferences. |
| Down-Preference | Preference value for the route when the interface is down. |
| Private-Route | Enables/disables advertisement of the route when the router sends RIP or OSPF updates. If set to Yes, the route is excluded from update packets. |
| Multicast-Allowed | See Setting up multicast forwarding. |
| Address-Pool | Number of the address pool from which to acquire an address (see Configuring and using address pools). |
| IP-Direct | IP address of a host to which all IP packets received across the link will be directed (see Examples of an IP-Direct connection). |
| RIP | Enables/disables RIP updates on the interface. RIP is disabled by default. |
| Route-Filter | Filter for RIP update packets. For details, see Chapter 10, Ascend Packet Filters. |
| Source-IP-Check | Enables/disables anti-spoofing for the session. When set to Yes, the system checks all packets received on this interface to ensure that the source IP address in the packets matches the far-end remote address or the address agreed upon in IPCP negotiation. If the addresses do not match, the system discards the packet. |
| OSPF-Options | OSPF routing options (see Chapter 5, OSPF Routing). |
| Multicast-Rate-Limit | Multicast forwarding option (see Setting up multicast forwarding). |
| Multicast-Group-Leave-Delay | Multicast forwarding option (see Setting up multicast forwarding). |
| Client-DNS-Primary-Addr | Client DNS option (see Using client DNS.) |
| Client-DNS-Secondary-Addr | Client DNS option (see Using client DNS.) |
| Client-DNS-Addr-Assign | Client DNS option (see Using client DNS.) |
| Client-Default-Gateway | Default route for traffic from this connection. For details, see Examples of client default gateways. |
| TOS-Options:Active | Enables/disables proxy-QoS and TOS for this connection (see Examples of setting QoS and TOS policy). |
| TOS-Options:Precedence | Priority level of the data stream. The three most significant bits of the TOS byte are priority bits used to set precedence for priority queuing. When TOS is enabled, those bits can be set to one of the following values (most significant bit first): 000: Normal priority. 001: Priority level 1. 010: Priority level 2. 011: Priority level 3. 100: Priority level 4. 101: Priority level 5. 110: Priority level 6. 111: Priority level 7 (the highest priority). |
| TOS-Options:Type-of-Service | Type of Service of the data stream. The next four bits of the TOS byte are used to choose a link based on the type of service. When TOS is enabled, Type-of-Service can specify Normal (Normal service), Cost (Minimize monetary cost), Reliability (Maximize reliability), Throughput (Maximize throughput), Latency (Minimize delay). |
| TOS-Options:Apply-To | In which direction TOS is enabled. If set to Input (the default), bits are set in packets received on the interface. If set to Output, bits are set in outbound packets only. If set to Both, both incoming and outgoing packets are tagged. |
Settings in RADIUS profiles
The following attribute-value pairs configure IP options in a RADIUS profile:
| Attribute | Value |
|---|
| Ascend-Route-IP (228) | Enables/disables IP routing for the interface. IP routing is enabled by default. |
| Framed-Compression (13) | Enables/disables Van Jacobsen prediction. You can specify Van-Jacobson-TCP-IP to turn on TCP/IP header compression. If you do not specify this value, RADIUS uses the default of no header compression. |
| Framed-Address (8) | IP address of the calling device. |
| Framed-Netmask (9) | Subnet mask of the caller's address. If you do not specify a subnet mask, the router assumes the default subnet mask based on address class. |
| Ascend-PPP-Address (253) | IP address assigned to the local side of a numbered-interface connection. (For details, see Examples of a numbered-interface connection.) |
| Ascend-IF-Netmask (153) | Subnet mask in use for the local side numbered interface. |
| Ascend-Metric (225) | RIP metric for the specified route (a number between 1 to 15, default 7). If preference values are equal, the higher the metric, the less likely that the MAX TNT will use the route. |
| Ascend-Route-Preference (126) | A preference value for the route. Valid values are from 0 to 255. A value of 255 prevents the use of the route. For details about setting preferences, see Setting static route preferences. |
| Framed-Route (22) | A static route definition, which can be used to make a user profile a private route. See Configuring static IP routes. |
| Ascend-Assign-IP-Pool (218) | Number of the address pool number from which to acquire an address (see Configuring and using address pools). |
| Ascend-Assign-IP- Global-Pool (146) | Name of a global address pool (see Global RADIUS pools (RADIPAD)). |
| Ascend-IP-Direct (209) | IP address of a host to which all IP packets received across the link will be directed (see Examples of an IP-Direct connection). |
| Framed-Routing (10) | Enables/disables RIP updates on the interface. RIP is disabled by default. Valid values are None(0), Broadcast(1), Listen(2), Broadcast-Listen(3), Broadcast-v2(4), Listen-v2(5), and Broadcast-Listen-v2(6). |
| Ascend-Source-IP- Check (96) | Enables/disables anti-spoofing for the session. The default is Source-IP-Check-No (0). When set to Source-IP-Check-Yes (1), the system checks all packets received on this interface to ensure that the source IP address in the packets matches the far-end remote address or the address agreed upon in IPCP negotiation. If the addresses do not match, the system discards the packet. |
| Ascend-Multicast-Client (155) | Multicast forwarding option (see Setting up multicast forwarding). |
| Ascend-Multicast-Rate-Limit (152) | Multicast forwarding option (see Setting up multicast forwarding). |
| Ascend-Multicast-GLeave-Delay (111) | Multicast forwarding option (see Setting up multicast forwarding). |
| Ascend-Client-Primary-DNS (135) | Client DNS option (see Using client DNS.) |
| Ascend-Client-Secondary-DNS (136) | Client DNS option (see Using client DNS.) |
| Ascend-Client-Assign-DNS (137) | Client DNS option (see Using client DNS.) |
| Ascend-Client-Gateway (132) | Default route for traffic from this connection (see Examples of client default gateways). |
| Ascend-IP-TOS (88) | Type of Service of the data stream. The value of this attribute sets the four bits following the three most significant bits of the TOS byte. which are used to choose a link based on the type of service. One of the following values can be specified: Ascend-IP-TOS IP-TOS-Normal (0): Normal service. Ascend-IP-TOS IP-TOS-Disabled (1): Disables TOS. Ascend-IP-TOS IP-TOS-Cost (2): Minimize monetary cost. Ascend-IP-TOS IP-TOS-Reliability (4): Maximize reliability. Ascend-IP-TOS IP-TOS-Throughput (8): Maximize throughput. Ascend-IP-TOS IP-TOS-Latency (16): Minimize delay. |
| Ascend-IP-TOS-Precedence (89) | Priority level of the data stream. The three most significant bits of the TOS byte are priority bits used to set precedence for priority queuing. When TOS is enabled, those bits can be set to one of the following values (most significant bit first): IP-TOS-Precedence-Pri-Normal (0): Normal priority. IP-TOS-Precedence-Pri-One (32): Priority level 1. IP-TOS-Precedence-Pri-Two (64): Priority level 2. IP-TOS-Precedence-Pri-Three (96): Priority level 3. IP-TOS-Precedence-Pri-Four (128): Priority level 4. IP-TOS-Precedence-Pri-Five (160): Priority level 5. IP-TOS-Precedence-Pri-Six (192): Priority level 6. IP-TOS-Precedence-Pri-Seven (224): Priority level 7 (the highest priority). |
| Ascend-IP-TOS-Apply-To (90) | In which direction TOS is enabled. If set to IP-TOS-Apply-To-Incoming (1024), which is the default, bits are set in packets received on the interface. If set to IP-TOS-Apply-To-Outgoing (2048), bits are set in outbound packets only. If set to IP-TOS-Apply-To-Both (3072), both incoming and outgoing packets are tagged. |
Examples of a connection to another IP router
Figure 4-3 shows the MAX TNT connecting to a far-end router, such as an Ascend Pipeline. This could be a telecommuting configuration, for example, where the Pipeline is located at a branch or home office.
Figure 4-3. Router-to-router IP connection
The default settings for the IP-Options subprofile enable IP routing and Van Jacobsen header compression and turn RIP off. Those are the appropriate settings for the following example, which configures a Connection profile for the Pipeline in Figure 4-3:
admin> read conn pipeline1
CONNECTION/pipeline1 read
admin> set active = yes
admin> set encapsulation-protocol = ppp
admin> set dial-number = 9-1-333-555-1212
admin> set ppp send-auth-mode = pap-ppp-auth
admin> set ppp send-password = remotepw
admin> set ppp recv-password = localpw
admin> set ip-options remote = 10.7.8.200/24
admin> write
CONNECTION/pipeline1 written
Following are comparable RADIUS profiles:
pipeline1 Password = "localpw"
User-Service = Framed-User,
Framed-Protocol = PPP,
Framed-Address = 10.7.8.200,
Framed-Netmask = 255.255.255.0
route-tnt-1 Password = "ascend", User-Service = Dialout-Framed-User
Framed-Route = "10.7.8.0/24 10.7.8.200 1 n pipeline1-out"
pipeline1-out Password = "localpw", User-Service = Dialout-Framed-User
User-Name = "pipeline1",
Ascend-Dial-Number = "9-1-333-555-1212",
Framed-Protocol = PPP,
Framed-Address = 10.7.8.200,
Framed-Netmask = 255.255.255.0,
Ascend-Send-Auth = Send-Auth-PAP,
Ascend-Send-Password = "remotepw"
Examples of a host route connection
A host route is advertised as an IP address with a subnet mask of 32. It represents a single host rather than a remote router. Figure 4-4 shows a sample connection in which a dial-in host with an ISDN modem card calls into the MAX TNT.
Figure 4-4. Dial-in host requiring a static IP address (a host route)
The PPP configuration includes the host's address. For example:
Username=patti
Accept Assigned IP=N/A (or No)
IP address=10.8.9.10
Netmask=255.255.255.255
Default Gateway=N/A (or None)
Name Server=10.7.7.1
Domain suffix=abc.com
VAN Jacobsen compression ON
The default settings for the IP-Options subprofile enable IP routing and Van Jacobsen header compression and turn RIP off. Those settings are appropriate for the following example, which configures the Connection profile for the host in Figure 4-4:
admin> new conn patti
CONNECTION/patti read
admin> set active = yes
admin> set encapsulation-protocol = ppp
admin> set ppp recv-password = localpw
admin> set ip-options remote = 10.8.9.10/32
admin> write
CONNECTION/patti written
Following is a comparable RADIUS profile:
patti Password = "localpw"
User-Service = Framed-User,
Framed-Protocol = PPP,
Framed-Address = 10.8.9.10,
Framed-Netmask = 255.255.255.255
Examples of a numbered-interface connection
For a numbered-interface connection, each side of the connection is assigned a unique address that applies only to the connection. This is a requirement for some applications, such as SNMP.
The Local-Address assigned to a numbered interface must be unique to the connection and to the network. You can assign a fake IP address or an IP address from one of the local subnets. The MAX TNT accepts IP packets destined for the specified address and treats them as destined for the system itself. (The packets may arrive on any interface, and the destination interface need not be in the active state.)
Note: Do not assign a local address that belongs to one of the MAX TNT unit's real, physical LAN interfaces. Assigning one of the MAX TNT IP addresses will cause routing problems.
Figure 4-5 shows a numbered-interface connection. The real, physical MAX TNT Ethernet interface has the IP address 10.5.6.7/24. The other two addresses represent the local and remote addresses of the numbered-interface connection.
Figure 4-5. A numbered interface connection
The following set of commands specifies a Connection profile for the numbered interface:
admin> new conn numbered
CONNECTION/numbered read
admin> set active = yes
admin> set encapsulation-protocol = ppp
admin> set ppp recv-password = localpw
admin> set ip-options remote-address = 10.9.1.213/30
admin> set ip-options local-address = 10.9.1.212/30
admin> write
CONNECTION/numbered written
Following is a comparable RADIUS profile:
numbered Password = "localpw"
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Route-IP = Route-IP-Yes,
Framed-Address = 10.9.1.213,
Framed-Netmask = 255.255.255.252,
Ascend-PPP-Addr = 10.9.1.212,
Ascend-IF-Netmask = 255.255.255.252
In this example, the interface is assigned a 30-bit subnet, so four bit combinations are available for host assignments. Of those four possible host addresses, the one that is evenly divisible by 4 is the network or base address (the address that specifies zeros in the host bits). This address is added to the routing table. The other host addresses are assigned a /32 subnet mask and added as host routes. You can suppress advertisement of the host routes associated with a numbered interface by using the Suppress-Host-Routes parameter, as described in Suppressing host-route advertisements.
Examples of an IP-Direct connection
Packets received on an IP-Direct connection bypass the routing tables and are redirected instead to a specified next-hop destination IP address. Outbound packets are routed as usual. At this time, the feature is implemented only for data calls. Figure 4-6 shows an example of the IP-Direct traffic flow.
Figure 4-6. IP Direct connections
In Figure 4-6, the following conditions apply:
- Client-A's profile redirects inbound packets to router-A on a LAN interface.
- Client-B's profile redirects inbound packets to router-B on a LAN interface .
- Client-C's profile redirects inbound packets to router-C through a switched connection.
Outbound packets destined for any of the three clients are routed normally by the MAX TNT, which means that these client connections can receive packets from any source, not just from the IP address to which their packets are sent.
The following set of commands configures an IP-Direct Connection profile for client-A:
admin> read conn client-A
CONNECTION/client-A read
admin> set active = yes
admin> set encapsulation-protocol = ppp
admin> set ppp recv-password = localpw
admin> set ip-options remote = 10.8.9.10/22
admin> set ip-options ip-direct = 10.2.3.11
admin> write
CONNECTION/client-A written
Following is a comparable RADIUS profile:
client-A Password = "localpw"
User-Service = Framed-User,
Framed-Protocol = PPP,
Framed-Address = 10.8.9.10,
Framed-Netmask = 255.255.252.0,
Ascend-IP-Direct = 10.2.3.11
IP-Direct connections require the following special handling:
- If the profile enables the receipt or receipt-transmission of RIP updates, all RIP packets from an incoming connection are kept locally and forwarded to the IP-Direct address, so that the MAX TNT can correctly forward packets destined for the client.
- ARP requests received from the incoming connection are ignored.
- The caller cannot Telnet to the MAX TNT, because the connection is passed through to the IP-Direct host.
Examples of making the route to a connection private
A private route is placed in the routing table but is marked with a flag that prevents routing protocols from advertising it. The following commands specify a private route in a Connection profile:
admin> read conn david
CONNECTION/david read
admin> set ip-options remote = 10.8.9.10/24
admin> set ip-options private = yes
admin> set ip-options routing-metric = 3
admin> write
CONNECTION/david written
Following is a comparable RADIUS profile:
david Password = "localpw"
User-Service = Framed-User,
Framed-Protocol = MPP,
Framed-Address = 10.8.9.10,
Framed-Netmask = 255.255.255.0,
Framed-Route = "10.8.9.10/24 0.0.0.0 3 y"
Examples of client default gateways
A client default gateway is a route that replaces the system-wide default route for a particular connection. For packets arriving on the connection, if the MAX TNT consults the routing table and finds no match for the packets' destination (if it finds only the system default route or no match at all, if there is no system default route), it forwards the packets to the client default gateway address.
Note: The specified address must be a legitimate next hop, that is, the MAX TNT must be able to reach the router directly in one hop. If this is not the case, the MAX TNT drops the packets it should route to the client default gateway.
Packets from other users or from the Ethernet are handled normally. The system's routing table is not modified by use of this feature.The following commands specify a connection-specific default gateway:
admin> read connection test
CONNECTION/test read
admin> set ip-options client-default-gateway = 17.1.1.1
admin> write
CONNECTION/test written
Following is a comparable setting in a RADIUS profile:
test Password = "localpw". User-Service = Framed-User
Ascend-Client-Gateway = 17.1.1.1
Examples of per-session source address checking
Administrators can configure WAN IP interfaces so the system checks the source IP address in all received packets, and drops the packets if the address does not match the address negotiated for the far-end subnet. This type of configuration enables the MAX TNT to detect packets with a spoofed source ip addresses and discard them.
When the system initially detects a spoofing attempt (a mismatched source address), it logs a message that includes the port number on which the attempt occurred. For example:
[1/4/1/1] Spoofing Attempt: from port 1 [MBID 1; 1119855018] [ed-mc1-p75]
The following commands configure a Connection profile for anti-spoofing:
admin> read connection ed-mc1-p75
CONNECTION/ed-mc1-p75 read
admin> set ip-options source-ip-check = yes
admin> write
CONNECTION/ed-mc1-p75 written
Following is a comparable setting in a RADIUS profile:
ed-mc1-p75 Password = "localpw"
User-Service = Framed-User,
Ascend-Source-IP-Check = Source-IP-Check-Yes
Examples of setting QoS and TOS policy
You can configure the MAX TNT to set Quality of Service (QoS) priority bits and Type of Service (TOS) classes of service on behalf of customer applications. The MAX TNT does not implement priority queuing, but it does set information that can be used by other routers to prioritize and select links for particular data streams.
To enable service-based TOS or to set QoS precedence for the traffic on a particular WAN connection, configure the TOS options in a Connection or RADIUS profile. The settings cause the MAX TNT set bits in the TOS byte of IP packet headers that are received (the default), transmitted, or both, on the WAN interface. Another router can then interpret the bits accordingly.
You can also specify proxy-QoS and TOS policy in a TOS filter, which can then be applied to any number of Connection or RADIUS profiles. For a Connection or RADIUS profile that has both its own local policy and an applied TOS filter, the policy defined in the TOS filter takes precedence. For example, applying a TOS filter to a TOS-enabled connection allows administrators to define one priority setting for incoming packets on a connection and another for incoming packets addressed to a particular destination (the destination in a TOS filter). For details, see Chapter 10, Ascend Packet Filters.
The following set of commands enables TOS for incoming packets on a WAN interface. It sets the priority of the packets at 6. This means that another router that implements priority queuing will not drop the packets until it has dropped all packets of a lower priority. The commands also set TOS to prefer maximum throughput. This means that the priority-queuing router will choose a high bandwidth connection if one is available, even if it is of higher cost, higher latency, or less reliable than another available link.
admin> read connection jfan-pc
CONNECTION/jfan-pc read
admin> set ip-options remote-address = 10.168.6.120/24
admin> set ip-options tos active = yes
admin> set ip-options tos precedence = 110
admin> set ip-options tos type = throughput
admin> write
CONNECTION/jfan-pc written
Following is a comparable RADIUS profile:
jfan-pc Password = "localpw"
User-Service = Framed-User,
Framed-IP-Address = 10.168.6.120,
Framed-IP-Netmask = 255.255.255.0,
Ascend-IP-TOS = IP-TOS-Throughput ,
Ascend-IP-TOS-Precedence = IP-TOS-Precedence-Pri-Six,
Ascend-IP-TOS-Apply-To = IP-TOS-Apply-To-Incoming
Configuring static IP routes
Any profile that specifies how to reach an IP device or subnet (such as an IP-Interface, Connection, or RADIUS user profile) specifies a static IP route to that destination . However, sometimes administrators configure static routes in a more flexible way, to extend or fine-tune the routing table.
The default route is a special-case static route that acts as a catch-all for packets for which the MAX TNT cannot find a route. If the administrator defines a default route (with the zero destination address), the MAX TNT routes all packets with unknown destinations to the specified gateway. If no default route is defined, the MAX TNT drops those packets.
If the unit's LAN IP addresses include subnet specifications, you must create a static route to another LAN router to enable the MAX TNT to reach local networks beyond its own subnets. You might also configure a static route to a LAN router to offload local routing overhead from the MAX TNT.
Another reason to configure static routes is to specify multipath routes, which define multiple paths to the same destination. Multipath routes, with equal metric and equal preference values, distribute traffic to a single destination across multiple interfaces.
Overview of static route settings
You can define static routes in IP-Route profiles or in RADIUS.
Settings in IP-Route profiles
Following are the settings in a local IP-Route profile (shown with default settings):
in IP-ROUTE/"" (new)]
name* = ""
dest-address = 0.0.0.0/0
gateway-address = 0.0.0.0
metric = 8
cost = 1
preference = 60
third-party = no
ase-type = type-1
ase-tag = c0:00:00:00
private-route = no
active-route = yes
ase7-adv = N/A
vrouter = ""
inter-vrouter = ""
Settings in a RADIUS route profiles
A route profile is a pseudo-user profile in which the first line has this format:
route-name-N Password = "ascend", User-Service = Dialout-Framed-User
The name argument is the MAX TNT system name (specified by the Name parameter in the System profile), and N is a number in a sequential series, starting with 1. Make sure there are no missing numbers in the series specified by N. If there is a gap in the sequence of numbers, the MAX TNT stops retrieving the profiles when it encounters the gap in sequence.
Note: To specify routes that may be dialed out by more than one system, eliminate the name argument. In that case, the first word of the pseudo-user profile is route-N.
Each pseudo-user profile specifies one or more routes with the Framed-Route (22) attribute. The value of the Framed-Route attribute uses the following syntax:
"dest-addr gateway-addr metric [private] [profile][preference][VRouter]"
Route settings in a RADIUS user profile
You can also include the Framed-Route (22) attribute in a RADIUS user profile to define a static route. See Settings in a RADIUS route profiles for details about Framed-Route usage.
In a user profile, you can specify the zero address as the gateway-address. In this context, the 0.0.0.0 address is a wildcard entry the MAX TNT replaces with the caller's IP address.When RADIUS authenticates the caller and sends the MAX TNT an Access-Accept message with a value of 0.0.0.0 for the router address, the MAX TNT updates its routing tables with the Framed-Route value, but substitutes the caller's IP address for the router. This setting is useful when the MAX TNT assigns an IP address from an address pool and RADIUS cannot know the IP address of the caller.
If a Framed-Route definition in a user profile duplicates a route defined in a route or IP-Route profile, the user profile definition takes precedence while the connection is active. For example, suppose a static route to network 10.10.10.10 is defined in a local IP-Route profile with a metric of 10. A RADIUS user profile in RADIUS defines a static route to 10.10.10.10 with a metric of 7. When the RADIUS user's route is not in use, the routing table indicates that the route has a metric of 10. When the route is in use, the MAX TNT routing table indicates that the route has a metric of 7, with an r in the flags column to indicate that the route came from RADIUS. Furthermore, the route with a metric of 10 remains in the routing table, with an asterisk (*) in the flags column, indicating that it is a hidden route.
Connection-specific private static routes (RADIUS only)
The following attribute-value pairs configure IP options in a RADIUS profile:
Examples of configuring default routes
A route with the zero destination address is a default route. If the system does not find a route for a packet's destination, it forwards the packet to a default route rather than dropping the packet. If there is no default route in the routing table, the MAX TNT drops packets for which it cannot find a route.
The MAX TNT creates an IP-Route profile named default, but the profile is not valid until you specify a gateway address, so the route is not active until you assign an address and activate the route. For example:
admin> read ip-route default
IP-ROUTE/default read
admin> set gateway-address = 10.10.10.10
admin> set active-route = yes
admin> write
IP-ROUTE/default written
You can create a default route by modifying the default profile, or by creating one or more IP-Route profiles that specify the zero destination and a valid gateway address.
Examples of a LAN-based default route
Figure 4-7 shows a router that resides on the same subnet as one of the MAX TNT unit's local IP interfaces:
Figure 4-7. Default route to a local IP router
Because the MAX TNT is located on a subnet, it needs to be informed about other backbone routers that can route beyond the subnet. In this example, the MAX TNT offloads part of its routing overhead by using a default route to the LAN router. The following commands define a default route to the local router:
admin> new ip-route lanroute-1
IP-ROUTE/lanroute-1 read
admin> set gateway-address = 10.4.4.133
admin> write
IP-ROUTE/lanroute-1 written
Following is a comparable RADIUS default route:
route-tnt-1 Password = "ascend", User-Service = Dialout-Framed-User
Framed-Route = "0.0.0.0 10.4.4.133"
Examples of a default route across a WAN link
Figure 4-8 shows a router that resides across a Frame Relay DLCI interface. If the WAN link to this default route goes down for any reason, the MAX TNT removes the route from its routing table.
Figure 4-8. Default route across a Frame Relay DLCI interface
In this example, the following Frame Relay settings define the data link:
[in FRAME-RELAY/fr1]
fr-name* = fr1
active = yes
nailed-up-group = 1
link-mgmt = ansi-t1.617d
link-type = dte
and the following Connection profile defines the DLCI interface:
[in CONNECTION/pvc1]
station* = pvc1
active = yes
encapsulation-protocol = frame-relay
ip-options = { yes yes 20.1.1.8/32 0.0.0.0/0 1 60 120 no no 0 0.0.0.0+
telco-options = { ans-and-orig no ft1 1 no no 56k-clear 0 "" "" no no+
fr-options = { fr1 16 "" no "" 16 }
The following commands define a default route to the remote device:
admin> new ip-route dlci
IP-ROUTE/dlci read
admin> set gateway-address = 20.1.1.8
admin> set private-route = yes
admin> write
IP-ROUTE/dlci written
Following is a comparable RADIUS default route:
route-tnt-1 Password = "ascend", User-Service = Dialout-Framed-User
Framed-Route = "0.0.0.0 20.1.1.8 y"
Examples of configuring a route to a remote subnet
When RIP and OSPF are turned off on an IP interface, the router cannot reach other routers on that interface unless it has a static route. For example, if a Connection profile specifies the destination address of a host on a remote subnet, but the packets must be routed through an intermediary device to reach that host (and RIP or OSPF is not enabled), you must configure a static route specifying the intermediary device as the gateway. Figure 4-9 shows an example.
Figure 4-9. Static route to a remote subnet
The following commands configure a static route to all hosts on the remote subnet:
admin> new ip-route subnet
IP-ROUTE/subnet read
admin> set dest = 10.4.5.0/22
admin> set gateway = 10.9.8.10
admin> write
IP-ROUTE/subnet written
Following is a RADIUS profile that shows both the default route and a route to the remote subnet:
route-tnt-1 Password = "ascend", User-Service = Dialout-Framed-User
Framed-Route = "10.4.5.0/22 10.9.8.10"
Examples of configuring a multipath route
Multipath static routes distribute traffic to one destination across the aggregated bandwidth of multiple interfaces. A multipath route requires that the multiple static routes have the same destination address and subnet mask, but different gateway addresses. In addition, they must have the same route metric or OSPF cost, and the same route preference. (Otherwise, the route with the lowest values for these settings would be used exclusively.)
Note: Even the default routes can be multipath. If more than one route has a destination of 0.0.0.0, the MAX TNT creates multipath default routes.
Following is an example in which an administrator configures a multipath route to the network 10.76.109.0/24:
admin> new ip-route bdvnet-1
IP-ROUTE/bdvnet-1 read
admin> set dest = 10.76.109.0/24
admin> set gateway = 11.65.212.1
admin> set metric = 2
admin> write
IP-ROUTE/bdvnet-1 written
admin> new ip-route bdvnet-2
IP-ROUTE/bdvnet-2 read
admin> set dest = 10.76.109.0/24
admin> set gateway = 11.65.210.1
admin> set metric = 2
admin> write
IP-ROUTE/bdvnet-2 written
Following is a comparable RADIUS profile:
route-tnt-2 Password = "ascend", User-Service = Dialout-Framed-User
Framed-Route = "10.76.109.0/24 11.65.212.1 2",
Framed-Route = "10.76.109.0/24 11.65.210.1 2"
The multipath routes appear in the routing table with the M (multipath) flag. For example:
admin> netstat -rn
Destination Gateway IF Flg Pref Met Use Age
...
10.76.109.0/24 11.65.212.1 ie1-12-2 SGM 100 2 20 7772
10.76.109.0/24 11.65.210.1 ie1-12-3 SGM 100 2 24 7772
Examples of private static routes
A RADIUS user profile can specify a list of private routes associated with the connection. (There is no comparable functionality in local Connection profiles.)
Private routes defined by the Ascend-Private-Route attribute in a user profile affect only packets received from the connection. The routes are not added to the global routing table. If a destination is not found in the list of private routes and there is no default private route, the global routing table is consulted for a decision on routing the packets. Otherwise, only the private routing table is consulted.
Following is an example user profile that creates three private routes associated with this caller:
pipe50 Password = "ascend" User-Service = Framed-User,
Framed-Protocol = PPP,
Framed-Address = 10.1.1.1,
Framed-Netmask = 255.0.0.0,
Ascend-Private-Route = "170.1.0.0/16 10.10.10.1"
Ascend-Private-Route = "200.1.1.1/32 10.10.10.2"
Ascend-Private-Route = "20.1.0.0/16 10.10.10.3"
Ascend-Private-Route = "0.0.0.0/0 10.10.10.4"
With this profile, the private routing table for this connection contains the following routes, including a default route:
Dest/Mask Gateway
170.1.0.0/16 10.10.10.1
200.1.1.1/32 10.10.10.2
20.1.0.0/16 10.10.10.3
0.0.0.0/0 10.10.10.4
Note: The user profile may also specify the Ascend-Client-Gateway attribute, but it will not modify the private default route if one has been specified via the Ascend-Private-Route attribute.
When the next-hop router address in an Ascend-Private-Route attribute is the zero address (0.0.0.0), a lookup is performed for that route in the global routing table, providing an exit mechanism to the global table for specific private routes. For example, with the private routes defined in the following RADIUS user profile:
pipe50 Password = "ascend" User-Service = Framed-User,
Framed-Protocol = PPP,
Framed-Address = 10.1.1.1,
Framed-Netmask = 255.0.0.0,
Ascend-Private-Route = "170.1.0.0/16 10.10.10.1 1"
Ascend-Private-Route = "200.1.1.1/32 10.10.10.2"
Ascend-Private-Route = "20.1.0.0/16 0.0.0.0 1"
Ascend-Private-Route = "0.0.0.0/0 10.10.10.4 1"
The private routing table for this connection contains the following routes:
Dest/Mask Gateway
170.1.0.0/16 10.10.10.1
200.1.1.1/32 10.10.10.2
20.1.0.0/16 0.0.0.0
0.0.0.0/0 10.10.10.4
With this private table, a route lookup for the 20.1.0.0/16 network proceeds to the global routing table.
Setting TCP/IP routing policies
The MAX TNT router has many configuration settings that affect its operations. The settings that determine its routing policies include security, RIP options, IP route cache options, and other options. These settings are available only in the IP-Global profile. They have no counterpart in RADIUS.
Note: You can also configure the MAX TNT to set QoS priority bits and TOS classes of service on behalf of customer applications, which can then be used by other routers to prioritize and select links for particular data streams. These policies are set on WAN interfaces. For details, see Examples of setting QoS and TOS policy.
Setting a system source IP address
The system IP address is the source address used for all packets generated by the system, such as RADIUS requests, ATMP tunnel requests, or a Telnet, Traceroute, or Ping command originating from the unit. It must be the real address of one of the unit's LAN IP interfaces, or the interface-independent address described in Example of defining the interface-independent IP address.
Following is the parameter for specifying a system address:
[in IP-GLOBAL]
system-ip-addr = 0.0.0.0
With the default zero address, the MAX TNT uses the IP address assigned to the shelf-controller Ethernet interface as the source address for packets it generates. One reason for setting a system address other than the default is that doing so simplifies access control. For example, most RADIUS servers keep a database of known RAS clients and their authentication keys. If you do not specify a system address, the RADIUS database must include a complete list of all the system's interface addresses. If you specify a system address, it is used for all RADIUS request packets.
Another reason for setting a system address is to ensure that packets sent from an ATMP Home Agent to Foreign Agents have a single, standard source address. Recommended for ATMP Home Agents that have multiple interfaces into the IP cloud that separates them from Foreign Agents, to prevent communication problems if a route changes within the IP cloud. For details, see System IP address recommendation.
Following is an example of setting the System-IP-Addr parameter to an address assigned to a port on a slot card:
admin> dir ip-interface
66 09/14/1998 10:13:24 { { shelf-1 controller 1 } 0 }
8 09/14/1998 11:36:32 { { shelf-1 slot-12 2 } 0 }
8 09/14/1998 11:36:32 { { shelf-1 slot-12 3 } 0 }
8 09/14/1998 11:36:32 { { shelf-1 slot-12 4 } 0 }
8 09/14/1998 11:36:59 { { shelf-1 slot-12 5 } 0 }
64 09/14/1998 11:53:12 { { shelf-1 slot-12 1 } 0 }
admin> get ip-int { {1 12 1} 0} ip-address
ip-address = 10.2.3.4
admin> read ip-global
IP-GLOBAL read
admin> set system-ip-addr = 10.2.3.4
admin> write
IP-GLOBAL written
Setting router security policies
The following parameters (shown with default settings) affect router security:
[in IP-GLOBAL]
must-accept-address-assign = no
shared-prof = no
telnet-password = ""
user-profile = ""
Requiring acceptance of dynamic address assignment
During PPP negotiation, a calling station could reject an IP address offered by the router and present the caller's own IP address for consideration. For security purposes, many sites set Must-Accept-Address-Assign to Yes to ensure that the MAX TNT terminates such a call, as shown in the following example:
admin> read ip-global
IP-GLOBAL read
admin> set must-accept-address-assign = yes
admin> write
IP-GLOBAL written
For address assignment to occur, the MAX TNT must have an address available for assignment, the Answer-Defaults profile must enable dynamic assignment, the caller's profile must specify dynamic assignment, and the caller's PPP dial-in software must be configured to acquire its IP address dynamically. For details, see Examples of assigning an address from a pool.
Shared profiles
In low-security situations, more than one caller can share a name and password for accessing the local network. If you do not need the added security of ensuring that each connection is authenticated with its own password, you can set the Shared-Prof parameter as follows:
admin> read ip-global
IP-GLOBAL read
admin> set shared-prof = yes
admin> write
IP-GLOBAL written
If you do enable shared profiles, the profile cannot result in a shared IP address (two callers at different locations sharing the same address). So, the profile must either not assign an IP address at all, or must assign one dynamically. When the shared profile uses dynamic address assignment, each call is a separate connection that shares the same name and password, but a separate IP address is assigned dynamically to each caller. For details on dynamic IP address assignment, see Examples of assigning an address from a pool.
Restricting Telnet access to the system:
A user can initiate a Telnet session to the MAX TNT command line from a local workstation or from a WAN connection. In both cases, the MAX TNT authenticates the session by means of a User profile, which defines a permission level for the user logging in. (For details about User profiles, see the MAX TNT Reference Guide.)
In addition to the password required by a User profile, you can specify that Telnet requires its own password authentication, which occurs before any User profile authentication.
The commands in the following example set the Telnet-Password parameter and specify the Default User profile for Telnet logins. The Default profile enables minimal permissions and requires no password.
admin> read ip-global
IP-GLOBAL read
admin> set telnet-password = Ascend
admin> set user-profile = default
admin> write
IP-GLOBAL written
When users Telnet to the system, they are allowed three tries, each with a 60-second time limit, to enter the correct Telnet password. If all three attempts fail, the connection times out. If they specify the correct Telnet password, the MAX TNT prompts again for a user name and password to authenticate a User profile. In the following example, a user starts a Telnet session to a MAX TNT unit named TNT01, which has a configured Telnet password.
% telnet tnt01
<tnt01> Enter Password:
Trying 10.1.2.3 ...
Connected to tnt01.abc.com.
Escape character is `^]'.
User:
After specifying the correct Telnet password, the user is prompted for a user name and password to authenticate a User profile.
Setting system-wide routing policies
The following parameters, shown with default settings, specify system-wide routing policies:
[in IP-GLOBAL]
ignore-icmp-redirects = no
icmp-reply-directed-bcast = no
drop-source-routed-ip-packets = no
static-pref = 100
Ignoring ICMP packets
ICMP Redirect packets can be counterfeited and used to change the way a device routes packets. Many sites choose to ignore ICMP Redirects for security purposes.
ICMP Echo Requests to the broadcast address have been used in denial-of-service attacks. To prevent the MAX TNT router from being used in a denial-of-service attack when an attacker compromises another router on the same Ethernet as the MAX TNT, you can prevent the MAX TNT from responding to directed-broadcast ICMP Echo Requests sent to the IP broadcast address.
The following commands configure the system to ignore both types of ICMP packets. (It does not respond to ICMP Echo requests to the broadcast address by default.)
admin> read ip-global
IP-GLOBAL read
admin> set ignore-icmp-redirects = yes
admin> write
IP-GLOBAL written
Dropping source-routed packets
The Drop-Source-Routed-IP-Packets parameter default is No, which causes the router to forward all source routed packets as described in RFC1812, Requirements For Routers. When set to Yes, the router drops all packets that have either a Loose or a Strict source route among their IP options. The following set of commands instructs the router to drop source-routed packets:
admin> read ip-global
IP-GLOBAL read
admin> set drop-source-routed-ip-packets = yes
admin> write
IP-GLOBAL written
Setting static route preferences
Because RIP and OSPF metrics are incompatible, the MAX TNT supports route preferences, which provide a way to weight routes that takes precedence over route metrics. When choosing a route, the router first compares preference values, preferring the lowest number. If the preference values are equal, the router compares the metric values, using the route with the lowest metric. Following are the default preferences for different types of routes:
- 0 (zero)-Connected routes
- 10-OSPF routes
- 30-Routes learned from ICMP redirects
- 100-Routes learned from RIP
- 100-Static routes
If a dynamic route's preference is lower than that of the static route, the dynamic route can hide (temporarily overwrite) a static route to the same network. However, dynamic routes age, and if no updates are received, they eventually expire. In that case, the hidden static route reappears in the routing table.By default, static routes and RIP routes have the same preference, so they are weighted equally. ICMP redirects take precedence over both, and OSPF takes precedence over everything.
The following command decreases the preference value of static routes, instructing the router to use those routes first if they exist:
admin> read ip-global
IP-GLOBAL read
admin> set static-pref = 50
admin> write
IP-GLOBAL written
Setting routing protocol options
The following parameters (shown with default settings) define how the MAX TNT handles routing protocol updates. :
[in IP-GLOBAL]
rip-policy = Poison-Rvrs
summarize-rip-routes = no
rip-trigger = yes
rip-pref = 100
dialout-poison = no
rip-queue-depth = 0
ignore-def-route = yes
suppress-host-routes = no
ospf-pref = 10
ospf-ase-pref = 150
rip-tag = c8:00:00:00
rip-ase-type = 1
[in IP-GLOBAL:ospf-global]
as-boundary-router = yes
RIP policy for propagating updates back to the originating subnet
You can specify a split-horizon or poison-reverse policy for outgoing update packets that include routes received on the same interface on which the update is sent. Split-horizon means that the router does not propagate routes back to the subnet from which they were received. Poison-reverse means that it propagates routes back to the subnet from which they were received, but with a metric of 16 (infinite metric).
The following command specifies the split-horizon policy:
admin> read ip-global
IP-GLOBAL read
admin> set rip-policy = split
admin> write
IP-GLOBAL written
RIP triggering
RIP triggering enables the router to tag routes that have been updated in the routing table and send updates that include only the changed routes. The result is reduced processing overhead in the MAX TNT router as well as its neighbors.
With the default value (Yes), the router tags changes to its routing table and includes only the tagged routes in its next update. Changes occur when a call arrives or disconnects, RIP or OSPF learns a route from another router, or the administrator modifies a route-related profile. The router broadcasts updates 5 to 8 seconds after the first change in the routing table is detected. The delay helps to prevent constant updates during peak traffic conditions.
If RIP-Trigger is set to No, the router sends full table updates every 20 to 40 seconds. The full table update is no longer broadcast at fixed 30-second intervals, to prevent RIP routers on a network synchronizing and sending large updates in unison.
Setting the preference value for routes learned from RIP updates
For an introduction to route preferences, see Setting static route preferences. The following command increases the preference value of routes learned from RIP updates, instructing the router to use those routes only if no other route exists to the same destination:
admin> read ip-global
IP-GLOBAL read
admin> set rip-pref = 150
admin> write
IP-GLOBAL written
Poisoning routes to force the use of a redundant Ascend unit
If you have another Ascend unit backing up the MAX TNT in a redundant configuration on the same network, you can set the Dialout-Poison parameter to let the redundant unit take over when necessary. If you set the parameter to Yes, and for any reason the MAX TNT unit's trunks experience an alarm condition, the MAX TNT stops advertising IP routes that use dial services. With a setting of No, the unit continues to advertise its dial-out routes, which prevents the redundant unit from taking over the routing load. Set the parameter as follows if you want the MAX TNT to allow a redundant unit to take over.
admin> read ip-global
IP-GLOBAL read
admin> set dialout-poison = yes
admin> write
IP-GLOBAL written
Limiting the size of UDP packet queues
When the router is very busy and receives a flood of UDP packets from SNMP requests or RIP updates, a backlog of packets waiting for processing can create enough delay in routing to cause sporadic problems with time-sensitive packets, such as LCP negotiation or Frame Relay management packets.
To prevent such problems, UDP processing runs at a lower priority than processing of routed packets. On a system busily routing packets, this could mean that UDP processing is delayed, and a backlog of UDP packets builds up. The RIP-Queue-Depth parameter in the IP-Global profile and the Queue-Depth parameter in the SNMP profile specify the maximum size of this backlog.
When you set one of these parameters to specify a queue depth, the MAX TNT is more likely to drop UDP packets when it is busy routing packets. However, time-sensitive routed packets are less likely to be delayed and system memory is used more efficiently.
In the following example, the administrator sets both queue depths to 50. Fifty of each type of packet will be held for processing, and if additional packets of either type are received when the queue is full, they will be dropped.
admin> read ip-global
IP-GLOBAL read
admin> set rip-queue-depth = 50
admin> write
IP-GLOBAL written
admin> read snmp
SNMP read
admin> set queue-depth = 50
admin> write
SNMP written
The Netstat command output shows the queue depth of various UDP ports, as well as the total packets received and total packets dropped on each port. The total packets received count includes the total packets dropped. In the following example, the SNMP queue depth was set to 32:
admin> netstat udp
udp:
Socket Local Port InQLen InQMax InQDrops Total Rx
0 1023 0 1 0 0
1 route 0 50 0 509
2 echo 0 32 0 0
3 ntp 0 32 0 0
4 1022 0 128 0 0
5 SNMP 32 32 5837 20849
Ignoring default routes when updating the routing table
Ignore-Def-Route prevents routing updates from modifying the default route in the routing table. (This configuration is recommended.) The following set of commands protects the default route from RIP updates:
admin> read ip-global
IP-GLOBAL read
admin> set ignore-def-route = yes
admin> write
IP-GLOBAL written
Suppressing host-route advertisements
If you set the Suppress-Host-Routes parameter to Yes, routes are suppressed according to the following rules:
- If a Connection profile specifies a subnet mask less than 32 bits in the Remote-Address setting, host routes for the interface are suppressed while the session is being negotiated, and after the session is established, only network routes are advertised for the interface.
- If a Connection profile specifies a subnet mask of /32 in the Remote-Address setting, host routes for the interface are not suppressed. (Pool addresses also have a 32-bit mask, so they are not suppressed.)
The following set of commands configures the router to suppress host routes for connections that specify a subnet mask less than 32 bits:
admin> read ip-global
IP-GLOBAL read
admin> set suppress-host-routes = yes
admin> write
IP-GLOBAL written
Setting IP route and IP port cache options
The following parameters, shown with default settings, define how the system handles intra-shelf and inter-shelf routing and route caching:
[in IP-GLOBAL]
iproute-cache-enable = yes
iproute-cache-size = 0
ipport-cache-enable = yes
Route caches
The global routing table, maintained on the shelf-controller, is used to route packets internally to the correct interface. To offload some of the routing overhead and improve performance, the MAX TNT uses route caches on each slot card. Route caches work as follows:
- When a modem or HDLC card receives an IP packet, it forwards the packet to the shelf-controller, which routes it to the proper slot (an Ethernet card, for example).
- When the shelf-controller routes the packet, it writes a cache entry that is downloaded to the route cache of each slot card.
- When the modem or HDLC card receives another IP packet with the same destination address, it checks its route cache and forwards the packet directly to the proper slot, without involving the shelf-controller.
The shelf-controller retains responsibility for managing routing protocols, the global routing table, and the route caches themselves. But each slot card is able to check a small IP cache and route packets to a destination interface without involving the shelf-controller. When a slot card receives an IP packet for which it has no cache entry, it forwards that packet to the shelf-controller, which routes the packet and writes a cache entry to all slot cards.
Port caches
Like IP route caches, port caches offload the shelf-controller by enabling slot cards to manage their own affairs. While route caches enable the cards to look up a destination interface for outbound traffic, port caches enable the cards to route traffic that is directed to the MAX TNT itself at a higher protocol layer, such as the traffic in a TCP-Clear session.
In a TCP-Clear session, for example, a TCP connection is established between a host slot card (such as a modem card) and a local host that is accessible through one of the MAX TNT unit's Ethernet ports. The modem card creates TCP packets containing the client's data stream and sends them to the server. IP route caching enables the modem card to send the TCP packets directly to the Ethernet card, rather than going through the shelf-controller. However, when the local host returns packets to the dial-in client, there is no IP route cache, because the packet is destined for the MAX TNT system itself. So the packets are delivered to the router, which forward them to the modem card by means of the destination port number.
If the IP-Port-Cache-Enable parameter is set to Yes (the default value), packets destined for the MAX TNT are routed from the slot card that receives them (such as the Ethernet card) to the destination slot card (such as the modem card) directly, rather than going through the shelf-controller.
Enabling protocol options
The following parameters (shown with default settings) configure TCP/IP protocol options:
[in IP-GLOBAL]
bootp-enabled = no
rarp-enabled = no
udp-cksum = yes
tcp-timeout = 0
finger = no
[in IP-GLOBAL:bootp-relay]
active = no
[in IP-GLOBAL:bootp-relay:bootp-servers]
bootp-servers[1] = 0.0.0.0
bootp-servers[2] = 0.0.0.0
[in IP-GLOBAL:sntp-info]
enabled = no
gmt-offset = utc+0000
host = [0.0.0.0 0.0.0.0 0.0.0.0]
[in IP-GLOBAL:sntp-info:host]
host[1] = 0.0.0.0
host[2] = 0.0.0.0
host[3] = 0.0.0.0
Enabling Bootstrap Protocol and Reverse-ARP
The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that enables a host to obtain its configuration dynamically from a BOOTP server. Reverse-ARP (RARP) enables a host to obtain its address from a RARP server. The following commands enable both BOOTP and RARP:
admin> read ip-global
IP-GLOBAL read
admin> set bootp-enabled = yes
admin> set rarp-enabled = yes
admin> write
IP-GLOBAL written
Enabling UDP checksums
If data integrity is of the highest concern for your network, and redundant checks are important, you can turn on UDP checksums to generate a checksum whenever a UDP packet is transmitted. UDP packets are transmitted for queries and responses related to ATMP, SYSLOG, DNS, ECHOSERV, RADIUS, TACACS, RIP, SNTP, and TFTP.
The following commands enable UDP checksums for transmitted packets:
admin> read ip-global
IP-GLOBAL read
admin> set udp-cksum = yes
admin> write
IP-GLOBAL written
Setting a TCP timeout
The TCP-Timeout parameter adjusts the TCP retry timer. At the default value (0), the system attempts a fixed number of retries at escalating intervals adding up to about 170 seconds total. (Other limits in the system terminate TCP retries after about 170 seconds, even if the parameter is set to a higher number.) If you set TCP-Timeout to a nonzero value, the value specifies the number of seconds TCP retries persist. After the specified number of seconds, the retries stop and the connection is considered lost.
TCP-Timeout applies to all TCP connections initiated from the MAX TNT, including Telnet, Rlogin, TCP-clear, and the TCP portion of DNS queries. It applies to established TCP connections as well as to initial attempts to connect. You might adjust the TCP retry timer because, for example, when a user employs client software to enter a host name in a terminal server session, and DNS returns a list of IP addresses for the host, if the first address proves unreachable and the timeout on each attempt is long, the client software often times out before finding a good address.
The following commands set the timeout to 50 seconds:
admin> read ip-global
IP-GLOBAL read
admin> set tcp-timeout = 50
admin> write
IP-GLOBAL written
The optimal setting for the TCP-Timeout parameter must be determined by experience. It depends on the characteristics of the TCP destination (server) hosts. For example, if the destinations are all on a LAN under the same administrative control as the MAX TNT and are lightly loaded, then a short timeout (such as a few seconds) might be reasonable, because a host that does not respond within that interval is probably down. Conversely, if the environment includes servers with longer network latency times (for example, those connected across the WAN), or load is high in the network or the router, or the characteristics of the remote hosts are not well known, a longer timeout is appropriate. Values of 30 to 60 seconds are common in UNIX TCP implementations.
Enabling response to Finger queries
If Finger (described in RFC 1288) is enabled in the IP-Global profile, the MAX TNT can return user information to a remote Finger query. The following commands enable the MAX TNT to accept Finger queries and return the requested active session details to a remote client:
admin> read ip-global
IP-GLOBAL read
admin> set finger = yes
admin> write
IP-GLOBAL written
When the Finger parameter is set to Yes, a client (such as a UNIX client) can request session information for the system named TNT1 by using the following command:
# finger @tnt1
The above command displays the information in narrow (80-character wide) format. The client can request the information in wide format by using the command with the -l option. For example, the following command:
# finger -l @tnt1
displays 140-character-wide format of session information for the system named TNT1. The client can also request the details of all sessions, or of a single session. For example, to request information about a single user named Gavin:
# finger gavin@tnt1
The Finger forwarding service is not supported. It uses the following hostname format :
@host1@host2
A remote client that uses the forwarding request format receives the following message:
Finger forwarding service denied.
Enabling BOOTP-Relay
If a host requesting an address and a BOOTP server do not reside on the same IP network, an intervening system is required to transfer messages between the client and server. The intervening host is a BOOTP Relay Agent.
The following commands enable the BOOTP Relay feature and specify the address of a BOOTP server.
admin> read ip-global
IP-GLOBAL read
admin> list bootp-relay
[in IP-GLOBAL:bootp-relay]
active = no
bootp-servers = [ 0.0.0.0 0.0.0.0 ]
admin> set active = yes
admin> set bootp-servers 1 = 10.178.10.125
admin> write
IP-GLOBAL written
If more than one server is specified, the MAX TNT uses the first server until it becomes unavailable. Once it starts using the second server, it continues using that server until it becomes unavailable, at which time it switches back to using the first server again.
For information about configuring BOOTP-Relay to access a DHCP server in support of DSLPipe Plug & Play, see the MAX TNT Hardware Installation Guide.
Using SNTP to set and maintain the MAX TNT system time
The MAX TNT can use Simple Network Time Protocol (SNTP), which is described in RFC 1305, to set and maintain its system time by communicating with an SNTP server.
You specify the system's time zone as an offset from the Universal Time Configuration (UTC). UTC is in the same time zone as Greenwich Mean Time (GMT). The offset specifies hours and minutes from UTC using a 24-hour clock. Because some time zones, such as Newfoundland, do not have an even hour boundary, the offset includes four digits and requires half-hour increments.
For example, in Newfoundland the time is 1.5 hours earlier UTC, so the offset is UTC -0130. For San Francisco, which is 8 hours earlier UTC, the offset is UTC -0800. For Frankfurt, which is 1 hour later than UTC, it is UTC +0100.
The commands in the following example specify the time zone for San Francisco and the address of one SNTP server:
admin> read ip-global
IP-GLOBAL read
admin> list sntp-info
enabled = no
gmt-offset = utc+0000
host = [0.0.0.0 0.0.0.0 0.0.0.0]
admin> set enabled = yes
admin> set gmt = utc-0800
admin> set host 1 = 10.2.3.4
admin> write
IP-GLOBAL written
The MAX TNT always communicates with the first address unless it is inaccessible. In that case, the MAX TNT attempts to communicate with the second address, trying the third address only if the other two are inaccessible.
Configuring DNS
Domain Name System (DNS) is a TCP/IP service for centralized management of address resolution. Service providers can maintain multiple DNS servers, each one dedicated to a particular client or location. In that case, it might be important for security reasons to ensure that connections are always directed to the correct DNS service. With per-connection DNS access, a service provider can direct specific users to the DNS servers appropriate to their services or locations.)
In the MAX TNT, DNS configuration includes settings for enabling local DNS lookups and supporting DNS list, settings for a local DNS table maintained in RAM, and client DNS, for directing connections to a particular DNS service.
Configuring DNS lookups and DNS list
Following are the parameters (shown with default settings) for configuring DNS to allow lookups and support DNS list:
[in IP-GLOBAL]
domain-name = ""
dns-primary-server = 0.0.0.0
dns-secondary-server = 0.0.0.0
netbios-primary-ns = 0.0.0.0
netbios-secondary-ns = 0.0.0.0
dns-list-attempt = no
dns-list-size = 6
sec-domain-name = ""
Specifying domain names for lookups
When the MAX TNT receives a host name to look up, it tries various combinations, including appending the domain name specified in the IP-Global profile. The following commands specify a primary and secondary domain name for DNS lookups:
admin> read ip-global
IP-GLOBAL read
admin> set domain-name = abc.com
admin> set sec-domain-name = eng.abc.com
admin> write
IP-GLOBAL written
If a lookup fails in the first domain name, the router tries again with the secondary domain name.
Specifying local DNS server addresses
To enable the MAX TNT to look up addresses via DNS, specify DNS server addresses as shown in the following example:
admin> read ip-global
IP-GLOBAL read
admin> set dns-pri = 10.2.3.56
admin> set dns-sec = 10.2.3.107
admin> write
IP-GLOBAL written
If the primary server is unavailable, the MAX TNT attempts a lookup on the secondary server. To execute a lookup manually, use the Nslookup command. For example:
admin> nslookup techpubs
Resolving host techpubs.
IP address for host techpubs is 10.6.212.19.
Local DNS servers provide information about the local network, and are sometimes isolated from incoming callers for security purposes. For details, see Using client DNS.
Supporting DNS list
Some DNS servers support a list feature that enables them to return multiple addresses for a host name in response to a DNS query. However, the responses do not include information about availability of the hosts in the list. Users typically attempt to access the first address in the list. If that host is unavailable, the user must try the next host, and so forth.
When the DNS list is used for an immediate connection by a dial-in user (for example, an immediate Telnet connection to a local host), and the first attempt fails, the physical connection is torn down.To avoid tearing down physical links when hosts are unavailable, you can support DNS list in the MAX TNT. The following example shows how to enable DNS list with a maximum of 14 hosts in the list:
admin> read ip-global
IP-GLOBAL read
admin> set dns-list-attempt = yes
admin> set dns-list-size = 14
admin> write
IP-GLOBAL written
(For related information, see Using the Auto-Update feature.)
Setting up a local DNS table
The MAX TNT can maintain in RAM a DNS table of up to 8 host names and their IP addresses. It consults the table in RAM for address resolution only if requests to the DNS server fail. The local table acts as a safeguard to ensure that the MAX TNT can resolve the local set of DNS names in case all DNS servers become unreachable or go down.
The local DNS table is propagated to RAM from a configured DNS-Local-Table subprofile in the IP-Global profile. At startup, the system copies values in the profile to the table in RAM. If the administrator subsequently modifies the DNS-Local-Table subprofile, the changes are propagated to the table in RAM when the profile is written.
The DNS table in RAM has space for up to 35 IP addresses per Host-Name entry (the limit set by the maximum DNS-List-Size). The DNS-Local-Table subprofile allows a single IP address per host name. (For related information, see Using the Auto-Update feature.)
To set up the local DNS table, the administrator configures the following parameters (shown with their default values) in the IP-Global profile:
[in IP-GLOBAL:dns-local-table]
enabled = no
auto-update = no
[in IP-GLOBAL:dns-local-table:table-config]
table-config [1] = {"" 0.0.0.0}
table-config [2] = {"" 0.0.0.0}
table-config [3] = {"" 0.0.0.0}
table-config [4] = {"" 0.0.0.0}
table-config [5] = {"" 0.0.0.0}
table-config [6] = {"" 0.0.0.0}
table-config [7] = {"" 0.0.0.0}
table-config [8] = {"" 0.0.0.0}
[in IP-GLOBAL:dns-local-table:table-config[1]]
host-name = ""
ip-address = 0.0.0.0
Host name matching
A host name in the local DNS table must start with an alphabetic character and must have fewer than 256 characters. Trailing periods are ignored in the comparison.
The name may be a host name or a fully qualified domain name. If the name does not include a domain name, and the administrator has specified one or more Domain-Name settings (see Configuring DNS), the system appends the specified domain name when looking up the host name. For example, for a DNS query on the following host name:
host-name = wheelers
The MAX TNT searches for the host name and for the following domain names:
wheelers.eng.abc.com
wheelers.abc.com
Defining the local table
Following is an example of configuring a local table that specifies three hosts:
admin> read ip-global
IP-GLOBAL read
admin> list dns-local
enabled = no
auto-update = no
table-config = [ { "" 0.0.0.0 } {"" 0.0.0.0 } {"" 0.0.0.0 } {"" 0.0.0.0+
admin> set enabled = yes
admin> list table 1
hostname = ""
ip-address = 0.0.0.0
admin> set host = host1.abc.com
admin> set ip = 10.1.2.3
admin> list ..
table-config[1] = { host1.abc.com 10.1.2.3 }
table-config[2] = { "" 0.0.0.0 }
table-config[3] = { "" 0.0.0.0 }
table-config[4] = { "" 0.0.0.0 }
table-config[5] = { "" 0.0.0.0 }
table-config[6] = { "" 0.0.0.0 }
table-config[7] = { "" 0.0.0.0 }
table-config[8] = { "" 0.0.0.0 }
admin> set 2 host = host2.xyz.
admin> set 2 ip = 11.1.2.3
admin> set 3 host = localhost
admin> set 3 ip = 10.0.0.1
admin> write
IP-GLOBAL written
If you specify an IP address without also specifying a host name, a message such as the following appears when you write the profile:
error: dns-local-table: host-name missing (#3 1.2.3.4)
If you enter an invalid host name, a message such as the following appears when you write the profile:
error: dns-local-table: host-name must start with alpha char (#5 11foo)
Using the Auto-Update feature
If the Auto-Update parameter is set to No (the default), successful DNS queries do not affect the contents of the local table. With a setting of Yes, when a regular DNS query succeeds, the system performs a lookup on that host name in the local table. If there is an entry for the host name, the entry's IP address(es) is replaced by the query response. The following parameters, which are shown with their default values, affect how the table is updated when Auto-Update is set to Yes:
[in IP-GLOBAL]
dns-list-attempt = no
dns-list-size = 6
If DNS-List-Attempt is set to No, a successful DNS query returns a single address for a given host name. In the DNS table in RAM, that address is stored and the remaining 34 addresses are cleared (set to zero).
If DNS-List-Attempt is set to Yes, a successful DNS query returns the number of addresses it finds for the host, up to DNS-List-Size. In the DNS table in RAM, those addresses are stored, overwriting the configured address or the addresses retrieved from earlier DNS queries. If the table in RAM contains more addresses than DNS-List-Size specifies, the excess addresses are cleared at each update, to prevent the accumulation of stale addresses.
Note: If the administrator modifies the DNS-Local-Table subprofile, assigning a single address to a host, the newly configured address is propagated to the table in RAM. The first address of the Host-Name entry is overwritten with the configured address, and all remaining addresses are cleared. If Auto-Update is set to Yes, the next successful DNS query overwrites the configured address and restores the multiple addresses (up to DNS-List-Size).
In the following example, the administrator configures 8 host names with null addresses and then sets Auto-Update to Yes. The DNS-Local-Table changes will be propagated to RAM, and successful DNS queries to the specified host names will build the table with up to 14 addresses for each of the hosts.
admin> read ip-global
IP-GLOBAL read
admin> set dns-list-attempt = yes
admin> set dns-list-size = 14
admin> list dns-local
enabled = no
auto-update = no
table-config = [ { "" 0.0.0.0 } {"" 0.0.0.0 } {"" 0.0.0.0 } {"" 0.0.0.0+
admin> set enabled = yes
admin> set auto-update = yes
admin> list table
table-config[1] = { "" 0.0.0.0 }
table-config[2] = { "" 0.0.0.0 }
table-config[3] = { "" 0.0.0.0 }
table-config[4] = { "" 0.0.0.0 }
table-config[5] = { "" 0.0.0.0 }
table-config[6] = { "" 0.0.0.0 }
table-config[7] = { "" 0.0.0.0 }
table-config[8] = { "" 0.0.0.0 }
admin> set 1 host = mercury
admin> set 2 host = venus
admin> set 3 host = earth
admin> set 4 host = mars
admin> set 5 host = jupiter
admin> set 6 host = saturn
admin> set 7 host = uranus
admin> set 8 host = neptune
admin> write
IP-GLOBAL written
Using client DNS
Client DNS specifies particular servers for dial-in clients. ISPs use client DNS to direct callers to servers belonging to particular locations or customers, and to prevent those callers from accessing other clients' host information.
Client DNS can be specified system-wide to allow all dial-in clients access to one or two DNS servers. Or it can be configured on a connection basis, to allow that connection to access one or two specific servers. At the system level, client DNS also provides an exit mechanism to the local servers if the client servers are inaccessible.
The addresses configured for client DNS servers are presented to WAN connections during IPCP negotiation.
Overview of client DNS settings
You can configure client DNS at the system level in the IP-Global profile. At the connection level, you can specify client DNS servers in Connection or RADIUS profiles.
Settings in the IP-Global profile
The following parameters (shown with default values) specify client DNS at the system level:
[in IP-GLOBAL]
client-primary-dns-server = 0.0.0.0
client-secondary-dns-server = 0.0.0.0
allow-as-client-dns-info = true
Settings in Connection profiles
The following parameters (shown with default settings) specify client DNS at the connection level:
[in CONNECTION/"":ip-options]
client-dns-primary-addr = 0.0.0.0
client-dns-secondary-addr = 0.0.0.0
client-dns-addr-assign = yes
Settings in a RADIUS profile
The following attribute-value pairs configure client DNS in RADIUS profiles:
Example of configuring client DNS servers at the system level
The following commands configure client DNS servers at the system level:
admin> read ip-global
IP-GLOBAL read
admin> set client-dns-pri = 10.22.17.56
admin> set client-dns-sec = 10.22.17.107
admin> set allow-as-client-dns-info = false
admin> write
IP-GLOBAL written
The secondary server is accessed only if the primary one is inaccessible. If both of these client DNS servers are not accessible and the caller's profile does not specify client DNS servers, the MAX TNT does not allow the client to access local DNS servers.
Examples of configuring client DNS at the connection level
The following commands identify two DNS servers for this connection. The secondary server is accessed only if the primary one is inaccessible.
admin> read connection cherry
CONNECTION/cherry read
admin> set ip-options client-dns-primary-addr = 10.2.3.4
admin> set ip-options client-dns-secondary-addr = 10.2.3.56
admin> set ip-options client-dns-addr-assign = yes
admin> write
CONNECTION/cherry written
Following are comparable settings in a RADIUS profile:
cherry Password = "localpw"
User-Service = Framed-User,
Ascend-Client-Primary-DNS = 10.2.3.4,
Ascend-Client-Secondary-DNS = 10.2.3.56,
Ascend-Client-Assign-DNS = DNS-Assign-Yes
Configuring and using address pools
An address pool is a range of contiguous addresses on a local IP network or subnet. Pool addresses are available for assignment to incoming callers that request an address. When the call terminates, the address is returned to the pool so it is available again for assignment.
If you designate a subnet for IP address pools, you must make sure that other IP hosts on the local network know the route to that subnet. You must also make sure that the pools do not overlap (do not contain duplicate addresses).
See Defining address pools for a VRouter for related information.
Overview of settings for defining pools
You can define up to 128 address pools locally in the IP-Global profile. Those pools can be used to assign addresses to callers authenticated locally (in Connection profiles) or by RADIUS. If you are using RADIUS authentication, you can choose to define address pools in RADIUS instead, or in addition to, those defined locally. If you have the RADIPAD program installed, you can use it to manage address pools centrally, on a single RADIUS server. For details on installing RADIPAD, see the MAX TNT RADIUS Guide.
Settings in the IP-Global profiles
The following parameters (shown with default values) configure address pools locally:
[in IP-GLOBAL]
pool-summary = no
pool-ospf-adv-type = type-1
pool-base-address = [ 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.+
assign-count = [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0+
pool-name = [ "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""+
Settings in RADIUS pseudo-user profiles
You can define address pools in a RADIUS pools pseudo-user profile. A pools pseudo-user profile uses the following format on its first line:
pools-name Password = "ascend", User-Service = Dialout-Framed-User
The name argument is the MAX TNT system name (specified by the Name parameter in the System profile). Subsequent lines in the profile define IP address pools by using the Ascend-IP-Pool-Definition (217) attribute. The value of the Ascend-IP-Pool-Definition attribute uses the following syntax:
"pool-num base-addr assign-count"
Global RADIUS pools (RADIPAD)
RADIUS IP Address Daemon (RADIPAD) is a program that works with RADIUS authentication to manage IP address pools centrally, so that connections can all acquire an address from a global pool, regardless of which system answers the call.
RADIPAD runs on one RADIUS server on the network. A MAX TNT sends an authentication request to RADIUS, and if the user profile contains an attribute to allocate an IP address from the global pool, RADIUS sends a request to RADIPAD to acquire the address.
The MAX TNT does not talk directly to RADIPAD, so it does not require additional configuration to use RADIPAD. To configure RADIPAD, you define the global pools of addresses, specify which RADIUS server is running RADIPAD, and (optionally) specify which MAX TNT or other Ascend units can obtain addresses from those pools. You can then create RADIUS user profiles that acquire an IP address from the global pool.
At startup, Syslog notes RADIUS requests to release RADIUS-allocated IP addresses. Some versions of the RADIUS server may time out the request, resulting in log messages indicating the release of global-pool addresses.
Defining global pools
Global address pools are defined in a global-pool pseudo-user profile on the server running RADIPAD. The first line of a global-pool pseudo-user profile uses the following format:
global-pools-name Password = "ascend", User-Service = Dialout-Framed-User
The name argument is a designation for any class of users. You can create multiple global pool profiles for multiple user classes. For example, you could create profiles named Global-Pool-PPP, Global-Pool-SLIP, and so forth. Subsequent lines in the profile define IP address pools by using the Ascend-IP-Pool-Definition (217) attribute. This is the same attribute described in Settings in RADIUS pseudo-user profiles, and it follows the same rules for global pools.
In addition to the definitions described in the preceding section for Ascend-IP-Pool-Definition (217), when the MAX TNT assigns an address from a pool managed by the RADIPAD daemon, RADIPAD tries to allocate an address from the pools in order (by pool number), and chooses an address from the pool with the first available IP address.
Specifying the RADIPAD host
In addition, each RADIUS server must specify the host running RADIPAD and (optionally) the Ascend units that can access the global pools. These settings are defined in a radipa-hosts pseudo-user profile, which uses the following format on the first line of the profile:
radipa-hosts Password = "ascend", User-Service = Dialout-Framed-User
Subsequent lines in the profile define which Ascend units can assign addresses from the pools managed by RADIPAD, using the following attribute value pairs:
For example:
radipa-hosts Password ="ascend", User-Service = Dialout-Framed-User
Ascend-Assign-IP-Server = 10.31.4.34,
Ascend-Assign-IP-Client = 10.31.4.10,
Ascend-Assign-IP-Client = 10.31.4.11
You can specify only one RADIPAD server, but can include multiple clients. The sample profile indicates that two Ascend units (10.31.4.10 and 10.31.4.11) can access RADIPAD pools as clients.
Examples of configuring address pools
For a pool that is not summarized, each assigned address is advertised as its own host route. Such a pool can start at any base address. Addresses do not accept a subnet mask component, because they are always advertised as host routes.
The following commands define three address pools, each containing 50 addresses. Pool 1 contains 10.2.3.4 through 10.2.3.54. Pool 2 contains 11.5.7.51 through 11.5.7.101. Pool 3 contains 12.7.112.15 through 12.7.112.65.
admin> read ip-global
IP-GLOBAL read
admin> set pool-base-address 1 = 10.2.3.4
admin> set pool-base-address 2 = 11.5.7.51
admin> set pool-base-address 3 = 12.7.112.15
admin> set assign-count 1 = 50
admin> set assign-count 2 = 50
admin> set assign-count 3 = 50
admin> write
IP-GLOBAL written
Following is a comparable RADIUS pools profile (for use by a single RADIUS server):
pools-tnt01 Password = "ascend", User-Service = Dialout-Framed-User
Ascend-IP-Pool-Definition = "1 10.2.3.4 50",
Ascend-IP-Pool-Definition = "2 11.5.7.51 50",
Ascend-IP-Pool-Definition = "3 12.7.112.15 50"
Following is a comparable global pools definition (for use with RADIPAD):
global-pool-ppp Password ="ascend", User-Service = Dialout-Framed-User
Ascend-IP-Pool-Definition = "1 10.2.3.4 50",
Ascend-IP-Pool-Definition = "2 11.5.7.51 50",
Ascend-IP-Pool-Definition = "3 12.7.112.15 50"
Although some client software assumes a default 255.255.255.0 netmask for PPP interfaces, you can define pools on networks wider than /24. For example, the following commands define an address pool on a /23 network:
admin> read ip-global
IP-GLOBAL read
admin> set pool-base-address 1 = 10.55.178.1
admin> set assign-count 1 = 510
admin> write
IP-GLOBAL written
This pool definition translates to 10.55.178.0/23 (a subnet mask of 255.255.252.0). Following are comparable RADIUS definitions:
pools-tnt01 Password = "ascend", User-Service = Dialout-Framed-User
Ascend-IP-Pool-Definition = "1 10.55.178.1 510"
global-pool-ppp Password ="ascend", User-Service = Dialout-Framed-User
Ascend-IP-Pool-Definition = "1 10.55.178.1 510"
Note: If you define address pools that contain more than 254 addresses, be aware that the system allocates the class boundary addresses ( x.y.z.0 and x.y.z.255) as valid caller addresses. According to CIDR, this is permitted because the pool is not a /24 network. However, some client systems, such as Windows, do not tolerate the class boundary addresses well. For example, because Windows assumes a /24 network, it broadcasts NetBIOS over IP name service to the .255 address, which could swamp a connection assigned the .255 host address.
To prevent client software from using a host address for broadcasts, you must explicitly apply a filter that prevents the system from using the class boundary addresses. For example, if you are using RADIUS authentication, you can apply a data filter in the Answer-Defaults profile that drops packets from any source to pool address x.y.z.0 and x.y.z.255.
Examples of configuring summarized address pools
The Pool-Summary feature reduces routing overhead associated with address pools. Instead of advertising each address assigned from a pool as a host route, the MAX TNT suppresses the host route advertisements and instead advertises a static route to the pool itself.
To use summarized pools locally or in RADIUS, you must set the Pool-Summary flag to Yes in the IP-Global profile. When Pool-Summary is set to Yes, all pools should be network-aligned.
Setting the Pool-Summary flag
The following commands enable the Pool-Summary flag:
admin> read ip-global
IP-GLOBAL read
admin> set pool-summary = yes
admin> write
IP-GLOBAL written
Defining network-aligned pools
Following are the rules for network-aligned address pools:
The following commands enable the Pool-Summary flag and define a network-aligned pool:
admin> read ip-global
IP-GLOBAL read
admin> set pool-summary = yes
admin> set assign-count 1 = 62
admin> set pool-base-address 1 = 10.12.253.1
admin> write
IP-GLOBAL written
In the example commands, the Assign-Count is set to 62. When you add two to the Assign-Count, you get 64. The subnet mask for 64 addresses is 255.255.255.192 (256-64 = 192). The Ascend subnet notation for a 255.255.255.192 mask is /26.
The Pool-Base-Address is set to 10.12.253.1. When you subtract one from this address, you get 10.12.253.0, which is a valid network-aligned base address for the 255.255.255.192 subnet mask. (Note that 10.12.253.64, 10.12.253.128, and 10.12.253.192 are also valid zero addresses for the same mask.) The resulting address pool subnet is 10.12.253.0/26.
Following is a comparable RADIUS pools profile (for use by a single RADIUS server):
pools-tnt01 Password = "ascend", User-Service = Dialout-Framed-User
Ascend-IP-Pool-Definition = "1 10.12.253.1 62"
Following is a comparable global pools definition (for use with RADIPAD):
global-pool-ppp Password ="ascend", User-Service = Dialout-Framed-User
Ascend-IP-Pool-Definition = "1 10.12.253.1 62"
The MAX TNT still creates (but does not advertise) a host route for each assigned address in the pool. Host routes take precedence over subnet routes, so packets whose destination matches an assigned IP address from the pool are routed properly. However, because the MAX TNT advertises the entire pool as a route, and only privately knows which IP addresses in the pool are active, a remote network might improperly send the MAX TNT a packet for an inactive IP address.If that occurs, the packets are routed to the Reject (rj0) interface (127.0.0.2). Packets routed to the Reject interface are bounced back to the sender with an ICMP unreachable message.
Examples of assigning an address from a pool
When an incoming call requests an IP address, the MAX TNT assigns one from a pool. A host requests an address by configuring its client software with settings such as the following:
Username=victor
Accept Assigned IP=Yes
IP address=Dynamic (or Assigned or N/A)
Netmask=255.255.255.255 (or None or N/A)
Default Gateway=None or N/A
Name Server=10.2.3.55
Domain suffix=abc.com
Baud rate=38400
Hardware handshaking ON
VAN Jacobsen compression ON
Figure 4-10 shows a dial-in host requesting and being assigned an IP address:
Figure 4-10. Dial-in host requiring assigned IP address
The following commands enable dynamic address assignment system-wide:
admin> read answer
ANSWER-DEFAULTS read
admin> set ip-answer assign = yes
admin> write
ANSWER-DEFAULTS written
For information about ensuring that connections must accept the address offered, see Requiring acceptance of dynamic address assignment.
The following commands configure a profile to acquire an address from the first pool that has available addresses (Pool 0):
admin> new conn victor
CONNECTION/victor read
admin> set active = yes
admin> set encapsulation-protocol = ppp
admin> set ppp recv-password = localpw
admin> set ip-options address-pool = 0
admin> write
CONNECTION/victor written
Following is a comparable RADIUS profile:
victor Password = "localpw"
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Assign-IP-Pool = 0
Following is a comparable RADIUS profile that acquires an address from any global pool managed by the RADIPAD daemon:
victor Password = "localpw"
User-Service = Framed-User,
Framed-Protocol = PPP,
Ascend-Assign-IP-Global-Pool ="global-pool-ppp"
Setting up multicast forwarding
Video and audio transmissions use one-to-many and many-to-many communication, rather than the point-to-point communications that many other types of network applications use. This type of transmission is provided by the IP Multicast Backbone (MBONE) as a much cheaper and faster way to communicate the same information to multiple hosts.
MBONE routers maintain multicast groups, in which hosts must register to receive a multicast transmission. Multicast group functions are handled using the Internet Group Management Protocol (IGMP). The MAX TNT forwards IGMP version-1 or version-2 packets, including IGMP MTRACE (multicast trace).
Figure 4-11 shows a MAX TNT forwarding multicast traffic from an MBONE router across the WAN to two WAN multicast client interfaces and a LAN multicast client interface:
Figure 4-11. MAX TNT forwarding multicast traffic to LAN and WAN clients
The interface to the MBONE router is the MBONE interface. The MAX TNT can have one and only one MBONE interface, which can be either a LAN or WAN IP interface.
To MBONE routers, the MAX TNT appears to be a multicast client, because it responds as a client to IGMP packets. To multicast clients, the MAX TNT appears to be an MBONE router, because it forwards IGMP queries to those clients, receives their responses, and forwards multicast traffic.
Global settings for enabling multicast forwarding
The following parameters (shown with default settings) initiate multicast forwarding at the system level:
[in IP-GLOBAL]
multicast-forwarding = no
mbone-profile = ""
mbone-lan-interface = { { any-shelf any-slot 0 } 0 }
multicast-hbeat-addr = 0.0.0.0
multicast-hbeat-port = 0
multicast-hbeat-slot-time = 0
multicast-hbeat-number-slot = 0
multicast-hbeat-alarm-threshold = 0
multicast-hbeat-src-addr = 0.0.0.0
multicast-hbeat-src-addr-mask = 0.0.0.0
multicast-member-timeout = 360
Note: Heartbeat monitoring is optional. It is not required for multicast forwarding.
Specifying a timeout for group memberships
The Multicast-Member-Timeout parameter specifies the timeout (in seconds) for client responses to multicast polling messages. If no client responds to the polling messages within the amount of time you specify for Multicast-Member-Timeout, the MAX TNT stops forwarding multicast traffic on the interface. The following commands set the timeout value to 60 seconds:
admin> read ip-global
IP-GLOBAL read
admin> set multicast-member-timeout = 60
admin> write
IP-GLOBAL written
Monitoring the multicast traffic heartbeat
Heartbeat monitoring is optional. It enables administrators to monitor possible multicast connectivity problems by continuously polling for a certain level of multicast traffic and generating the following SNMP alarm trap in the event of a traffic breakdown:
Trap type: TRAP_ENTERPRISE
Code: TRAP_MULTICAST_TREE_BROKEN (19)
Arguments:
1) Multicast group address being monitored (4 bytes),
2) Source address of last heartbeat packet received (4 bytes)
3) Slot time interval configured in seconds (4 bytes),
4) Number of slots configured (4 bytes).
5) Total number of heartbeat packets received before the unit started sending SNMP Alarms (4 bytes).
Enabling heartbeat monitoring
To enable multicast heartbeat monitoring, you specify a polling frequency and the threshold below which the alarm is generated.
With the following sample configuration, the MAX TNT polls 10 times at 10-second intervals and then compares the total traffic count to the threshold value. If fewer than 30 packets have been received, it generates the SNMP alarm.
admin> read ip-global
IP-GLOBAL/ read
admin> set multicast-hbeat-slot-time = 10
admin> set multicast-hbeat-number-slot = 10
admin> set multicast-hbeat-alarm-threshold = 30
admin> write
IP-GLOBAL/ written
Specifying which packets to monitor
To fine-tune heartbeat monitoring, you can specify which packets the system should count as multicast traffic. You can do this in one or more of the following ways:
- Specify a particular multicast address to be used for monitoring.
- Specify a UDP port number (all packets received on that port will be used for monitoring).
- Specify a source address (all packets from that host will be ignored for monitoring purposes).
- Specify a subnet mask to be applied to the source address (all packets from the subnet or network will be ignored for monitoring purposes).
The following example shows how to monitor only packets forwarded to and received from the 224.1.1.1 multicast address.
admin> read ip-global
IP-GLOBAL/ read
admin> set multicast-hbeat-addr = 224.1.1.1
admin> write
IP-GLOBAL/ written
The next sample configuration limits monitoring to packets forwarded to and received from the multicast address 224.1.1.1 on UDP port 16387.
admin> read ip-global
IP-GLOBAL/ read
admin> set multicast-hbeat-addr = 224.1.1.1
admin> set multicast-hbeat-port = 16387
admin> write
IP-GLOBAL/ written
The following example shows how to specify that multicast packets from the 10.1.0.0 subnet will be ignored for heartbeat monitoring purposes:
admin> read ip-global
IP-GLOBAL/ read
admin> set multicast-hbeat-src-addr = 10.1.2.3
admin> set multicast-hbeat-src-addr-mask = 255.255.0.0
admin> write
IP-GLOBAL/ written
Configuring the MBONE interface
The MBONE interface is the single LAN or WAN IP interface on which an MBONE router resides. The MBONE interface cannot support multicast clients.
To enable the MAX TNT to forward traffic to and from an MBONE router, you must configure both the IP-Global settings and the appropriate settings in an IP-Interface or Connection profile.
Overview of MBONE interface settings
The following parameter (shown with its default setting) is used on the MBONE interface:
[in IP-INTERFACE/{ { any-shelf any-slot 0 } 0 } ]
multicast-allowed = no
[in CONNECTION/"":ip-options]
multicast-allowed = no
Example of a local MBONE router
Figure 4-12 shows an MBONE router on one of the system's LAN IP interfaces:
Figure 4-12. MBONE router on a LAN interface
The following commands configure the shelf-controller Ethernet port as the MBONE interface:
admin> read ip-global
IP-GLOBAL read
admin> set multicast-forwarding = yes
admin> set mbone-lan-interface = { {1 c 1} 0}
admin> write
IP-GLOBAL written
admin> read ip-interface {{1 c 1}0}
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } read
admin> set multicast-allowed = yes
admin> write
IP-INTERFACE/{ { shelf-1 controller 1 } 0 } written
Example of an MBONE router on a WAN interface
Figure 4-13 shows an MBONE router on a WAN interface:
Figure 4-13. MBONE router on a WAN interface
The following commands configure a switched WAN IP interface to the MBONE router:
admin> read ip-global
IP-GLOBAL read
admin> set multicast-forwarding = yes
admin> set mbone-profile = multicast-router
admin> write
IP-GLOBAL written
admin> read connection multicast-router
CONNECTION/multicast-router read
admin> set active = yes
admin> set encapsulation-protocol = mp
admin> set ip remote-address = 10.10.10.10/24
admin> set ip multicast-allowed = yes
admin> set ppp recv-password = localpw
admin> set mp base-channel-count = 12
admin> write
CONNECTION/multicast-router written
Configuring multicast client interfaces
The MAX TNT can forward multicast transmissions to any interface except the MBONE interface. To communicate with multicast clients (which are typically running Video Audio Tools (VAT) or Windows), the MAX TNT handles IGMP queries and responses and forwards the MBONE transmission it receives from the MBONE router.
Settings in local IP-Interface and Connection profiles
The parameters (shown with default settings) are used to set up a multicast client interface :
[in IP-INTERFACE/{ { any-shelf any-slot 0 } 0 } ]
multicast-allowed = no
multicast-rate-limit = 100
multicast-group-leave-delay = 0
[in CONNECTION /"":ip-options]
multicast-allowed = no
multicast-rate-limit = 100
multicast-group-leave-delay = 0
Settings in RADIUS profiles
The following attribute-value pairs can be specified in RADIUS profiles for WAN multicast client interfaces:
Setting the multicast rate limit
Multicast-Rate-Limit specifies the rate at which the MAX TNT accepts multicast packets from clients on the interface.
Note: By default, Multicast-Rate-Limit is set to 100. This disables multicast forwarding on the interface. (The forwarder handles IGMP packets, but does not accept packets from clients or forward multicast packets from the MBONE router.) To enable multicast forwarding on the interface, you must set the Multicast-Rate-Limit parameter to a number less than 100.
For example, if you set Multicast-Rate-Limit to 5, the MAX TNT accepts one packet every five seconds from multicast clients on the interface . Any subsequent packets received within that 5-second window are discarded.
For high-bandwidth data, voice, and audio multicast applications, the MAX TNT supports both multicast rate limiting (described immediately above) and prioritized packet dropping. If the MAX TNT is the receiving device under extremely high loads, it drops packets according to a priority ranking, which is determined by the following UDP port ranges:
- Traffic on ports 0-16384 (unclassified traffic) has the lowest priority (50).
- Traffic on ports 16385-32768 (Audio traffic) has the highest priority (70).
- Traffic on ports 32769-49152 (Whiteboard traffic) has medium priority (60).
- Traffic on ports 49153-65536 (Video traffic) has low priority (55).
Specifying a delay for clearing IGMP groups
Multicast-Group-Leave-Delay specifies the number of seconds the MAX TNT waits before forwarding to the MBONE router an IGMP version-2 Leave Group message it receives across a multicast client interface. Typically, these messages indicate that the IGMP group session can be cleared. However, a multicast interface in the MAX TNT can support many clients, some of which might establish multiple multicast sessions for identical groups, in which case a Leave Group message from a single client must be treated in a special way.
If Multicast-Group-Leave-Delay is set to zero (the default), the MAX TNT forwards the Leave Group messages immediately.
If you set Multicast-Group-Leave-Delay to a nonzero value, the MAX TNT does not immediate forward a Leave Group message it receives from a client on the interface. Instead, it sends back a query to make sure there are no clients on the interface with active multicast sessions for that group. If the MAX TNT receives a response before the specified Multicast-Group-Leave-Delay interval, it does not forward the Leave Group message. Otherwise, it forwards the message and clears the IGMP group session from its tables after the specified interval.
If users might establish multiple multicast sessions for identical groups, you should set this parameter to a value between 10 and 20.
Example of configuring a LAN multicast client interface
Figure 4-14 shows multicast clients on a LAN interface:
Figure 4-14. LAN multicast client interface
The following commands configure the LAN IP interface to forward multicast transmissions to subscribed multicast clients:
admin> read ip-interface {{1 6 1 0}
IP-INTERFACE/{ { shelf-1 slot-6 1 } 0 } read
admin> set multicast-allowed = yes
admin> set multicast-rate-limit = 5
admin> set multicast-group-leave-delay = 10
admin> write
IP-INTERFACE/{ { shelf-1 slot-6 1 } 0 } written
Examples of configuring WAN multicast client interfaces
Figure 4-15 shows multicast clients on WAN interfaces:
Figure 4-15. WAN multicast client interfaces
The following commands enable multicast forwarding on the WAN multicast client interfaces in Connection profiles named VAT-1, W98-1, and W95-1:
admin> read connection vat-1
CONNECTION/vat-1 read
admin> set ip multicast-allowed = yes
admin> set ip multicast-rate-limit = 5
admin> set ip multicast-group-leave-delay = 20
admin> write
CONNECTION/vat-1 written
admin> read connection w98-1
CONNECTION/w98-1 read
admin> set ip multicast-allowed = yes
admin> set ip multicast-rate-limit = 5
admin> set ip multicast-group-leave-delay = 20
admin> write
CONNECTION/w98-1 written
admin> read connection w95-1
CONNECTION/w95-1 read
admin> set ip multicast-allowed = yes
admin> set ip multicast-rate-limit = 5
admin> set ip multicast-group-leave-delay = 20
admin> write
CONNECTION/w95-1 written
Following are comparable settings in RADIUS profiles:
vat-1 Password = "vat1pw"
User-Service = Framed-User,
Ascend-Multicast-Client = Multicast-Yes,
Ascend-Multicast-GRP-Leave-Delay = 20,
Ascend-Multicast-Rate-Limit = 5
w98-1 Password = "w98-1pw"
User-Service = Framed-User,
Ascend-Multicast-Client = Multicast-Yes,
Ascend-Multicast-GRP-Leave-Delay = 20,
Ascend-Multicast-Rate-Limit = 5
w95-1 Password = "w95-1pw"
User-Service = Framed-User,
Ascend-Multicast-Client = Multicast-Yes,
Ascend-Multicast-GRP-Leave-Delay = 20,
Ascend-Multicast-Rate-Limit = 5
Configuring virtual routers
A Virtual Router (also called a VRouter) is a grouping of interfaces in the MAX TNT system. Each Virtual Router has its own associated routing table, ARP table, route cache, and address pools, and maintains its own routing and packet statistics.
If you don't configure any VRouters, the MAX TNT router operates exactly as it has in previous releases. When one or more VRouters are specified, the main router operates as the global VRouter. All interfaces that are not explicitly grouped with a defined VRouter are grouped with the global VRouter.
Figure 4-16 shows a MAX TNT with one VRouter operating for Corporation A. Interfaces related to Corporation A are grouped and handled by one VRouter, creating a Virtual Private Network for Corporation A. Corporation A's WAN interfaces can dial-in to a local MAX TNT, which may be on a public network, to reach Corporation A's private LANs.
Figure 4-16. Virtual IP routing
How VRouters affect the routing table
Before the introduction of VRouters, the MAX TNT maintained a single IP routing table that enabled the router to reach any of its many interfaces. In that context, each interface known to the system required a unique address.
With VRouters, addresses must be unique within the VRouter's routing domain, but not necessarily within the MAX TNT system. Because each VRouter maintains its own routing table, and because it knows about only those interfaces that explicitly specify the same VRouter, there is no requirement that the private networks maintain unique address spaces.
How VRouters affect network commands
The following commands now support virtual routing. If no VRouter name is specified on the command line, the global VRouter is assumed. If a VRouter name is specified, the command performs its usual function but applies only to the specified VRouter:
Current limitations
Currently, SNMP management does not present the view of the MAX TNT on per-VRouter basis. Errors and events are not logged on per-VRouter basis. The Syslog host defined in the system's Log profile must be accessible to the main VRouter.
Currently, ATMP presents incoming packets only to the main VRouter. In addition, servers defined in the following profiles must be accessible to the main VRouter:
- Debug
- SNTP
- Trap
- External-Auth
Creating a VRouter
When at least one VRouter profile is configured, the System-IP-Address parameter and the Global-VRouter parameter in the IP-Global profile apply to the global VRouter. All interfaces that are not explicitly assigned to another VRouter are grouped with the global VRouter.
For each VRouter in the system, an instance of RIP is created to process routes. The new instance of RIP sends and receives update packets only on the interfaces associated with its particular VRouter and manipulates only that VRouter's routing table. A default instance of RIP is always created for the global VRouter.
When you create a VRouter, the new instance of RIP sends and receives packets only on the interfaces associated with that VRouter and manipulates only that VRouter's routing table. All RIP-related parameters in a VRouter profile use default settings that are recommended for most sites.
Settings in a VRouter profile
A VRouter profile contains the following parameters, shown here with default values:
[in VROUTER/""]
name* = ""
vrouter-ip-address = 0.0.0.0
pool-base-address = [ 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0+
assign-count = [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 +
pool-name = [ "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""+
pool-summary = no
rip-policy = Poison-Rvrs
summarize-rip-routes = no
rip-trigger = yes
| Parameter | Specifies |
|---|
| Name | Unique name for the VRouter, up to 15 characters. Interfaces belonging to the VRouter are grouped by specifying this name in the IP-Interface or Connection profile. |
| VRouter-IP-Address | System IP address for the VRouter. |
Pool-Base-Address
Assign-Count
Pool-Name
Pool-Summary | IP address pools for the VRouter. The parameters operate identically to the parameters of the same names in the IP-Global profile, except that they are exclusive to one VRouter. If address pools are not specified in a VRouter profile, VRouters can share the address pools defined for in the IP-Global profile. |
| RIP-Policy | Policy for sending update packets that include routes received on the same interface. (For details, see RIP policy for propagating updates back to the originating subnet.) |
| Summarize-RIP-Routes | If the VRouter is running RIP-v1, the Summarize-RIP-Routes parameter specifies whether to summarize subnet information when advertising routes. If the VRouter summarizes RIP routes, it advertises a route to all the subnets in a network of the same class. For example, the route to 200.5.8.13/28 (a class C address) would be advertised as a route to 200.5.8.0. When the VRouter does not summarize information, it advertises each route in its routing table as-is. |
| RIP-Trigger | Enables/disables RIP triggering. If set to Yes (the default), RIP updates include only changed routes. (For details, see RIP triggering.) |
Example of defining a VRouter
The following commands create a VRouter for Corporation A:
admin> new vrouter corpa
VROUTER/corpa read
admin> list
[in VROUTER/corpa (new)]
name* = ""
vrouter-ip-address = 0.0.0.0
pool-base-address = [ 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0+
assign-count = [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 +
pool-name = [ "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""+
pool-summary = no
rip-policy = Poison-Rvrs
summarize-rip-routes = no
rip-trigger = yes
admin> set vrouter-ip-addr = 130.200.200.100
admin> write
VROUTER/corpa written
Viewing the VRouter's routing and interface tables
The new VRouter defined for Corporation A maintains the following minimal routing and interface tables at this point:
admin> netstat corpa -rn
Destination Gateway IF Flg Pref Met Use Age
127.0.0.0/8 - bh0_corpa CP 0 0 0 8172
127.0.0.1/32 - local CP 0 0 0 8172
127.0.0.2/32 - rj0_corpa CP 0 0 0 8172
admin> netstat corpa -in
Name MTU Net/Dest Address Ipkts Ierr Opkts Oerr
vr0_corpa 1500 130.200.200.100/32 130.200.200.100 0 0 0 0
lo0_corpa 1500 127.0.0.1/32 127.0.0.1 0 0 0 0
local 65535 127.0.0.1/32 127.0.0.1 0 0 0 0
rj0_corpa 1500 127.0.0.2/32 127.0.0.2 0 0 0 0
bh0_corpa 1500 127.0.0.3/32 127.0.0.3 0 0 0 0
The new VRouter has also started maintaining its own IP, TCP, UDP, and ICMP statistics. For example:
admin> netstat corpa -s
udp:
1442 packets received
0 packets received with no ports
0 packets received with errors
0 packets dropped
32 packets transmitted
tcp:
0 active opens
1 passive opens
0 connect attempts failed
0 connections were reset
1 connections currently established
858 segments received
0 segments received out of order
548 segments transmitted
0 segments retransmitted
0 active closes
0 passive closes
0 disconnects while awaiting retransmission
icmp:
31 packets received
0 packets received with errors
Input histogram:
30 echo requests
1 netmask requests
31 packets transmitted
0 packets not transmitted due to lack of resources
Output histogram:
30 echo replies
1 netmask replies
ip:
0 packets received
0 packets received with header errors
0 packets received with address errors
0 packets received forwarded
0 packets received with unknown protocols
0 inbound packets discarded
0 packets delivered to upper layers
0 transmit requests
0 discarded transmit packets
0 outbound packets with no route
0 reassemblies timeout
0 reassemblies required
0 reassemblies succeeded
0 reassemblies failed
0 fragmentation succeeded
0 fragmentation failed
0 fragmented packets created
0 route discards due to lack of memory
64 default ttl
igmp:
0 packets received
0 bad checksum packets received
0 bad version packets received
0 query packets received
0 leave packets received
0 packets transmitted
0 query packets sent
0 resonse packets sent
0 leave packets sent
mcast:
0 packets received
0 packets forwarded
0 packets in error
0 packets dropped
0 packets transmitted
Note: There is no support for IP multicast on per-VRouter basis, so the IGMP and MCast statistics relate only to the global VRouter.
Defining address pools for a VRouter
The following commands define an address pool for the Corporation A VRouter:
admin> read vrouter corpa
VROUTER/corpa read
admin> set pool-base 1 = 130.100.100.128
admin> set assign-count 1 = 127
admin> write
VROUTER/corpa written
Following is a comparable RADIUS pool definition:
pools-tnt01 Password = "ascend", User-Service = Dialout-Framed-User
Ascend-IP-Pool-Definition = "1 130.100.100.128 127 corpa"
The Corporation A VRouter is now maintaining the following pool of addresses:
admin> ip-pools corpa
Pool# Base Count InUse
1 130.100.100.128 127 0
Number of remaining allocated addresses: 0
Note: The Ascend-IP-Pool-Definition attribute supports a VRouter name as the last syntax element in a pool definition. The value of Ascend-IP-Pool-Definition uses the following syntax:
"pool-num base-addr assign-count [vrouter-name]"
For background information about address pools, see Configuring and using address pools. The process of defining address pools for a VRouter is the same as described in that section.
Assigning interfaces to a VRouter
To assign VRouter membership to an interface, you specify a VRouter name in the interface profile. In addition to PPP and other framed connections, TCP-Clear connections are also managed on a per-VRouter basis. If a Connection profile or RADIUS profile is associated with a VRouter and configured for TCP-Clear, the system locates the specified host only in the VRouter's routing table.
Settings in local profiles
Following are the related parameters in local profiles, shown here with sample values:
[in IP-INTERFACE/{ { shelf-1 slot-5 5 } 0 } ]
vrouter = corpa
[in CONNECTION/corpa-client]
vrouter = corpa
Settings in RADIUS profiles
RADIUS uses the following attribute-value pair to support the concept of a VRouter:
Examples of assigning VRouter membership to interfaces
The following commands group three WAN interfaces with the Corporation A VRouter:
admin> new connection dialin-1
CONNECTION/dialin-1 read
admin> set active = yes
admin> set vrouter = corpa
admin> set ip-options remote-address = 10.1.1.1/24
admin> write
CONNECTION/dialin-1 written
admin> new connection dialin-2
CONNECTION/dialin-2 read
admin> set active = yes
admin> set vrouter = corpa
admin> set ip-options remote-address = 11.1.1.1/24
admin> write
CONNECTION/dialin-2 written
admin> new connection dialin-3
CONNECTION/dialin-3 read
admin> set active = yes
admin> set vrouter = corpa
admin> set ip-options remote-address = 12.1.1.1/24
admin> write
CONNECTION/dialin-3 written
Following are comparable settings in RADIUS profiles:
dialin-1 Password = "pwd3"
User-Service = Framed-User,
Framed-Protocol = MPP,
Framed-Address = 10.1.1.1,
Framed-Netmask = 255.255.255.0,
Ascend-Vrouter-Name = "corpa"
dialin-2 Password = "pwd2"
User-Service = Framed-User,
Framed-Protocol = MPP,
Framed-Address = 11.1.1.1,
Framed-Netmask = 255.255.255.0,
Ascend-Vrouter-Name = "corpa"
dialin-3 Password = "pwd1"
User-Service = Framed-User,
Framed-Protocol = MPP,
Framed-Address = 12.1.1.1,
Framed-Netmask = 255.255.255.0,
Ascend-Vrouter-Name = "corpa"
Viewing assigned interfaces in the VRouter's tables
The new interfaces show up in the VRouter's routing and interface tables when the interfaces become active. For example:
admin> netstat corpa -rn
Destination Gateway IF Flg Pref Met Use Age
10.0.0.0/24 10.1.1.1 wan30 SG 120 7 0 215
10.1.1.1/32 10.1.1.1 wan30 S 120 7 1 215
11.0.0.0/24 11.1.1.1 wan31 SG 120 7 0 215
11.1.1.1/32 11.1.1.1 wan31 S 120 7 1 215
12.0.0.0/24 12.1.1.1 wan32 SG 120 7 0 215
12.1.1.1/32 12.1.1.1 wan32 S 120 7 1 215
127.0.0.0/8 - bh0_corpa CP 0 0 0 1193
127.0.0.1/32 - local CP 0 0 0 1193
127.0.0.2/32 - rj0_corpa CP 0 0 0 1193
admin> netstat corpa -in
Name MTU Net/Dest Address Ipkts Ierr Opkts Oerr
vr0_corpa 1500 130.200.200.100/32 130.200.200.100 0 0 0 0
lo0_corpa 1500 127.0.0.1/32 127.0.0.1 0 0 0 0
local 65535 127.0.0.1/32 127.0.0.1 0 0 0 0
rj0_corpa 1500 127.0.0.2/32 127.0.0.2 0 0 0 0
bh0_corpa 1500 127.0.0.3/32 127.0.0.3 0 0 0 0
wan30 1500 10.1.1.1 130.200.200.100 0 0 0 0
wan31 1500 11.1.1.1 130.200.200.100 0 0 0 0
wan32 1500 12.1.1.1 130.200.200.100 0 0 0 0
Defining VRouter static routes
You specify a static route associated with a VRouter for one of the following reasons:
- To define a route on a per-VRouter basis.
- To specify an inter-VRouter route.
Settings in an IP-Route profile
Following are the parameters related to VRouters in IP-Route profiles, shown here with default values:
[in IP-ROUTE/""]
vrouter = ""
inter-vrouter = ""
Settings in RADIUS profiles
The value of the Framed-Route (22) attribute can accept a VRouter name in the following syntax:
"dest-addr gateway-addr metric [private] [profile] [vrouter-name]"
Examples of defining a route on a per-VRouter basis
Following is an example that defines a static route to Corporation B. This route is within the Corporation A VRouter domain (the VRouter named CorpA will own this route).
admin> new ip-route corpa-east
IP-ROUTE/corpa-east read
admin> set dest = 10.5.6.7/28
admin> set gateway = 10.1.1.1
admin> set vrouter = corpa
admin> write
IP-ROUTE/corpa-east written
Following is a comparable RADIUS profile:
route-tnt-1 Password = "ascend", User-Service = Dialout-Framed-User
Framed-Route = "10.5.6.7/28 10.1.1.1 corpa"
Viewing the static route in the VRouter's table
The new static route is added to the Corporation A VRouter's routing table, as shown in the following sample output:
admin> netstat corpa -rn
Destination Gateway IF Flg Pref Met Use Age
10.1.1.0/24 10.1.1.1 wan30 SG 120 7 0 9
10.1.1.1/32 10.1.1.1 wan30 S 120 7 2 9
10.5.6.0/28 10.1.1.1 wan30 SG 60 8 0 9
11.1.1.0/24 11.1.1.1 wan31 SG 120 7 0 9
11.1.1.1/32 11.1.1.1 wan31 S 120 7 1 9
12.1.1.0/24 12.1.1.1 wan32 SG 120 7 0 9
12.1.1.1/32 12.1.1.1 wan32 S 120 7 1 9
127.0.0.0/8 - bh0_corpa CP 0 0 0 2274
127.0.0.1/32 - local CP 0 0 0 2274
127.0.0.2/32 - rj0_corpa CP 0 0 0 2274
Specifying an inter-VRouter route
In the next example, the static route specifies the Corporation A VRouter as the route's next hop. All packets to the specified destination network are sent to the specified VRouter for a routing decision:
admin> new ip-route corpb
IP-ROUTE/corpb read
admin> set dest-address = 11.0.0.0/24
admin> set inter-vrouter = corpa
admin> write
IP-ROUTE/corpb written
Following is a comparable RADIUS route profile:
route-tnt-1 Password = "ascend", User-Service = Dialout-Framed-User
Framed-Route = "11.0.0.0/28 0.0.0.0 corpa"
Viewing the inter-VRouter route in the global table
In this case, the route is added to the global VRouter's routing table, not to the Corporation A VRouter. For example:
admin> netstat -rn
Destination Gateway IF Flg Pref Met Use Age
0.0.0.0/0 10.168.6.1 ie0 SGP 60 1 59 4
11.0.0.0/24 - vr0_corpa S 60 8 0 4
20.0.0.0/8 - ie1-12-1 C 0 0 12 2347
20.1.1.2/32 - local CP 0 0 0 2347
127.0.0.0/8 - bh0 CP 0 0 0 2378
127.0.0.1/32 - local CP 0 0 0 2378
127.0.0.2/32 - rj0 CP 0 0 0 2378
130.100.100.10/32 - sip0 C 0 0 0 2378
130.100.100.252/30 - rj0 C 0 0 0 2378
100.168.6.0/24 100.168.6.221 wanabe SG 60 1 0 4
101.168.6.0/24 - ie0 C 0 0 2531 2378
101.168.6.234/32 - local CP 0 0 4152 2378
224.0.0.0/4 - mcast CP 0 0 0 2378
224.0.0.1/32 - local CP 0 0 0 2378
224.0.0.2/32 - local CP 0 0 0 2378
224.0.0.5/32 - local CP 0 0 732 2378
224.0.0.6/32 - local CP 0 0 0 2378
255.255.255.255/32 - ie0 P 0 0 422 2378
Deleting a VRouter
Deleting a VRouter profile deletes the virtual router. For example:
admin> delete vrouter corpa
Note: If you delete a VRouter with active connections, a reset is recommended. If a system reset is not possible, the recommended course of action before deleting the VRouter is to manually tear down its active connections, and then modify the local Connection, IP-Interface, and IP-Route profiles that point to the VRouter to point instead to the global VRouter or another existing VRouter.
techpubs@ascend.com
Copyright © 1999, Ascend Communications, Inc. All rights reserved.
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
