[Top][Contents][Prev][Next][Last]Search


IP Routing


This chapter covers the following topics:
IP routing configuration overview
Configuring the IP router
Configuring LAN interfaces
Configuring WAN interfaces
Configuring static IP routes

IP routing configuration overview

This chapter shows how to configure the IP router, its LAN and WAN interfaces, and static IP routes. The router software has many possible configuration settings that determine how it handles routes, which source address it uses for packets generated by the system itself, how WAN clients access DNS servers, how pools of local addresses are allocated for dynamic assignment to dial-in hosts, and so forth. Most general router behavior options are configured in the IP-Global profile.

Each LAN interface in the MAX TNT can be configured for IP with one or more IP addresses. LAN interfaces are configured in IP-Interface profiles.

Each WAN interface can support IP routing, enabling the system to route IP packets to and from that interface. Each connection has a variety of options for controlling RIP updates, assigning metrics, and specifying the IP address of the remote device. You can configure WAN interfaces in Connection profiles or on an external authentication server, such as RADIUS, TACACS, or TACACS+.

If the router cannot find a route to a packet's destination address, it either drops the packet or sends it to a configured default route. Most sites configure a default route in the MAX TNT. Many sites choose to provide multipath static routes to balance traffic to a site across several connections. Static routes are configured in IP-Route profiles.

In addition to these IP-specific profiles, you might also need to change settings in the Answer-Defaults profile. For an example, see Configuring address pools for dynamic assignment to dial-in hosts.

For information about IP or route filters, see Chapter 9, Ascend Packet Filters.

IP diagnostic commands

The MAX TNT command-line interface supports several network administration commands, which are described in more detail in the MAX TNT Reference Guide. This section provides a brief overview of the following commands, which you'll need for verifying that IP routing is working properly:

Displaying the routing and interface tables

To view the routing table, enter the Netstat command with the -rn argument, as shown in the following example:

admin> netstat -rn
Destination Gateway IF Flg Pref Met Use Age
127.0.0.0/8 - bh0 CP 0 0 0 881
127.0.0.1/32 - local CP 0 0 0 881
127.0.0.2/32 - rj0 CP 0 0 0 881
11.168.7.0/24 - ie0 C 0 0 830 881
11.168.7.134/32 - local CP 0 0 489 881
10.1.1.0/24 10.1.1.2 wan12 rGT 60 1 0 767
10.1.1.2/32 10.1.1.2 wan12 rT 60 1 0 767
10.1.2.0/24 10.1.2.2 wan9 rGT 60 1 0 770
10.1.2.2/32 10.1.2.2 wan9 rT 60 1 0 770
10.2.1.0/24 10.2.1.2 wan10 rGT 60 1 0 769
10.2.1.2/32 10.2.1.2 wan10 rT 60 1 0 769
10.2.2.0/24 10.2.2.2 wan11 rGT 60 1 0 768
10.2.2.2/32 10.2.2.2 wan11 rT 60 1 0 768
10.3.1.0/24 - ie1-4-1 C 0 0 12 831
10.3.1.2/32 - local CP 0 0 0 831
10.3.2.0/24 - ie1-4-2 C 0 0 12 831
10.3.2.2/32 - local CP 0 0 0 831
10.3.102.2/32 - local rTM 0 0 0 728
10.3.102.2/32 - local CM 0 0 0 881
10.4.3.0/24 10.4.103.2 wan17 SG 60 8 235 682
10.4.4.0/24 10.4.4.2 wan19 SG 120 7 0 830
10.4.4.2/32 10.4.4.2 wan19 S 120 7 1 830
10.4.103.0/24 10.4.103.2 wan17 rGT 60 1 0 682
10.4.103.2/32 10.4.103.2 wan17 rT 60 1 2 682
10.4.104.0/24 10.4.104.2 wan18 rGT 60 1 0 728
10.4.104.2/32 10.4.104.2 wan18 rT 60 1 0 728
10.5.1.0/24 - ie1-4-3 C 0 0 12 831
10.5.1.2/32 - local CP 0 0 0 831
10.5.2.0/24 - ie1-4-4 C 0 0 12 830
10.5.2.2/32 - local CP 0 0 0 830
10.6.2.0/24 10.6.2.2 wan14 rGT 60 1 0 770
10.6.2.2/32 10.6.2.2 wan14 rT 60 1 0 770
10.100.3.0/24 10.100.3.2 wan15 rGT 60 1 0 768
10.100.3.2/32 10.100.3.2 wan15 rT 60 1 0 768
12.65.212.0/24 11.168.7.1 ie0 SG 60 8 256 830
224.0.0.0/4 - mcast CP 0 0 0 881
224.0.0.1/32 - local CP 0 0 0 881
224.0.0.2/32 - local CP 0 0 0 881
224.0.0.5/32 - local CP 0 0 0 881
224.0.0.6/32 - local CP 0 0 0 881
224.0.0.9/32 - local CP 0 0 0 881
255.255.255.255/32 - ie0 CP 0 0 18 881
For details about the subnet notation Ascend uses (for example, 12.65.212.227/32, where 32 is the subnet mask), see Using Ascend notation for IP addresses.

The Destination and Gateway fields show the destination address and the address of the next-hop router used to reach that destination. Note that the router will use the most specific route (having the largest netmask) that matches a given destination. Direct routes do not show a gateway address.

The IF field shows the name of the interface through which a packet addressed to this destination will be sent. The route to the mcast interface name encapsulates the multicast forwarder for the entire class D address space. (See Chapter 6, Multicast Forwarding.)

Routes targeted at 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.)

224.0.0.5 and 224.0.0.6 are used by OSPF for inter-router communications (instead of using broadcasts as RIP does).

To view the interface table, enter the Netstat command with the -in argument, as shown in the following example:

