[Contents] [Prev] [Next] [Index] [Report an Error]

# IP Routing

The Internet is a large collection of hosts that communicate with each other and use routers as intermediate packet switches.

Routers forward a packet through the interconnected system of networks and routers until the packet reaches a router that is attached to the same network as the destination host. The router delivers the packet to the specified host on its local network.

## Routing Information Tables

A router makes forwarding decisions based on the information that is contained in its routing table. Routers announce and receive route information to and from other routers. They build tables of routes based on the collected information about all the best paths to all the destinations they know how to reach.

Each configured protocol has one or more local routing tables, sometimes referred to as a routing information base (RIB). This table is a database local to the protocol that contains all the routes known by that protocol to the prefixes in the table. For example, OSPF might have four different routes to 10.23.40.5.32. Only one of these routes is the best route to that prefix known to OSPF, but all four routes are in the OSPF local routing table.

The global routing table is a database maintained by IP on the SRP module. It contains at most one route per protocol to each prefix in the table. Each of these routes is the best route known by a given protocol to get to that prefix. The IP routing table does not, for example, have two OSPF routes to 10.5.11.0/24; it will have only one (if any) OSPF route to that prefix. It might also have a BGP route to the prefix, and a RIP route to the prefix, but no more than one route to a prefix per protocol.

IP compares the administrative distances for the routes to each prefix and selects the overall best route regardless of protocol. The best route to 10.5.11.0/24 might be via IS-IS. The best route to 192.168.0.0/16 might be via EBGP, and so on. These selected overall best routes to each prefix are used to create the forwarding table. The forwarding table is pushed to each line module. The line modules use their local instance of the forwarding table to forward the packets that they receive. When the global IP routing table is updated, so are the forwarding tables on the line modules.

Figure 10 illustrates a very simple network composed of three networks and two routers. The hosts that are attached to each network are not shown, because each router makes its forwarding decisions based on the network number and not on the address of each individual host. The router uses ARP to find the physical address that corresponds to the Internet address for any host or router on networks directly connected to it.

Figure 10: Routers in a Small Network

Table 3 and Table 4 represent information from the routing tables for routers NY and LA. Each routing table contains one entry for each route for each protocol or route type. Each routing table entry includes the following information:

- The destination IP network address.
- The IP address of the next-hop router.
- The type of network, such as static, directly connected, or the particular protocol.
- An administrative distance that is used to select the least-cost route among multiple routes to the same destination network. The least-cost (best) route is placed in the forwarding table. The administrative distance is not included in the forwarding table.
- A metric that is used by protocols to which the route is redistributed to select the least-cost route among multiple routes to the same destination network. The metric is not used to determine the best route to be placed in the forwarding table. The metric is also not listed in the forwarding table.

  Table 3: Routing Table for Router NY

  Destination Network | Next-Hop Router | Route Type | Administrative Distance | Metric
  --- | --- | --- | --- | ---
  10.1.0.0/16 | 10.1.0.1 | connected | 0 | 0
  10.2.0.0/16 | 10.5.0.3 | OSPF | 110 | 10
  10.2.0.0/16 | 10.5.0.3 | IS-IS | 115 | 10
  10.2.0.0/16 | 10.5.0.3 | EBGP | 20 | 15
  10.2.0.0/16 | 10.5.0.3 | RIP | 120 | 5
  10.5.0.0/30 | 10.5.0.2 | connected | 0 | 0

  Table 4: Routing Table for Router LA

  Destination Network | Next-Hop Router | Route Type | Administrative Distance | Metric
  --- | --- | --- | --- | ---
  10.1.0.0/16 | 10.5.0.2 | static | 1 | 0
  10.1.0.0/16 | 10.5.0.2 | OSPF | 110 | 10
  10.1.0.0/16 | 10.5.0.2 | RIP | 120 | 4
  10.2.0.0/16 | 10.2.0.1 | connected | 0 | 0
  10.5.0.0/30 | 10.5.0.3 | connected | 0 | 0

## Setting the Administrative Distance for a Route

The administrative distance is an integer that is associated with each route known to a router. The distance represents how reliable the source of the route is considered to be. A lower value is preferred over a higher value. An administrative distance of 255 indicates no confidence in the source; routes with this distance are not installed in the routing table.

Table 5 lists the default distance for each type of source from which a route can be learned.

Table 5: Default Administrative Distances for Route Sources

Route Source | Default Distance
--- | ---
Connected interface | 0
Static route | 1
Internal access route | 2
Access route | 3
External BGP | 20
OSPF | 110
IS-IS | 115
RIP | 120
Internal BGP | 200
Unknown | 255

If the IP routing table contains several routes to the same prefix—for example, an OSPF route and a RIP route—the route with the lowest administrative distance is used for forwarding.

To set the administrative distance for BGP routes, see JUNOSe BGP and MPLS Configuration Guide.

To set the administrative distance for RIP, IS-IS, and OSPF, use the following distance commands in Router Configuration mode.

distance

- Use to set an administrative distance for RIP or OSPF routes in the range 0–255.
- For RIP routes, the default value is 120.
- For OSPF routes, the default value is 110.
- Example
  `
  host1(config)#router rip
  host1(config-router)#distance 100
  `
- Use the no version to restore the default value.
- See distance

distance ip

- Use to set the administrative distance for IS-IS routes in the range 1–255.
- Example
  `
  host1(config)#router isis
  host1(config-router)#distance 80 ip
  `
- Use the no version to restore the default value of 115.
- See distance ip

## Setting the Metric for a Route

For information about how to set a metric for a route, see JUNOSe IP Services Configuration Guide as well as the individual routing protocol chapters in the JUNOSe BGP and MPLS Configuration Guide , and in this guide.

## Routing Operations

Routers keep track of next-hop information that enables a data packet to reach its destination through the network. A router that does not have a direct physical connection to the destination checks its routing table and forwards packets to another next-hop router that is closer to that destination. This process continues until the packet reaches its final destination.

## Identifying a Router Within an Autonomous System

The router ID is commonly one of the router’s defined IP addresses. Although the router ID is, by convention, formatted as an IP address, it is not required to be a configured address of the router. If you do not use the ip router-id command to assign a router ID, the router uses one of its configured IP addresses as the router ID.

ip router-id

- Use to assign a router ID—a unique identifier that IP routing protocols use to identify the router within an autonomous system.
- Example
  `
  host1(config)#ip router-id 192.32.15.23
  `
- Use the no version to remove the router ID assignment.
- See ip router-id

## Establishing a Static Route

You can set a destination to receive and send traffic by a specific route through the network.

ip route

- Use to establish a static route.
- Example
  `
  host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1
  `
- Use the no version to remove a static route from the routing table.
- See ip route

## Configuring Static Routes with Indirect Next Hops

You can configure static routes where next hops are not on directly connected interfaces. Such a route is usable, and appears in the route table, only if another route in the route table can resolve the next hop.

The resolving route can be either statically created or dynamically learned by a routing protocol (like RIP, BGP, OSPF, and so on).

| Note: When configuring this type of static route, the route that resolves the next hop must have an administrative distance value that is better (lower) than the distance of the static route you want to resolve.

Figure 11: Static Routes with Indirect Next Hops

On the Boston router in the network shown in Figure 11:

1. Configure a static route to 10.2.0.0/16 with a next hop of 10.5.0.2 (which is not directly connected) and an administrative distance of 254 (which is worse [higher] than the default administrative distance for static routes [1]).
   `
   host1(config)#ip route 10.2.0.0 255.255.0.0 10.5.0.2 254
   `
2. Configure another static route that resolves 10.5.0.2 and uses the default administrative distance.
   `
   host1(config)#ip route 10.5.0.0 255.255.255.252 10.1.0.2 [ 1 ]
   `

   | Note: The previous example shows the default administrative distance value, 1, to illustrate the difference between the two static route commands. However, you do not have to enter this value when issuing the command.

   A static route to 10.2.0.0 is added to the route table with a next hop of 10.1.0.2 (on the directly connected Ethernet interface).

   | Note: A dynamically learned route can also resolve indirect next hops, as long as the administrative distance value of the learned route is better (lower) than the static route whose next hop is being resolved.

## Verifying Next Hops for Static Routes

You can configure either Bidirectional Forwarding Detection (BFD) or Response Time Reporter (RTR) probes to further control when a static route is installed in the routing table. Using either BFD or RTR, static route installation is based on two factors: whether the next hop to the specified destination is resolved, and whether an IP service running above the static route application is currently available.

Next-hop verification is useful for static route configurations in which the layer 2 and layer 3 interfaces are up and the next hop to the specified destination is available, but the IP services that run above the static route are currently unavailable. When the upper-layer IP services are unavailable, the router does not install the static route in its routing table.

### How BFD Next-Hop Verification Works

Static routes on E-series routers can use Bidirectional Forwarding Detection (BFD) to verify the availability of the next hop and obtain the state of the IP service. For additional information about BFD, see JUNOSe IP Services Configuration Guide.

If you specify the bfd-liveness-detection keywords with a minimum receive interval, minimum transmit interval, or multiplier when you issue the ip route command to establish a static route, the router verifies the next-hop status and installs the static route in the routing table under the following conditions:

- You configure the static routes with the actual next hop address and not just interface details.
- The BFD protocol is operational on both ends of the verification.
- The next hop is adjacent to the router (that is, only one hop away).

  | Note: BFD next-hop verification does not currently function in a multi-hop configuration.

- The next hop to the specified IP destination address is resolved.

You can further control the installation of static routes by specifying the last-resort keyword, which is valid when you use the bfd-liveness-detection keywords in the ip route command. The last-resort keyword instructs the router to install the static route in the routing table even if the specified BFD operation is unreachable, provided that no other static route to the same network prefix is available.

The static route is removed from the routing table if the next hop is no longer reachable and reinstalled when the route becomes reachable again.

### BFD Next Hop Verification Configuration Example

To enable BFD next hop verification between two adjacent peers, you configure each peer as follows:

1. Configure peer A with the next hop address of peer B along with the desired intervals and keyword options.
   `
   host1(config)#ip route 192.1.1.0 255.255.255.0 192.1.2.1 verify bfd-liveness-detection minimum-interval 500 multiplier 3 last-resort
   `
2. Configure peer B with the next hop address of peer A along with the desired intervals and keyword options.
   `
   host1(config)#ip route 192.1.2.1 255.255.255.0 192.1.1.0 verify bfd-liveness-detection minimum-interval 300 multiplier 3
   `

ip route verify bfd-liveness-detection

- Use to enable BFD on a static route.
- Use the minimum-interval keyword to specify a value in the range 100–65535 milliseconds. This keyword defines both the minimum receive interval and minimum transmit interval using the same value.
- Use the minimum-receive-interval keyword to specify a minimum receive interval value in the range 100–65535 milliseconds.
- Use the minimum-transmit-interval keyword to specify a minimum transmit interval value in the range 100–65535 milliseconds.
- Use the multiplier keyword to specify a multiplier number in the range 1–255.
- Optionally, you can include the last-resort keyword when you use the verify bfd-liveness-detection keywords to instruct the router to install the static route in the routing table even if the specified BFD operation is currently unreachable, provided that no other static route to the same network prefix is available.
- Change parameters at any time without stopping or restarting the existing session; BFD automatically adjusts to the new parameter value. However, no changes to BFD parameters take place until the values resynchronize with each BFD peer.
- Example 1—Next hop address and last resort
  `
  host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1 verify bfd-liveness-detection minimum-interval 800 multiplier 2 last-resort
  `
- Example 2—Next hop address and interface
  `
  host1(config)#ip route 192.56.15.24 255.255.255.0 192.66.0.2 fast 6/0 verify bfd-liveness-detection
  `
- Example 3—Next hop address with different receive and transmit intervals
  `
  host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1 verify bfd-liveness-detection minimum-receive-interval 800 minimum-transmit-interval 300 multiplier 2 last-resort
  `
- Use the no version to remove the static route from the routing table and thereby remove BFD from that static route.
- See ip route

### How RTR Next-Hop Verification Works