admin> netstat -in
Name MTU Net/Dest Address Ipkts Ierr Opkts Oerr
ie0 1500 11.168.7.0/24 11.168.7.134 2277 0 246 0
lo0 1500 127.0.0.1/32 127.0.0.1 344 0 344 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 0 0 0 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 431 0 431 0
mcast 65535 224.0.0.0/4 224.0.0.0 0 0 0 0
tunnel7 1500 11.168.7.0/24 11.168.7.134 0 0 0 0
dtpt8 1500 11.168.7.0/24 11.168.7.134 0 0 0 0
wan9 1528 10.1.2.2 11.168.7.134 0 0 0 0
wan10 1528 10.2.1.2 11.168.7.134 0 0 0 0
wan11 1528 10.2.2.2 11.168.7.134 0 0 0 0
wan12 1528 10.1.1.2 11.168.7.134 0 0 0 0
wan13 1500 10.6.1.2 11.168.7.134 0 0 0 0
wan14 1528 10.6.2.2 11.168.7.134 0 0 0 0
wan15 1528 10.100.3.2 11.168.7.134 0 0 0 0
wan16 1500 10.100.2.2 11.168.7.134 0 0 0 0
wan17 1528 10.4.103.2 11.168.7.134 0 0 80 0
wan18 1528 10.4.104.2 10.3.102.2 0 0 0 0
wan19 1500 10.4.4.2 11.168.7.134 0 0 0 0
ie1-4-1 1500 10.3.1.0/24 10.3.1.2 0 0 1 0
ie1-4-2 1500 10.3.2.0/24 10.3.2.2 0 0 1 0
ie1-4-3 1500 10.5.1.20/4 10.5.1.2 0 0 0 0
ie1-4-4 1500 10.5.2.0/24 10.5.2.2 0 0 1 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, 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:

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:

has the following interface name:

The other names in the interface table, and their significance, are:

Performing a DNS lookup

To retrieve the IP address of the host named Techpubs, append the host's name to the Nslookup command:

Pinging a host

To Ping the host named Techpubs, append the name to the Ping command:

Displaying route statistics

To trace the route an IP packet takes to a host named Cujo, append the host's name to the Traceroute command:

Using Ascend notation for IP addresses

In the MAX TNT, IP addresses are specified in dotted decimal format (not hexadecimal). If no subnet mask is specified, the MAX TNT assumes a default mask based on address class. Table 4-1 shows address classes and the number of network bits in the default mask.

Table 4-1. IP address classes

Class

Address range

Network bits

Class A

0.0.0.0 - 127.255.255.255

8

Class B

128.0.0.0 - 191.255.255.255

16

Class C

192.0.0.0 - 223.255.255.255