Static routes on E-series routers can use Response Time Reporter (RTR) probes configured as echo (ping) types to verify the availability of the next hop and obtain the state of the IP service. For more information about using RTR, see Response Time Reporter.

If you specify the verify rtr keywords with an RTR operation number when you issue the ip route command to establish a static route, the router verifies the next-hop status and installs the static route in the routing table only if both of the following conditions are met:

- The next hop to the specified IP destination address is resolved.
- The specified RTR operation is currently reachable.

You can further control the installation of static routes by specifying the last-resort keyword, which is valid only when you use the verify rtr keywords in the ip route command. The last-resort keyword instructs the router to install the static route in the routing table even if the specified RTR operation is unreachable, provided that no other static route to the same network prefix is available.

Although the configuration example in the next section uses Fast Ethernet interfaces, E-series routers support next-hop verification on any type of lower-layer interface.

### RTR Configuration Example

Figure 12 shows a sample configuration that illustrates the next-hop verification feature. In this example, two Fast Ethernet interfaces are configured between a remote system and an E-series router: Fast Ethernet interface 4/0 and Fast Ethernet interface 4/1. At any given time, only one of these interfaces forwards IP traffic, even though the associated layer 2 interfaces may be up concurrently.

On the E-series router, Fast Ethernet interfaces 4/0 and 4/1 are configured as unnumbered IP interfaces. In addition, each interface has an RTR probe configured as an echo type that sends requests over the interface to determine its availability. RTR 10 sends requests over Fast Ethernet interface 4/0, and RTR 11 sends requests over Fast Ethernet interface 4/1.

In this example, both RTR 10 and RTR 11 use the IP address of the remote system (10.1.1.2) as the target address. When you configure multiple RTR entries to use the same target address, you must set the receive-interface attribute to specify the interface on which the probe expects to receive responses. (See Step 4c in the next section, Configuring RTR Next-Hop Verification.) This action enables the router to map incoming responses to the proper RTR entry, even when multiple RTR entries have the same target address.

Figure 12: Sample Configuration for Next-Hop Verification

The ip route command is issued for each interface with the verify rtr and last-resort keywords to establish the necessary static routes. (See Steps 6 and 7 in the next section, Configuring RTR Next-Hop Verification.) This command causes the results described in Table 6, based on the status of the associated RTR operations.

Table 6: Next-Hop Verification Results for Sample Configuration

RTR 10 Status | RTR 11 Status | Results
--- | --- | ---
Up | Up | The router installs an equal-cost multipath (ECMP) route to 10.1.1.2 in the routing table, using Fast Ethernet interfaces 4/0 and 4/1 as the next hops.
Up | Down | The router installs a route to 10.1.1.2, using Fast Ethernet interface 4/0 as the next hop.
Down | Up | The router installs a route to 10.1.1.2, using Fast Ethernet interface 4/1 as the next hop.
Down | Down | Although both RTR operations are down, the last-resort keyword instructs the router to install an ECMP route to 10.1.1.2, using Fast Ethernet interfaces 4/0 and 4/1 as the next hops. When all of the RTR operations associated with your static routes are down, you can control which route is installed in the routing table by including the last-resort keyword in the ip route verify rtr command only for the route that you want to install.

The next section, Configuring RTR Next-Hop Verification, provides instructions for configuring the example shown in Figure 12.

### Configuring RTR Next-Hop Verification

To configure the next-hop verification example shown in Figure 12:

1. Configure a loopback interface, and assign an IP address and mask to the interface.
   `
   host1(config)#interface loopback 0
   host1(config-if)#ip address 10.1.1.1 255.255.255.255
   host1(config-if)#exit
   `
2. Configure Fast Ethernet port 4/0 with an unnumbered primary IP interface associated with the loopback interface configured in Step 1.
   `
   host1(config)#interface fastEthernet 4/0
   host1(config-if)#ip unnumbered loopback 0
   host1(config-if)#exit
   `
3. Repeat Step 2 for Fast Ethernet port 4/1.
   `
   host1(config)#interface fastEthernet 4/1
   host1(config-if)#ip unnumbered loopback 0
   host1(config-if)#exit
   `
4. Define probe RTR 10 for Fast Ethernet interface 4/0.
   1. Assign an operation number to the RTR probe, and access RTR Configuration mode. For information, see Configuring the Probe Type.
      `
      host1(config)#rtr 10
      host1(config-rtr)#
      `
   2. Configure the RTR probe as an echo type, and set the IP destination address and source interface.

      You must configure the RTR probe as an echo type to use next-hop verification. For information, see Configuring the Probe Type.

      `
      host1(config-rtr)#type echo protocol ipIcmpEcho 10.1.1.2
      source fastEthernet 4/0
      `
   3. Specify the interface on which the RTR probe expects to receive responses.

      You must set the receive-interface attribute when multiple RTR operations use the same target address. For information, see Setting the Receiving Interface.

      `
      host1(config-rtr)#receive-interface fastEthernet 4/0
      `
   4. (Optional) Configure optional probe characteristics, such as the frequency and samples-of-history kept. For information, see Configuring Optional Characteristics.
      `
      host1(config-rtr)#frequency 1
      host1(config-rtr)#samples-of-history-kept 0
      `
   5. Exit RTR Configuration mode.
      `
      host1(config-rtr)#exit
      `
   6. Enable the probe to react to the test-failure event and the test-completion event.

      You must configure both the test-failure and test-completion reaction conditions to use next-hop verification. For information, see Setting Reaction Conditions.

      `
      host1(config)#rtr reaction-configuration 10 test-failure 3
      host1(config)#rtr reaction-configuration 10 test-completion
      `
   7. Schedule the probe operation. For information, see Scheduling the Probe.
      `
      host1(config)#rtr schedule 10 life 3
      host1(config)#rtr schedule 10 restart-time 1
      host1(config)#rtr schedule 10 start now
      `
5. Repeat Step 4 to define RTR 11 for Fast Ethernet interface 4/1.
   `
   host1(config)#rtr 11
   host1(config-rtr)#type echo protocol ipIcmpEcho 10.1.1.2
   source fastEthernet 4/1
   host1(config-rtr)#receive-interface fastEthernet 4/1
   host1(config-rtr)#frequency 1
   host1(config-rtr)#samples-of-history-kept 0
   host1(config-rtr)#exit
   host1(config)#rtr reaction-configuration 11 test-failure 3
   host1(config)#rtr reaction-configuration 11 test-completion
   host1(config)#rtr schedule 11 life 3
   host1(config)#rtr schedule 11 restart-time 1
   host1(config)#rtr schedule 11 start now
   `
6. Establish a static route associated with RTR 10.

   This command creates a static route and installs it in the routing table only if RTR 10 is currently reachable or if no other static route to IP destination address 10.1.1.2 is usable.

   `
   host1(config)#ip route 10.1.1.2 255.255.255.255 10.1.1.2 fastEthernet 4/0 verify rtr 10 last-resort
   `
7. Establish a static route associated with RTR 11.

   This command creates a static route and installs it in the routing table only if RTR 11 is currently reachable or if no other static route to IP destination address 10.1.1.2 is usable.

   `
   host1(config)#ip route 10.1.1.2 255.255.255.255 10.1.1.2 fastEthernet 4/1 verify rtr 11 last-resort
   `

   When both RTR 10 and RTR 11 are unreachable, you can control which static route is installed in the routing table by including the last-resort keyword in the ip route verify rtr command only for the route that you want to install.

   | Note: For detailed information about the commands for configuring RTR probes, see Response Time Reporter.

interface fastEthernet

- Use to select a Fast Ethernet (FE) interface on a line module or an SRP module.
- Example
  `
  host1(config)#interface fastEthernet 1/0
  `
- Use the no version to remove IP from an interface or subinterface. You must issue the no version from the highest level down; you cannot remove an interface or a subinterface if the one above it still exists.

  | Note: For more details on use of this command, see the syntax description in the JUNOSe Command Reference Guide.

- See interface fastEthernet

interface loopback

- Use to access and configure a loopback interface.
- You can use a loopback interface to provide a stable IP address that can minimize the impact if a physical interface goes down.
- Example
  `
  host1(config)#interface loopback 10
  host1(config-if)#ip address 100.20.32.1 255.255.255.255
  `
- You cannot shutdown a loopback interface.

  | Best Practice: We recommend that you configure a 32-bit subnet mask for the loopback interface. For example, if you configure a loopback interface with the IP address and mask as 1.1.1.1/16, the 1.1.0.0/16 route entry is entered on the line module and all traffic destined to the to 1.1.0.0/16 subnet is forwarded to the SRP module by the line module. Although the SRP module responds only to traffic destined to the 1.1.1.1 subnet and discards traffic to all other host IP addresses within that subnet (1.1.1.1/16), if no specific or longer route entry is found or if the SRP module receives too much traffic from subnets other than 1.1.1.1, the CPU utilization on the SRP module reaches the saturation level. If you use a subnet mask other than a /32 mask for the IP address configured on the loopback interface, traffic from the entire subnet is routed to the loopback interface. Therefore, that subnet cannot be routed through any other interface on the router, unless a more specific route points to another interface.

- Use the no version to delete the loopback interface.
- See interface loopback

ip address

- Use to set an IP address for an interface or a subinterface.
- Specify the layer 2 encapsulation before you set the IP address.
- Example
  `
  host1(config-subif)#ip address 192.0.2.50 255.255.255.0
  `
- Use the no version to remove the IP address or to disable IP processing on the interface.
- See ip address

ip route verify rtr

- Use to establish a static route and associate it with a configured RTR operation.
- Use the verify rtr keywords to instruct the router to install the static route in the routing table only if the next hop to the specified destination address is resolved and if the specified RTR operation is currently reachable. When you use the verify rtr keywords, you must also specify the number of the associated RTR operation.
- Optionally, you can include the last-resort keyword when you use the verify rtr keywords to instruct the router to install the static route in the routing table even if the specified RTR operation is currently unreachable, provided that no other static route to the same network prefix is available.
- Example
  `
  host1(config)#ip route 10.1.1.5 255.255.255.0 10.1.1.5 fastEthernet 1/0 verify rtr 5 last-resort
  `
- Use the no version to remove a static route from the routing table.
- See ip route

ip unnumbered

- Use to configure an unnumbered IP interface.
- This command enables IP processing on an interface without assigning an explicit IP address to the interface.
- You must specify an interface location, which is the identifier of another interface on which the router has an assigned IP address. This interface cannot be another unnumbered interface.
- Example 1
  `
  host1(config-if)#ip unnumbered fastEthernet 3/0
  `
- Example 2
  `
  host1(config-if)#ip unnumbered loopback 10
  `
- Use the no version to disable IP processing on the interface.
- See ip unnumbered

## Setting Up Default Routes

A router examines its routing table to find a path for each packet. If the router cannot locate a route, it must discard the packet. You can set up a default route using the special address: 0.0.0.0. If the router cannot locate a path to a destination network and a default route is defined, the router forwards the packet to the default router. For example:

`

host1(config)#ip route 0.0.0.0 0.0.0.0 192.56.21.3

`

Default routes are typically used to reduce the size of the routing table. Routing is simplified because the router can test for a few local networks or use the default route. However, a disadvantage of default routes is the possible creation of multiple paths and routing loops.

## Setting Up an Unnumbered Interface

An unnumbered interface does not have an IP address assigned to it. Unnumbered interfaces are often used in point-to-point connections where an IP address is not required.

ip unnumbered

- Use to set up an unnumbered interface.
- This command enables IP processing on an interface without assigning an explicit IP address to the interface.
- You supply an interface location, which is the type and number of another interface on which the router has an assigned IP address. This interface cannot be another unnumbered interface.
- Example
  `
  host1(config-if)#ip unnumbered fastEthernet 0/0
  `
- Use the no version to disable IP processing on an interface.
- See ip unnumbered

## Adding a Host Route to a Peer on a PPP Interface

You can enable the ability to create host access routes on a PPP interface. This feature is useful in B-RAS applications.

ip access-routes

- Use to enable the ability to create host access routes on a PPP interface.
- Example
  `
  host1(config-if)#ip access-routes
  `