24

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:

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 have the same base address that a class A, B, or C network would have. For example, the subnet 192.168.8.0/30 was illegal because it had the same base address as the class C network 192.168.8.0/24, while 192.168.8.4/30 was legal (192.168.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 2 and OSPF treat these so-called zero subnetworks 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

Subnet mask

Number of host addresses

Ascend notation

255.255.255.0

254 hosts + 1 broadcast, 1 network base

/24

255.255.255.128

126 hosts + 1 broadcast, 1 network base

/25

255.255.255.192

62 hosts + 1 broadcast, 1 network base

/26

255.255.255.224

30 hosts + 1 broadcast, 1 network base

/27

255.255.255.240

14 hosts + 1 broadcast, 1 network base

/28

255.255.255.248

6 hosts + 1 broadcast, 1 network base

/29

255.255.255.252

2 hosts + 1 broadcast, 1 network base

/30

255.255.255.254

invalid netmask (no hosts)

/31

255.255.255.255

1 host - a host route

/32

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:

The Ethernet attached to that router has the following address range:

A host route is a special-case IP address with a subnet mask of /32. For example:

Host routes are required for dial-in hosts.

Configuring the IP router

This section describes how to configure the MAX TNT IP router. It covers the following topics:

For information about OSPF routing, see Chapter 5, OSPF Routing. For information about multicast forwarding, see Chapter 6, Multicast Forwarding.

Accessing the IP-Global profile

System-level configuration of the IP router consists largely of configuring the IP-Global profile. To read the profile into the edit buffer, use the Read command as follows:

The following sections describe parameters in the IP-Global profile. For detailed information about each parameter, see the MAX TNT Reference Guide.

Specifying a system address

By default, the MAX TNT uses the IP address assigned to the shelf-controller Ethernet interface as the source address for packets it generates, such as RADIUS or TACACS+ requests, an ATMP tunnel request, or a Telnet, Traceroute, or Ping command originating from the shelf-controller or any slot card within the unit. You can use the following parameter (shown with a sample setting) to specify a different source address for these packets:

If you specify an IP address in the System-IP-Addr parameter, the MAX TNT uses that as the source address for packets it generates. If the system address becomes unreachable due to a change in the network topology, the MAX TNT might still be reachable by Telnet at any of its other interface addresses. (Of course, this is subject to packet filtering throughout the network.)

One reason for setting a system address other than the shelf-controller address 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 don't specify a system address, the 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. This is 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:

Setting an interface-independent IP address

To make inbound IP traffic independent of physical addresses in the MAX TNT, you can define an interface-independent (soft) IP address. Because a soft address is not associated with a physical port, it is always accessible if any one of the MAX TNT physical interfaces is up.

You can use the following parameter (shown with a sample setting) to set a soft interface address:


Note: The interface-independent address must have a unique IP address, just like other interfaces in the unit.

For example, the following commands set the soft interface address to 11.168.7.100:

This address is advertised in RIP and OSPF as a host route with a mask of /32 using the loopback interface. To enable hosts on the network to reach this address, you must either enable routing protocols (RIP or OSPF) or configure static routes in routers one hop away from the MAX TNT. 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:

Providing access to DNS

There are three aspects to DNS configuration in the MAX TNT:

For information about configuring client DNS, which enables the MAX TNT to direct connections to DNS servers owned by a client, or to DNS servers owned by several different clients on a per-connection basis, see Appendix B, Network Security Settings.

Specifying domain names for name lookups

When the MAX TNT is given a host name to look up, it tries various combinations. For example, it appends the domain name specified in the IP-Global profile. You can specify a primary and secondary domain name for DNS lookups by setting the following parameters (shown with sample settings):

The secondary domain name specifies another domain name the MAX TNT can search if the host name is not found in the primary domain. The following example shows the commands entered to set the primary and secondary domain names, and the system's responses:

Specifying which name servers are accessible

In the IP-Global profile, administrators can specify addresses for two local DNS servers, and for additional DNS servers referred to as client servers. Client servers are accessed only if a caller's configured profile does not include DNS server addresses specific to that connection. Following are the related parameters in the IP-Global profile (shown with sample settings):

For information about configuring client DNS, see Appendix B, Network Security Settings.

If you are using NetBIOS
If the local network supports NetBIOS instead of DNS, you can configure the MAX TNT to access NetBIOS servers by setting the following parameters (shown with sample values):

Following is an example of specifying NetBIOS server addresses:

The system accesses the secondary NetBIOS server only if the primary server is not found.

If you are using DNS
If you inform the MAX TNT about name servers on the local network, callers can access the databases on those hosts. The following example shows how to specify DNS server addresses:

The secondary server is accessed only if the primary one is inaccessible.

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 by setting the following parameters (shown with default settings):

The DNS-List-Attempt parameter enables the user to try one entry in the DNS list of hosts, and, if that connection fails, to try the next entry, and so on, without losing the WAN session. The DNS-List-Size parameter specifies the maximum number of hosts listed, up to a maximum of 35.

The following example shows how to enable DNS list with a maximum of 14 hosts in the list:

See Setting a TCP timeout for related information.

Setting up a local DNS table

The MAX TNT can maintain a DNS table in RAM 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 system startup, the values in the profile are copied 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 in the IP-Global profile, which are shown with their default values:

The Enabled parameter specifies whether the local DNS table in RAM will be available if DNS queries fail. If set to No (the default), and a DNS query times out, the request fails. If set to Yes, the MAX TNT attempts to resolve the query by consulting the DNS table in RAM. If the host name in the DNS query has an entry in the table in RAM, the system returns the associated IP address(es) to the requester.

For details about Auto-Update, see Using the Auto-Update feature.

The Table-Config subprofiles, numbered 1 to 8, each contain a single Host-Name field and a single IP address field. Host-Name specifies a host name, which must be unique within the table. For details, see "Host name matching" next. IP-Address specifies a valid IP address for the Host-Name, or the null address.

Host name matching

The host name specified in the DNS-Local-Table subprofile must start with an alphabetic character, and must be less 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 contain a domain name, and the following parameters are set to valid Domain-Name values in the IP-Global profile:

Then the system appends the specified domain name when looking up the host name. For example, for a DNS query on the following host name:

The MAX TNT searches for the host name as well as the following domain names:

Defining the local table

Following is an example of configuring a local table specifying three hosts:

If you specify an IP address without also specifying a host name, a message such as the following is displayed when you write the profile:

If you enter an invalid host name, a message such as the following is displayed when you write the profile:

Using the Auto-Update feature

The Auto-Update parameter determines whether the local table is updated by regular successful DNS queries. If it is set to No (the default), the contents of the local table are not affected by successful DNS queries. If set to Yes, when a regular DNS query succeeds, a lookup on that host name is made to the local table. If there is an entry for the host name, the entry's IP address(es) is replaced by the query response. Note that you can use the Auto-Update parameter to build the local table.

The following parameters, which are shown with their default values, affect how the table is updated when Auto-Update is set to Yes:

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. To prevent stale entries in the table in RAM, addresses greater than DNS-List-Size are cleared at each update.


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).

Following is an example that 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.

Configuring address pools for dynamic assignment to dial-in hosts

For dial-in PPP clients that are not running as IP routers, the MAX TNT can assign the connection a local IP address on a first-come first-served basis. After the connection is terminated, the address that was assigned to that connection is returned to the pool for reassignment to another connection.

To enable the MAX TNT to handle local IP addresses in this way, you configure the following parameters (shown with their default values):


Note: For information about importing summarized pool addresses into OSPF, see Assigning a cost to a static route of Chapter 5, OSPF Routing.

Enabling the system to assign addresses

To enable the MAX TNT to assign an IP address to an incoming call, you must set the Assign-Address parameter in the Answer-Defaults profile to Yes. For example:

Requiring acceptance of the pool address

During PPP negotiation, a caller could reject the IP address offered by the MAX TNT and present its own IP address for consideration. For security reasons, you might want to set the Must-Accept-Address-Assign parameter to ensure that the MAX TNT terminates such a call:

If you enforce acceptance of the assigned address, the Answer-Defaults profile must enable dynamic assignment, the caller's configured profile must specify dynamic assignment, and the caller's PPP dial-in software must be configured to acquire its IP address dynamically. For more details, see Example of a dial-in host requiring address assignment.

Pool names (TACACS+)

Each pool configuration consists of a pool base address and address count. You can also assign a pool name, and you must do so if using TACACS+ authentication. A pool name can contain up to 11 characters.

If TACACS+ authentication is not in use, the name is treated as a comment. If TACACS+ authentication is performed, the name is matched against the TACACS+ pool names to identify which pool to use for allocating an address to the connection. If all addresses in the named pool are already allocated, an address is taken from the next pool with the same name.

What is pool summary?

The Pool-Summary feature is designed to reduce the routing overhead associated with address pools. Originally, each address assigned from a pool was advertised as a host route with a subnet mask of 32. As the number of supported pool addresses grew (the MAX TNT can support up to 32,512 pool addresses), the possible overhead associated with advertising these host routes became an issue.