- Use the no version to disable this feature.
- See ip access-routes

## Enabling Source Address Validation

Source address validation verifies that a packet has been sent from a valid source address. When a packet arrives on an interface, the router performs a routing table lookup using the source address. The result from the routing table lookup is an interface to which packets destined for that address are routed. This interface must match the interface on which the packet arrived. If it does not match, the router drops the packet.

ip sa-validate

- Use to enable source address validation.
- Example
  `
  host1(config-if)#ip sa-validate
  `
- Use the no version to disable source address validation.
- See ip sa-validate

## Enabling Source Address Validation Traps

The ip sa-validate trap-enable command enables the generation of traps for source address validation failure.

| Note: To fully enable source address validation traps, you must also enable the IP trap category with the snmp-server trap enable command. See JUNOSe System Basics Configuration Guide for more information.

ip sa-validate trap-enable

- Use to enable the generation of traps for source address validation failure on the router.
- You can specify a VRF context for which you want to enable trap validation for source address validation.
- Example
  `
  host1(config)#ip sa-validate trap-enable
  `
- Use the no version to disable the generation of source address validation failure traps on the router.
- See ip sa-validate trap-enable

## Defining TCP Maximum Segment Size

The ip tcp adjust-mss command enables you to modify the TCP maximum segment size (MSS) for TCP sessions.

When defined, the router modifies the maximum segment size (MSS) for TCP SYN packets traveling through the interface. The modification occurs only for packets that contain values smaller than the adjusted MSS value. When the packet does not contain an MSS field value, the router assumes an MSS value of 536 and makes any modifications accordingly.

| Note: Implementation of the MSS value is identical for both ingress and egress interface traffic. That is, the router uses the same MSS value when adjusting inbound or outbound TCP traffic.

ip tcp adjust-mss

- Use to modify the maximum segment size (MSS) for TCP SYN packets traveling through the interface. The router compares the MSS value of incoming or outgoing packets against the adjusted MSS setting and replaces smaller values that it detects in any packets with the larger setting. If the packet does not contain an MSS value, the router assumes a value of 536 for the packet MSS on which to base the comparison.

  | Note: The purpose behind using MSS is to alleviate problems with Path Discovery (PMTUD) and resulting “ black hole” detection issues. (See RFC 2923, “ TCP Problems with Path MTU Discovery,” for additional information about the “ black hole” scenario.)

- Example
  `
  host1(config-if)#ip tcp adjust-mss 1000
  `
- Use the no version to remove the MSS assignment from the profile.
- See ip tcp adjust-mss

## Setting MSS for TCP Connections

MSS is used by TCP to define the maximum amount of data that a TCP interface can accept in any single packet (or segment size). The MSS value is typically negotiated during connection establishment and is not renegotiated.

By default, the router uses an MSS value of 536 bytes and the advertised MSS is derived from the MTU of the transmitting interface. However, you can use the tcp mss command to set the MSS for TCP advertisements.

tcp mss

- Use to specify the MSS value for TCP to advertise.

  | Note: The MSS value is equal to the MTU value minus the IP and TCP headers, so the MSS value is generally 40 bytes less than the MTU.

- Use the vrfName variable to specify a VRF to which you want to assign the TCP MSS value.
- Example
  `
  host1(config-if)#tcp mss 1000
  `
- Use the no version to remove the MSS value so that the router uses the advertised MSS derived from the MTU of the output interface.
- See tcp mss

## Configuring IP Path MTU Discovery

IP hosts transmit large amounts of data to other hosts using a series of IP datagrams. To best use resources, increase performance, and avoid difficult reassembly, hosts try to send datagrams that are as large as possible without requiring fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the path MTU (PMTU), and it is equal to the smallest MTU for each hop in the path.

Path MTU discovery is the process of discovering the PMTU value and using that value when transmitting TCP packets in datagrams.

### Enabling PMTU Discovery

Use the tcp path-mtu-discovery command to enable PMTU discovery on the active virtual router.

tcp path-mtu-discovery

- Use to enable and configure path MTU discovery on the virtual router.
- Issue the command without any keywords to enable path MTU discovery.
- Issue the age-timer keyword to set the time (minutes) that TCP waits before attempting to increase the path MTU after receiving an ICMP Too Big message or after previously increasing the PMTU successfully (minutes2). The range of these two timers is 1–30 minutes. The timer defaults to 10 minutes.
- Issue the age-timer infinite keyword to disable PMTU aging functions.
- Example 1—Enables path MTU discovery
  `
  host1:VR1(config)#tcp path-mtu-discovery
  `
- Example 2—Sets path MTU discovery age timers differently
  `
  host1:VR1(config)#tcp path-mtu-discovery age-timer 20 15
  `
- Example 3—Sets path MTU discovery age timers to the same value
  (5 minutes)
  `
  host1:VR1(config)#tcp path-mtu-discovery age-timer 5
  `
- Example 4—Disables path MTU discovery age timers
  `
  host1:VR1(config)#tcp path-mtu-discovery age-timer infinite
  `
- Use the no version with a keyword to return the value to its default. Issue the no version without any keywords to disable path MTU discovery on the virtual router.
- See tcp path-mtu-discovery

### Limiting PMTU

You can limit calculated PMTU values within a range by using the tcp path-mtu-discovery max-mtu and tcp path-mtu-discovery min-mtu commands. When specifying PMTU limits, keep the following in mind:

- If a PMTU discovery value is lower than the configured minimum MTU setting, PMTU discovery is disabled for that connection.
- If a PMTU discovery value is larger than the configured maximum MTU setting, the configured maximum MTU setting is used.
- The maximum MTU setting must be greater than the minimum MTU setting.

tcp path-mtu-discovery max-mtu

- Use to limit the maximum MTU size used for the path MTU.
- Example
  `
  host1:VR1(config)#tcp path-mtu-discovery max-mtu 512
  `
- Use the no version to remove any limitation so that the virtual router uses the path MTU discovery value.
- See tcp path-mtu-discovery

tcp path-mtu-discovery min-mtu

- Use to specify the minimum MTU value used for the path MTU. If the discovered PMTU value is less than the minimum setting, path MTU discovery is disabled for this connection.
- Example
  `
  host1:VR1(config)#tcp path-mtu-discovery min-mtu 255
  `