The Pool-Summary feature sets a flag that enables the MAX TNT to advertise a route to the entire pool of addresses rather than advertise each address within the pool. However, to use this feature, the pools must be network aligned, which requires a special pool base address and adherence to other specifications. (For details, see Setting up summarized address pools (pool summary).)

If you do not use the Pool-Summary feature, each address in a pool is advertised as a host route with a subnet mask of 32. In that case, the pool does not have to be network-aligned, so any IP address that begins a block of free addresses can serve as the pool base address.

Setting up address pools (no pool summary)

You can define up to 128 address pools, with each pool containing up to 254 contiguous IP addresses. A non-aligned pool can start at any pool base address. Addresses do not accept a subnet mask component, because they are always advertised as host routes.

The Pool-Base-Address parameter specifies the first address in a block of contiguous addresses on the local network or subnet, and the Assign-Count parameter specifies how many addresses are in the pool (up to 254).

The Pool-Name parameter is optional unless you are using TACACS+ authentication (see Pool names (TACACS+)).

The commands in the following example specify three pools, each containing 50 contiguous free IP addresses:

These commands allocate the following addresses for dynamic assignment to callers:

Setting up summarized address pools (pool summary)

If you set up address pools that comply with all Pool-Summary requirements, the MAX TNT can summarize the host routes into one advertisement for the pool as a whole. For this feature to work, your configuration must meet the following requirements:

Network-aligned address pools
Following are the rules for network-aligned address pools:

  1. The Assign-Count value must be two less than the total number of addresses in the pool. (Add two to Assign-Count for the total number of addresses in the subnet, and calculate the mask for the subnet on the basis of this total.)

  2. The Pool-Base-Address value must be the first host address. (Subtract 1 from the Pool- Base-Address for the base address for the subnet.)

For example, the following configuration is network aligned:

In this example, 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 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.

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.

Configuring a static route to the summarized subnet
After verifying that every one of the configured address pools is network aligned, you must enter a static route for each of them. These static routes advertise the route to the pool itself. The MAX TNT handles IP addresses in the pool that have not been assigned by routing them to the Reject interface or the Blackhole interface.

The Reject (rj0) interface address is 127.0.0.2. Packets routed to this interface are bounced back to the sender with an ICMP unreachable message.

The Blackhole (bh0) interface address is 127.0.0.3. Packets routed to this interface are silently discarded.

The MAX TNT creates a host route for each assigned address in the pool, and host routes override subnet routes. So packets whose destination matches an assigned IP address from the pool are properly routed and not discarded or bounced. But 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. Depending on the static-route gateway address, these packets are either bounced with an ICMP unreachable message (reject interface) or silently discarded (blackhole interface).

For example, you could use a procedure similar to the following to set up the destination and gateway parameters that define the pool. This example uses the blackhole interface for inactive host addresses, and sets the other required values for the route. For information about configuring static routes, see Configuring static IP routes.

  1. Create a new IP-Route profile:

  2. Specify the base network address of the network-aligned pool:

  3. Specify the Blackhole interface (for example) as the Gateway-Address:

  4. Set the metric, cost, and preference values to zero:

  5. Make sure the route is not private:

  6. Write the IP-Route profile:

The routing table will contain the following lines:

Destination         Gateway    IF      Flg       Pref   Met     Use    Age
10.12.253.0/26      -          bh0     C         0      0       0   172162
127.0.0.1/32 - lo0 CP 0 0 0 172163
127.0.0.2/32 - rj0 CP 0 0 0 172163
127.0.0.3/32 - bh0 CP 0 0 0 172163
Making each Connection profile that uses the pool private
When you configure Connection profiles that will be assigned an IP address from the summarized pool, make sure the Private-Route parameter is set to Yes. For example:

  1. Open a Connection profile that will use dynamic address assignment:

  2. Specify the number of the summarized pool:

  3. Make the WAN connection route private:

  4. Write the profile:

This example assumes that Address-Pool 1 is network aligned and has a configured route, as shown in the preceding sections. In addition, the Answer-Defaults profile must enable dynamic assignment, and the caller's PPP dial-in software must be configured to acquire its IP address dynamically. For more information about configuring Connection profiles, see Configuring LAN interfaces.

Enabling incoming calls to share profiles

The following parameter specifies whether the MAX TNT will allow more than one incoming call to share the same Connection profile:

For routed IP callers, shared profiles cannot result in two IP addresses reached through the same profile.

In low-security situations, more than one caller can share a name and password for accessing the local network. This requires sharing a single Connection profile that does not assign an IP address, or one that specifies dynamic IP address assignment. If a shared profile uses an IP address, it must be assigned dynamically, because multiple hosts cannot share a single IP address. When the shared profile uses dynamic address assignment, each call is a separate connection that shares the same name and password. A separate IP address is assigned dynamically to each caller.

To enable shared profiles, set the Shared-Profile parameter as follows:

Configuring Telnet access to the system

The following parameters (shown with their default values) configure Telnet access to the MAX TNT:

All users attempting to access the MAX TNT unit via Telnet are prompted for the Telnet-Password. They are allowed three tries, each with a 60-second time limit, to enter the correct password. If all three tries fail, the connection attempt times out.

You can also associate a User profile with Telnet sessions. By default, no profile is specified, which means that each Telnet user must supply the name and password of a User profile. If you specify a User profile for Telnet sessions, the system uses that profile for any Telnet login. If the profile has a password, the Telnet user is prompted for it after the Telnet password. If not, supplying the Telnet-Password alone allows access to the unit.

The commands in the following example set the Telnet-Password and specify the Default User profile for Telnet logins. The Default profile enables minimal permissions and requires no password.

Configuring system-level routing policies and preferences

The following parameters configure routing policies and route preferences in the MAX TNT:

RIP-v1 issues