- Use the no version to remove any limitation so that the virtual router uses the discovered path MTU value.
- See tcp path-mtu-discovery

### Specifying Black Hole Thresholds

A black hole threshold is a limit to the number of times a virtual router can retransmit identical sequences of datagrams before the retransmissions are identified as a problem.

Some domains might be configured not to generate certain ICMP messages (like an ICMP destination unreachable message) or to filter all ICMP messages. Under these conditions, the source of oversized ICMP packets never learns that it is sending oversized packets. The device continues sending oversized packets that never get through. This behavior is often referred to as a black hole.

tcp path-mtu-discovery black-hole-detect-threshold

- Use to specify the minimum MTU value used for the path MTU. If the discovered PMTU value is less than the minimum setting, path MTU discovery is disabled for this connection.
- Example
  `
  host1:VR1(config)#tcp path-mtu-discovery black-hole-detect-threshold 200
  `
- Use the no version to disable black hole threshold detection.
- See tcp path-mtu-discovery

## Shutting Down an IP Interface

You can disable an interface to the router at the IP level without removing it.

ip shutdown

- Use to shut down an IP interface.
- Example
  `
  host1(config-if)#ip shutdown
  `
- Use the no version to restart the interface.
- See ip shutdown

## Removing the IP Configuration

You can remove the IP configuration from an interface or subinterface.

no ip interface

- Use to remove the IP configuration from an interface or subinterface and disable IP processing on the interface.
- Example
  `
  host1(config-if)#no ip interface
  `
- See no ip interface

## Clearing IP Routes

The router enables you to clear the specified routing entries from the routing table. You must specify the IP address prefix and the mask of the IP address prefix to clear specific routes. You can later reinstall the routes you have cleared.

clear ip routes

- Use to clear specified IP routes according to an IP prefix or a VPN routing and forwarding (VRF) table.
- Use an asterisk (*) to clear all dynamic routes from the routing table.
- Example
  `
  host1#clear ip routes *
  `
- There is no no version.
- See clear ip routes

ip refresh-route

- Use to enable the owning protocols (BGP, IS-IS, OSPF) to reinstall routes removed from the IP routing table by the clear ip routes command.
- Example
  `
  host1#ip refresh-route
  `
- There is no no version.
- See ip refresh-route

## Clearing IP Interfaces

The router enables you to clear the counters on one or more specified IP interfaces.

clear ip interface

- Use to clear a specified IP interface.
- Example
  `
  host1#clear ip interface pos 2/0
  `
- There is no no version.
- See clear ip interface

## Setting a Baseline

The router enables you to set a baseline for statistics on an IP interface.

baseline ip interface

- Use to set a baseline for a specified IP interface.
- Example
  `
  host1#baseline ip interface pos 2/0
  `
- There is no no version.
- See baseline ip interface

## Disabling Forwarding of Packets

The router enables you to disable forwarding of packets on an SRP Ethernet interface.

ip disable-forwarding

- Use to disable forwarding of packets on the SRP Ethernet interface.
- The purpose of this command is to maintain router performance by maximizing the CPU time available for routing protocols. Although you can allow data forwarding on the SRP Ethernet interface, router performance will be affected.
- You see an error message if you try to set this command for interfaces other than the SRP Ethernet interface.
- Example
  `
  host1(config-if)#ip disable-forwarding
  `
- Use the no version to enable forwarding of packets on the interface.
- See ip disable-forwarding

## Enabling Forwarding of Source-Routed Packets

IP packets are normally routed according to the destination address they contain based on the routing table at each hop through a path. The originator or source of the source-routed packets specifies the path (the series of hops) that the packets must traverse; the source makes the routing decisions. The source can specify either of the following types of source routing:

- Strict-source routing specifies every hop that the packet must traverse. The specified path consists of adjacent hops. The source generates an ICMP error if the exact path cannot be followed. For example, for a path going from source router A to router B to router C to router D, router A specifies a strict-source route as B, C, D.
- Loose-source routing specifies a set of hops that the packet must traverse, but not necessarily every hop in the path. That is, the specified hops do not have to be adjacent. For example, for a path going from source router A to router B to router C to router D, router A specifies a loose-source route as B, D or C, D, or B, C, D.

ip source-route

- Use to enable forwarding of source-routed packets in a VR or VRF.
- Forwarding is disabled by default in all VRs.
- Example
  `
  host1(config)#ip source-route
  `
- Use the no version to disable forwarding of source-routed packets on the VR or VRF.
- See ip source-route

## Forcing an Interface to Appear Up

The router enables you to force an IP interface to appear as if it is up, regardless of the state of the lower layers.

ip alwaysup

- Use to force an IP interface to appear as up regardless of the state of lower layers.
- This command reduces route topology changes when the network attached to this link is single-homed.
- Example
  `
  host1(config-if)#ip alwaysup
  `
- Use the no version to make the interface appear in the current state.
- See ip alwaysup

## Specifying a Debounce Time

You can set a debounce time that requires an IP interface to be in a given state—for example, up or down—for the specified time before the state is reported. This feature prevents a link that briefly goes up or down from causing an unnecessary topology change, for example by causing an interface down condition. However, note that increasing the debounce time increases the latency of updating the routing table to reflect an up or down change, and the latency of routing protocols propagating the state change.

ip debounce-time

- Use to set the interval in milliseconds for which an interface must maintain a given state before the state change is reported.
- Example
  `
  host1(config)#ip debounce-time 5000
  `
- Use the no version to remove the debounce time requirement.
- See ip debounce-time

## Adding a Description

The router enables you to add a text description or an alias to a static IP interface or subinterface. Adding a description helps you identify the interface and keep track of interface connections. If no IP interface currently exists, then a static IP interface is automatically created on the current layer 2 interface and the description is applied to that static IP interface. You cannot assign a profile to a layer 2 interface that has a static interface configured above it.

| Note: The ip description command is replacing the description command to assign a description to a static IP interface.

ip description

- Use to assign a text description or an alias to an IP interface or subinterface.
- The description or alias can be a maximum of 256 characters.
- Use the show ip interface command to display the text description.
- Example 1
  `
  host1(config-if)#ip description canada01 ip interface
  `
- Example 2
  `
  host1(config-subif)#ip description montreal011 ip subinterface
  `
- Use the no version to remove the text description or alias.
- See ip description

## Enabling Link Status Traps

The router enables you to enable link status traps on an interface.

snmp trap ip link-status

- Use to enable link status traps on an interface.
- Example
  `
  host1(config-if)#snmp trap ip link-status
  `
- Use the no version to disable link status traps on an interface.
- See snmp trap ip link-status

## Configuring the Speed

The router enables you to set the speed of an IP interface.

ip speed

- Use to set the speed of the interface in bits per second.
- By default, the speed is determined from a lower-layer interface.
- Example
  `
  host1(config-if)#ip speed 1000
  `
- Use the no version to set the speed to the default, 0.
- See ip speed

## Configuring Equal-Cost Multipath Load Sharing

Equal-cost multipath (ECMP) sets are formed when the router finds routing table entries for the same destination with equal cost. The router then balances traffic across these sets of equal-cost paths by using one of two ECMP modes—hashed (the default) or round-robin.

Hashed mode uses hashing of source and destination addresses to determine which of the available paths in the ECMP set to use. Hashed mode is the default ECMP mode of operation.

### Defining Maximum Paths

You can add routing table entries manually (as static routes), or they are formed as routers discover their neighbors and exchange routing tables (via OSPF, BGP, and other routing protocols).

The maximum paths command controls the maximum number of parallel routes that the routing protocol (BGP, IS-IS, OSPF, or RIP) can support.

### Round-Robin Mode

Round-robin mode distributes packets equally among the available paths in the ECMP set.

ip multipath round-robin

- Use to specify round-robin as the mode for ECMP load sharing on an interface.
- ECMP uses the round-robin mode when you have configured all interfaces in the set to round-robin. Otherwise, ECMP defaults to hashed mode because round-robin mode can cause reordering of packets. You must explicitly ensure that the possible reordering is acceptable on all the member interfaces by setting them to round-robin mode.
- If one of the ECMP next hops is an indirect next hop, ECMP uses hashed mode load balancing.
- Example
  `
  host1(config)#virtual-router router_0
  host1:router_0(config)#interface serial 4/0:1/22.22
  host1:router_0(config-subif)#ip multipath round-robin
  host1:router_0(config-subif)#exit
  `

- Use the no version to set the ECMP mode to the default, hashed.
- See ip multipath round-robin

maximum-paths

- Use to control the maximum number of parallel routes that the routing protocol supports.
- The maximum number of routes can be in the range 1–16 for BGP, IS-IS, OSPF, or RIP.
- Example
  `
  host1(config-router)#maximum-paths 2
  `
- Use the no version to restore the default value, 1 for BGP or 4 for IS-IS, OSPF, or RIP.
- See maximum-paths

### Fast Reroute Protection

If a link goes down, ECMP uses fast reroute protection to shift packet forwarding to use operational links, thereby decreasing packet loss. Fast reroute protection updates ECMP sets for the interface without having to wait for the route table update process. When the next route table update occurs, a new ECMP set can be added with fewer links or the route might point to a single next hop.

| Caution: To provide ECMP fast reroute functionality in the event of an interface failure, the members of an equal cost multipath must be resolved to corresponding interfaces. If the member is an indirect next hop, the interface is obtained by using the forwarding equivalence class (FEC) to which the member points. This method of resolving members occurs only if the FEC, pointed to by the indirect next hop, is either an interface or a direct next hop. An indirect next hop member is not resolved to an interface if it points to another indirect next hop or to an equal cost multipath. ECMP fast reroute functionality is not available if any interfaces that correspond to unresolved indirect next hop members go down. If you modify an indirect next hop member to point to a different FEC (that is, a different interface, direct next hop, indirect next hop, or ECMP), the indirect next hop member is not resolved for the new changes.

## Setting a TTL Value

You can use the ip ttl command to set the TTL (time-to-live) field in the IP header for all IP operations. The TTL specifies a hop count. This configured TTL value can be overridden by other commands that specify a TTL.

ip ttl

- Use to set a default value for the IP header TTL field for all IP operations.
- Example
  `
  host1(config)#ip ttl 255
  `
- Use the no version to restore the default value, 127.
- See ip ttl

## Protecting Against TCP RST or SYN DoS Attacks

You can use the tcp ack-rst-and-syn command to help protect the router from denial of service (DoS) attacks.

Normally, when it receives an RST or SYN message, TCP attempts to shut down the TCP connection. This action is expected under normal conditions, but someone maliciously generating valid RST or SYN messages can cause problems for TCP and the network as a whole.

When you enable the tcp ack-rst-and-syn command, the router challenges any RST or SYN messages that it receives by sending an ACK message back to the expected source of the message. The source reacts in one of the following ways:

- If the source did send the RST or SYN message, it recognizes the ACK message to be spurious and resends another RST or SYN message. The second RST or SYN message causes the router to shut down the connection.
- If the source did not send the RST or SYN message, the source accepts the ACK message as part of an existing connection. As a result, the source does not send another RST or SYN message and the router does not shut down the connection.

  | Note: Enabling this command slightly modifies the way TCP processes RST or SYN messages to ensure that they are genuine.

tcp ack-rst-and-syn

- Use to help protect the router from TCP RST and SYN denial of service attacks.
- Example
  `
  host1(config)#tcp ack-rst-and-syn
  `
- Use the no version to disable this protection.
- See tcp ack-rst-and-syn

## Preventing TCP PAWS Timestamp DoS Attacks

The TCP Protect Against Wrapped Sequence (PAWS) number option works by including the TCP timestamp option in all TCP headers to help validate the packet sequence number.

Normally, in PAWS packets that have the timestamps option enabled, hosts use an internal timer to compare the value of the timestamp associated with incoming segments against the last valid timestamp the host recorded. If the segment timestamp is larger than the value of the last valid timestamp, and the sequence number is less than the last acknowledgement sent, the host updates its internal timer with the new timestamp and passes the segment on for further processing.