The RIP-Policy and Summarize-RIP-Routes parameters have no effect on RIP-v2. The IETF has voted to move RIP-v1 into the Historic category, and its use is no longer recommended. You should upgrade all routers and hosts to RIP-v2. If you must maintain RIP-v1, Ascend recommends that you create a separate subnet for all RIP-v1 routers and hosts.

If the MAX TNT is running RIP-v1, the RIP-Policy parameter must specify a split-horizon or poison-reverse policy for outgoing update packets that include routes that were received on the same interface on which the update is sent. Split-horizon means that the MAX TNT 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.

The Summarize-RIP-Routes parameter specifies whether to summarize subnet information when advertising routes. If the MAX TNT 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 MAX TNT does not summarize information, it advertises each route in its routing table as-is.

Handling ICMP redirects and directed broadcast requests

For security purposes, you can prevent the MAX TNT from processing ICMP Redirect packets and responding as a host to directed-broadcast ICMP Echo requests.

ICMP Redirect packets can be counterfeited and used to change the way a device routes packets. The following example shows how to configure the router to ignore all ICMP Redirects:

Directed-broadcast ICMP Echo requests have been used in some denial-of-service attacks. The following example shows how to prevent the system from responding to such packets:

For more detail about preventing misuse of directed broadcasts, see Appendix B, Network Security Settings.

Dropping source-routed packets

The Drop-Source-Routed-IP-Packets parameter specifies whether the MAX TNT forwards IP packets with the source route option set. The default is No, which causes the MAX TNT to forward all source routed packets as described in RFC1812, Requirements For Routers. When the parameter is set to Yes, the MAX TNT 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:

Ignoring default routes in updates

You can configure the MAX TNT to ignore default routes advertised by routing protocols. This configuration is recommended. The default route specifies a static route to another IP router, which is often a LAN router. When the MAX TNT is configured to ignore the default route, RIP updates do not modify the default route in the MAX TNT routing table. The following set of commands protects the default route from RIP updates:

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, it instructs the MAX TNT to stop advertising IP routes that use dial services if for any reason its trunks are in the alarm condition. Otherwise, it continues to advertise its dial-out routes, which prevents the redundant unit from taking over the routing load. Set the parameter as follows to use of this feature for redundant units:

Static and RIP preferences

RIP is a distance-vector protocol, which uses a hop count to select the shortest route to a destination network. OSPF is a link-state protocol, which means that OSPF can take into account a variety of link conditions, such as the reliability or speed of the link, when determining the best path to a destination network. Because RIP and OSPF metrics are incompatible, the MAX TNT supports route preferences.

By default, static routes and RIP routes have the same preference, so they compete equally. ICMP redirects take precedence over both, and OSPF takes precedence over everything. 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.

In the following example, the administrator increases the preference value of RIP routes, instructing the router to use static routes first if they exist:

For information about filtering routes or configuring route metrics in RIP update packets, see Chapter 9, Ascend Packet Filters.

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. Following are the parameters that specify the maximum size of this backlog (shown with their default values):

The 0 (zero) value for the RIP-Queue-Depth or Queue-Depth parameters means that the MAX TNT will not drop any UDP packets, no matter how far behind it gets. In other words, there is no limit to the queue depth. Valid values are 0 to 1024.

When you set 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.

Note that 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:

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:

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.

If you must control memory usage for the card, you can restrict the cache size or disable the route cache with the following parameters (shown with their default values, which are recommended):

Route caches are enabled by default, and Ascend recommends that you do not disable route caches or change their size.The IProute-Cache-Size parameter is set to 0 by default, which sets no limit on the size of the cache. If you set a higher number, it represents the number of cache entries. Usually, no limit is required.

Port caches

The IP route caching mechanism does not affect 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, a TCP connection is established between the receiving slot card for the client dial-in (such as a modem card) and a server on the IP network, which is accessible through the destination card (such as an Ethernet card). TCP packets containing the client terminal byte stream are created by the modem card and sent to the server. In this example, the packets from modem card to server can be routed via IP route-caching directly to the Ethernet card. In the reverse direction, server to client, there is no IP route cache, because the packet is destined for the MAX TNT system itself. So the packet is delivered to the router, where it is forwarded to the modem card based on the destination port number.

The following parameter (shown with its default value) enables IP packet forwarding card-to-card based on the packet destination IP address and port:

If you set this parameter to No, packets destined for the MAX TNT itself are routed from the receiving slot card to the destination slot card through the shelf-controller, rather than being forwarded directly from the receiving slot card.

Enabling BOOTP and RARP

The following parameters (shown with their default values) configure Bootstrap Protocol (BOOTP) and reverse-ARP (RARP) in the MAX TNT:

With BOOTP-Enabled set to Yes, the MAX TNT can query a BOOTP server for new parameters and to check for a new software load. With RARP-Enabled set to Yes, the MAX TNT can obtain its own IP addresses from a RARP server. The following set of commands enables both BOOTP and RARP:

Enabling UDP checksums

The UDP-Checksum parameter enables UDP checksums for transmitted packets:

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 turn on UDP checksums:

Setting a TCP timeout

The TCP-Timeout parameter enables the administrator to adjust the TCP retry timer so that each unsuccessful connection attempt will terminate quickly, allowing more rapid progress through the list, to a good address if one is present. The parameter is shown with its default value:

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. For example, when a user enters a host name via client software 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.

Valid values for TCP-Timeout are from 0 to 200 seconds. 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 non-zero value, the value is the number of seconds TCP retries persist. After the specified number of seconds, the retries stop and the connection is considered lost. The following commands set the timeout to 50 seconds:

The optimal setting for the TCP-Timeout parameter must be determined by experience, and 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, such as 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, such as UNIX client. Following is the relevant parameter, which is shown with its default setting:

When set to No, the MAX TNT rejects queries from Finger clients with the following message:

The following commands enable the MAX TNT to accept Finger queries and return the requested active session details to a remote client:

The client can request the short or wide format; for example, a UNIX client can request the wide format by using the -l option. The following command:

displays the narrow (80-character wide) format, and the following command

displays a wide (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:

The Finger forwarding service is not supported. The forwarding service uses the following hostname format :

If the remote client uses the forwarding request format, the client sees the following message:

Using SNTP to set and maintain the MAX TNT system time

The MAX TNT can use Simple Network Time Protocol (SNTP-described in RFC 1305) to set and maintain its system time by communicating with an SNTP server. You configure the process in the SNTP-Info subprofile of the IP-Global profile, by setting the following parameters (which are shown with their default values):

SNTP must be enabled before the MAX TNT can communicate using that protocol. In addition, you must specify the IP address of at least one SNTP server. The Host parameter lets you specify up to three server addresses. 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.

With the GMT-Offset parameter, you specify your time zone as an offset from the Universal Time Configuration (UTC). UTC is in the same time zone as Greenwich Mean Time (GMT), and you specify the offset in hours and minutes using a 24-hour clock. Because some time zones, such as Newfoundland, do not have an even hour boundary, the offset includes four digits. It requires half-hour increments. For example, in Newfoundland the time is 1.5 hours ahead of UTC, which is represented as follows:

For San Francisco, which is 8 hours ahead of UTC:

For Frankfurt, which is 1 hour behind UTC:

The commands in the following example specify the time zone for San Francisco and the address of one SNTP server:

Configuring LAN interfaces

This section describes how to configure the local Ethernet interfaces of the MAX TNT for IP routing. It covers the following topics:

For information about OSPF routing, see Chapter 5, OSPF Routing. For information about multicast forwarding, see Chapter 6, Multicast Forwarding.

IP-Interface profile indexes

The MAX TNT creates a default IP-Interface profile for each local interface when it first detects the shelf-controller Ethernet port or the presence of an installed Ethernet card. For example, the following output shows the default IP-Interface profiles for the shelf-controller and a 100-Mbit Ethernet card installed in slot 12:

The profile for the first Ethernet port on a card in shelf 1, slot 12, uses the following index:

This index is composed of a physical address and a logical-item-number in the following format:

The logical item addresses a specific logical interface. It is zero except when multiple interfaces have been configured. The logical-item-numbers do not have to be consecutive, but they must be unique. For example, the following command creates another IP-Interface profile for that Ethernet port:


Note: For IP-Interface profiles, the default 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.)

Assigning local IP addresses

You must specify at least one IP address for each LAN interface that supports TCP/IP, unless the MAX TNT uses reverse ARP to obtain its address for the interface. (To enable reverse ARP, see Enabling BOOTP and RARP). To assign an IP address to a LAN interface, set the IP-Address parameter in the IP-Interface profile (shown here with its default value):

To assign an address, first obtain an IP address that is not in use on the network segment. Then, open the IP-Interface profile and specify the IP address. Following is an example that shows the commands entered to set the IP address to 10.1.2.65/24, and the system's responses:

For background information about specifying subnet masks, see Using Ascend notation for IP addresses.

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 a 0 (zero) logical-item-number. To configure more than one IP address on a local interface, create an IP-Interface profile for each unique IP address.


Note: The Ascend OSPF implementation conforms with RFC 1583 and does not support virtual IP interfaces. OSPF can be enabled on any one of a port's IP interfaces, but not on more than one interface for the same port.

The first set of commands in the following example assigns the IP address 10.5.6.7 to the default IP interface for shelf 1, slot 12, port 1:

The next set of commands creates a second IP-interface profile for the same physical port and assigns it the address 10.9.1.212/24:


Note: For IP-Interface profiles, the default 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 IP-Interface profiles.

Enabling proxy ARP on a LAN interface

When you enable proxy ARP, hosts on the LAN interface 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 local hosts' ARP requests, and then routes the packets for those connections across the WAN. To enable proxy ARP, set the Proxy-Mode parameter in the IP-Interface profile (shown here with its default value):


Note: 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.

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.

To enable the MAX TNT to respond as proxy for ARP requests, but only for active WAN connections, set Proxy-Mode to Active, as shown in the following example:

Enabling RIP on a LAN interface

By default, RIP is turned off on local interfaces. For each local interface, you can enable RIP to send updates on the interface, receive updates from other routers, or both. To configure RIP, use the following parameters (shown here with their default values):

For details about each parameter's settings, see the MAX TNT Reference Guide.

Figure 4-3 shows the MAX TNT and a local router, connecting to a remote access router with another router on the remote network. Each router maintains its own routing table.

Figure 4-3. Deciding whether to enable RIP

When RIP is turned off in the IP-Interface profile, the MAX TNT does not propagate its routing table to routers on the LAN interface, so local hosts do not have access to the remote network and its routes. Also, when RIP is off, the MAX TNT does not receive the local routers' updates to its routing table, so callers do not have access to other routes maintained locally. If you decide to enable RIP on the LAN interface, you have the following options:

Following is an example of enabling the MAX TNT to send and receive RIP-v2 updates on the multicast address:

For information about filtering routes or configuring route metrics in RIP update packets, see Chapter 9, Ascend Packet Filters.

Configuring WAN interfaces

This section describes how to configure Connection profiles for IP routing connections. It covers the following topics:

For information about OSPF routing, see Chapter 5, OSPF Routing. For information about multicast forwarding, see Chapter 6, Multicast Forwarding.

Listing the IP subprofile of a Connection profile

For information about configuring the encapsulation, telco, and session options required for building a connection, see Chapter 2, WAN Connections. Following is an example that shows the commands entered to open a Connection profile and list the IP-Options subprofile, and the system's responses:

For complete information about each parameter, see the MAX TNT Reference Guide. For information about the Client-DNS settings, see Appendix B, Network Security Settings.