If the host detects a segment timestamp that is smaller than the value of the last valid timestamp or the sequence number is greater than the last acknowledgement sent, the host rejects the segment.

A remote attacker can potentially determine the source and destination ports and IP addresses of both hosts that are engaged in an active connection. With this information, the attacker might be able to inject a specially crafted segment into the connection that contains a fabricated timestamp value. When the host receives this fabricated timestamp, it changes its internal timer value to match. If this timestamp value is larger than subsequent timestamp values from valid incoming segments, the host determines the incoming segments as being too old and discards them. The flow of data between hosts eventually stops, resulting in a denial of service condition.

Use the tcp paws-disable command to disable PAWS processing.

| Note: Disabling PAWS does not disable other processing related to the TCP timestamp option. This means that even though you disable PAWS, a fabricated timestamp that already exists in the network can still pollute the database and result in a successful DoS attack. Enabling PAWS resets the saved timestamp state for all connections in the virtual router and stops any existing attack.

tcp paws-disable

- Use to disable the Protect Against Wrapped Sequence (PAWS) number option in TCP segments.
- You can specify a VRF context for which you want PAWS disabled.
- Example
  `
  host1(config)#tcp paws-disable
  `
- Use the no version to restore PAWS processing (the default mode).
- See tcp paws-disable

## Protecting Against TCP Out of Order DoS Attacks

You can use the group of tcp resequence-buffers commands to help protect the router from TCP out-of-order DoS attacks.

TCP guarantees that applications receive data in order. This means that TCP buffers any out-of-order packets it receives until ordered delivery can occur. To prevent buffers from consuming too many resources, TCP limits the amount of data it accepts to the number of data bytes that the receiver is willing to receive and buffer.

TCP does not take into account the buffering scheme that the receiver uses. If the receiver uses a fixed-size receive buffer (that is, buffering all packets) regardless of length, a packet that contains only one data byte might consume many data bytes of buffer space, but only one byte of TCP space.

Under these conditions, an attacker can send a large number of 1-byte packets to an E-series router in which each packet is buffered, consuming an entire packet buffer and eventually consuming a large amount of resources.

To defend against this sort of attack, you can set defaults and limits on the number of outstanding buffers on reordering queues. You can configure these defaults and limits on a per-router, per-virtual router, or per-connection basis.

### Limiting Buffers per Router

The tcp resequence-buffers global-maximum command enables you to limit the number of outstanding buffers on the entire router.

tcp resequence-buffers global-maximum

- Use to specify a router-wide maximum number of buffers that resequencing queues can contain.
- Specify a value of zero (0) to turn off the limit.
- Example
  `
  host1(config)#tcp resequence-buffers global-maximum
  `
- Use the no version to revert the global maximum buffer value to its default, 1000 buffers.
- See tcp resequence-buffers global-maximum

### Limiting Buffers per Virtual Router

The tcp resequence-buffers default-vr-maximum command and tcp resequence-buffers vr-maximum command enable you to limit the number of outstanding buffers on existing or newly established virtual routers.

tcp resequence-buffers default-vr-maximum

- Use to specify the default buffer limit assigned to all virtual routers when the virtual router is established.
- Specify a value of zero (0) to turn off the limit assignment.
- Example
  `
  host1(config)#tcp resequence-buffers default-vr-maximum 200
  `
- Use the no version to revert the virtual router maximum value to its default, 100 buffers.
- See tcp resequence-buffers default-vr-maximum

tcp resequence-buffers vr-maximum

- Use to define the maximum number of buffers that the current or specified virtual router can use.
- Specify a value of zero (0) to turn off the limit assignment.
- Example
  `
  host1(config)#tcp resequence-buffers vr-maximum
  `
- Use the no version to revert the virtual router maximum value to its default, 100 buffers.
- See tcp resequence-buffers vr-maximum

### Limiting Buffers per Connection

The tcp resequence-buffers connection-maximum command and tcp resequence-buffers default-connection-maximum command enable you to limit the number of outstanding buffers on existing or newly established connections.

tcp resequence-buffers connection-maximum

- Use to define the maximum number of buffers that connections on the current or specified virtual router can use.
- Specify a value of zero (0) to turn off the connection maximum.
- Example
  `
  host1(config)#tcp resequence-buffers connection-maximum 50
  `
- Use the no version to revert the connection maximum value to its default,
  10 buffers.
- See tcp resequence-buffers connection-maximum

cp resequence-buffers default-connection-maximum

- Use to specify the default buffer limit assigned to all TCP connections on a virtual router unless a specific limit is set for the VR in which the connection is established.
- Specify a value of zero (0) buffers to turn off the default limit.
- Example
  `
  host1(config)#tcp resequence-buffers default-connection-maximum 100
  `
- Use the no version to revert the connection maximum value to its default, 10 buffers.
- See tcp resequence-buffers default-connection-maximum

## Distributing Routing Table Updates to Line Modules

You can configure the forwarding table hold-down time allotted after a routing table change for the accumulation of additional updates and the subsequent distribution of the set of routing table changes to the line modules.

forwarding-table route-holddown

- Use to enhance SRP performance by increasing the hold-down time allotted for accumulating and distributing sets of routing table changes to the line modules.
- A higher timer value can enhance SRP performance, but it can also delay the implementation of routing table changes on the line modules. Be aware of the possible effect on network performance before you reconfigure the forwarding table hold-down timer.
- Setting the hold-down timer to zero (0) distributes an update after each change to the routing table, which can degrade SRP performance.
- Example
  `
  host1(config)#forwarding-table route-holddown 15
  `
- Use the no version to set the hold-down timer to the default value, 3 seconds.
- See forwarding-table route-holddown

## IP Tunnel Routing Table

The IP tunnel routing tables include IPv4 routes that point only to tunnels, such as MPLS tunnels. The tunnel routing table is not used for forwarding. Instead, protocols resolve next hops by looking up the routes that point to tunnels. The routes in the tunnel routing table cannot be redistributed. See JUNOSe BGP and MPLS Configuration Guide for more information.

[Contents] [Prev] [Next] [Index] [Report an Error]