Enabling IP routing for a WAN connection

The following parameters (shown with their default values) enable IP routing and TCP header compression:

By default, all new Connection profiles enable the routing of IP packets (the IP-Routing-Enabled parameter is set to Yes). The VJ-Header-Prediction parameter is also set to Yes by default, which specifies negotiation of Van Jacobson header prediction for TCP packets on incoming calls using encapsulation protocols that support this feature. You can change the defaults if necessary, but they are appropriate for most IP routing connections.

Example of a connection to a remote IP router

The following parameter (shown with a sample setting) specifies the IP address of a remote router:

When the remote station calls in, the MAX TNT matches the caller's source IP address to this parameter to find the right Connection profile. Figure 4-4 shows the MAX TNT connecting to a remote 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-4. Router-to-router IP connection

Because the MAX TNT includes a subnet mask in its own local IP address, it must use other routers to route to local IP addresses outside that subnet. To forward packets to other parts of the corporate network, the MAX TNT must either have a static route configuration to a router in its own subnet (such as the CPE router in Figure 4-4), or it must enable RIP on Ethernet. For related information, see Example of a default route.


Note: If you do not specify the subnet mask in the Remote-Address parameter, the MAX TNT inserts a default mask that assumes the entire far-end network is accessible. Normally, if the far-end router's address includes a mask, you should include it.

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-4:

To specify the local CPE router as the MAX TNT unit's default route:

For information about configuring other Connection profile parameters, see Chapter 2, WAN Connections and Appendix A, Access Security Settings.

Example of a dial-in host requiring a host route

The following parameter specifies the IP address of a dial-in host running PPP software:

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-5 shows a sample connection in which a dial-in host with an ISDN modem card calls into the MAX TNT.

Figure 4-5. Dial-in host requiring a static IP address (a host route)

The PPP configuration includes the host's address. For example:

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:

Example of a dial-in host requiring address assignment

This section assumes that you have configured address pools in the IP-Global profile, as described in Configuring address pools for dynamic assignment to dial-in hosts. Following are the parameters related to assigning an address to a dial-in connection, shown with their default values:

If the remote device is a dial-in host that accepts dynamic address assignment, leave the Remote-Address parameter blank and specify the number of the pool from which the MAX TNT can obtain an address for dynamic assignment to the host. Figure 4-6 shows the MAX TNT assigning an address from one of its defined pools to a dial-in host:

Figure 4-6. Dial-in host requiring assigned IP address

This example does not use the pool summary feature that enables the MAX TNT to advertise the entire pool of addresses rather than individual host routes for each assignment. (For further discussion of pool summary, see Configuring address pools for dynamic assignment to dial-in hosts.)

The PPP software on the dial-in host in Figure 4-6 is configured to acquire its IP address dynamically. For example, the PPP software could have the following configuration:

Following is an example of configuring a Connection profile to assign an IP address dynamically when the host dials in:

When Address-Pool is 0 (zero), the MAX TNT gets an IP address for this host from the first defined address pool. To assign an address within a specific range, specify a pool number from 1 to 128.

Example of a numbered-interface connection

In the usual routing operations (system-based routing), each interface that supports TCP/IP has an IP address and the system routes traffic to and from the interface based on the destination address in packets.

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. For a numbered interface, routing operations differ in the following ways:

To configure a numbered interface, use the following parameters, which are shown with sample settings:

Remote-Address is the remote system's IP address.

Local-Address is an IP address assigned to the local side of a numbered-interface connection. The address must be unique to the connection. 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 numbered interface need not be in the active state.)


Note: Local-Address cannot be an address assigned in an IP-Interface profile 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-7 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 sides of the numbered-interface connection.

Figure 4-7. A numbered interface connection

To configure this connection, the administrator enters the following commands:

Configuring WAN routing policies and preferences

At system startup, the MAX TNT adds a static route to the routing table for each LAN IP interface (configured IP-Interface profile) and for each WAN IP interface (configured Connection profile). For example, for a Connection profile with the following remote address:

the MAX TNT creates a static route with the following addresses:

Because each WAN connection is a routing table entry, you can configure routing policies and preferences for the route, just as you would for a static IP-Route profile. The following parameters configure routing policies and route preferences for the WAN connection:

For complete information about each parameter, see the MAX TNT Reference Guide.

Assigning a metric to the connection

Connection profiles often represent switched connections, which have an initial cost that you avoid if you use a nailed-up link to the same destination. The lower the metric assigned to a route (a connection), the more likely it is to be used as a means to a destination address. To favor nailed-up links, you can assign a higher metric to switched connections than to any of the nailed-up links that can go to the same place. The following set of commands assigns a high metric to the connection:

For information about configuring route metrics in RIP packets, see Chapter 9, Ascend Packet Filters.

Assigning a preference and down-preference

When choosing which route to use, the router first compares the 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. The value of 255 means "Don't use this route." For a discussion of route preferences see Configuring system-level routing policies and preferences.

The Down-Preference value should be high, so the MAX TNT will look for other routes when this connection is down. Following is an example of assigning preference values:

Making the connection route private

The Private-Route parameter specifies whether the MAX TNT will disclose the existence of this route when queried by RIP or another routing protocol. Private routes are used internally but are not advertised.

In some cases, making a route private is recommended. In the case of the pool summary feature, it is required. See Setting up summarized address pools (pool summary). Following is an example of making the Connection profile route private:

Enabling RIP on the connection

When you enable RIP in a Connection profile, you can specify whether the MAX TNT sends RIP updates across the WAN connection (informing other routers, on the remote network, of its routes), receives RIP updates from the remote router (including those routes in its routing table), or both. For related information, see Enabling RIP on a LAN interface. The commands in the following example set the unit to both send and receive RIP update packets on the connection named David:

You should run RIP version 2 (RIP-v2) if possible. 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.

For information about filtering routes in RIP update packets, see Chapter 9, Ascend Packet Filters.

Using client DNS

Client DNS configurations define the DNS servers presented to WAN connections during IPCP negotiation. The configurations provide a way to protect your local DNS information from WAN users. For details, see Appendix B, Network Security Settings.

Specifying client default gateways

A client default gateway is a connection-specific next-hop router. All packets received across the WAN connection are forwarded to the specified router. Client default gateways are typically used to ensure that traffic associated with a particular on-line service is sent through the router operated by that service.

The MAX TNT must be able to reach the specified router directly, in one hop. If the specified router is not a legitimate next-hop router, the MAX TNT drops packets received on the connection. It is important to bear this in mind if you encounter routing problems after configuring a client default gateway, because an error in the next-hop router address will not be apparent when you check the global routing table.

You configure a client default gateway by specifying its address in the following parameter (shown with its default value):

For example:

When a client default gateway is specified for a WAN connection, all packets received across the connection are forwarded to the specified next-hop router. If the remote device is another access router, the default gateway is used for packets sent by all hosts behind that router.

While all packets arriving on the interface using this profile are affected, packets from other connections or from the Ethernet are handled normally. Use of this feature does not alter the global routing table.

When a Connection profile specifies a client default gateway, the MAX TNT receives packets across the connection and consults the routing table in the usual way. It looks first for a specific route that matches the destination. If it finds no explicit route for packets received across this WAN connection, it uses the client default gateway instead of using the system default route or, if no system default route has been configured, dropping the packet.

Specifying IP-Direct connections

An IP Direct configuration allows IP packets received from an incoming connection to bypass the routing tables and be 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. Following is the related parameter, shown with a sample setting:

The IP-Direct parameter specifies the IP address of a next-hop destination to which all IP packets received across the link will be directed. The default is 0.0.0.0, which means that IP-Direct is disabled. Figure 4-8 shows an example of the IP-Direct traffic flow.

Figure 4-8. IP Direct connections

In Figure 4-8:

Packets destined for the clients A, B, or C 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:

IP-Direct connections require the following special handling:

All incoming packets on this connection are forwarded to the IP-Direct address. As a side-effect, a user on the remote network cannot Telnet to the MAX TNT, because the connection is passed through to the IP-Direct host.

Configuring static IP routes

When the MAX TNT starts up, it initially builds the routing table from its known static routes, which include those defined in IP-Interface profiles, Connection profiles, and IP-Route profiles. The routes in IP-Route profiles are also passed to the router whenever a route changes. Following are the related parameters, shown with sample settings:

OSPF-related settings

The following parameters (shown with default values) apply only when OSPF is enabled:

For information about how to configure IP-Route profiles for OSPF, see Chapter 5, OSPF Routing.

Example of a default route

When the MAX TNT consults its routing table, if it does not find a specific match for the packet's destination address, it looks for a default route. The default route specifies a zero destination address (0.0.0.0), which is interpreted as any destination. If the MAX TNT finds a default route, it forwards the packet to the specified gateway address (next-hop router). If it finds no specific destination match and no default route, the MAX TNT drops the packet.

Following are the parameters that define the default route (shown with a sample gateway address):

Figure 4-9 shows a router on a local interface configured as the default route in a MAX TNT. This type of configuration enables the MAX TNT to turn off RIP on its local interfaces, and forward all local packets to the default route.

Figure 4-9. Default route to a local IP router


Note: If you do not configure a default route, the MAX TNT drops packets for which it has no route. Many sites configure a local router as the default route to offload routing overhead to local networks and subnets.

The name of the default IP-Route profile is always Default and its destination is always 0.0.0.0. Although you might want to configure other parameters in the Default route profile, the only required setting is a Gateway-Address. The following example shows commands entered to configure the default route, and the system's responses:

Example of a static route

When dynamic route-discovery protocols such as RIP or OSPF are turned off on an IP interface, the router does not learn about routers on that interface, except those to which it has a static route. Following are the parameters that define a static route (shown with sample settings):

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-10 shows an example.

Figure 4-10. Static route to a remote subnet

In this example, the following commands configure a static route to the remote subnet:

Assigning a metric and preference to a static route

The Metric parameter is a virtual hop count (a number between 1 to 15) for the specified route. The higher the metric, the less likely that the MAX TNT will use the route.

The Preference parameter specifies a route preference. Zero is the default for connected routes (such as the Ethernet). When choosing which route to use, the router first compares the 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. The value of 255 means "Don't use this route." For a discussion of route preferences see Configuring system-level routing policies and preferences.

The commands in the following example set a relatively low metric and preference values for a route:

For information about configuring route metrics in RIP packets, see Chapter 9, Ascend Packet Filters.

Making a static route private

The Private-Route parameter specifies whether the MAX TNT will disclose the existence of this route when queried by RIP or another routing protocol. Private routes are used internally but are not advertised. Following is an example of making a route private:

Making a static route temporarily inactive

The Active-Route parameter is set to Yes by default, indicating that the route should be entered in the routing table. If you set the parameter to No, the MAX TNT leaves the route out of its routing table. This is a useful alternative to deleting the profile, if you might want to reinstate the route later.

Example of static multipath routes

Multipath static routes distribute traffic to one destination across the aggregated bandwidth of multiple interfaces. A multipath route requires static routes that meet the following criteria:

If more than one IP-Route profile has a destination of 0.0.0.0, the MAX TNT creates a multipath default route. Following is an example in which an administrator configures a multipath route to the network 10.76.109.0/24:

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 206.65.212.1 ie1-12-2 SGM 100 2 20 7772
10.76.109.0/24 206.65.210.1 ie1-12-3 SGM 100 2 24 7772


[Top][Contents][Prev][Next][Last]Search

techpubs@eng.ascend.com

Copyright © 1998, Ascend Communications, Inc. All rights reserved.