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.

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.

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.

Establishing a Static Route

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

Sending ICMP Unreachable Messages for Static Routes on Null Interfaces

You can handle undesired traffic by sending data packets to the null interface. The null interface is automatically created by the router, is always up, cannot be deleted, and acts as a data sink. The null interface cannot forward or receive traffic. However, the CLI does enable you to access the null interface. You can configure a static route using the ip route command and direct traffic to the null interface by specifying the null 0 keyword with this command, instead of a next-hop or destination address. You can also use access control lists to filter undesired traffic.

The following example shows an IPv4 static route configured with null 0 interface as the next-hop. In this example, the default behavior for packets reaching null 0 interfaces with static routes takes effect, which is to discard the received packets and not send ICMP unreachable messages to the originator.

When a ping or traceroute packet from a subscriber reaches the null 0 interface configured with a static route, it is discarded in the forwarding plane. You can configure the router to either send or not send ICMP unreachable messages to the subscriber for such discarded packets. An advantage of this feature is that it enables synchronization of the RADIUS configuration of the client environment with the network topology.

You can use the reject keyword with the ip route command to cause the router to send ICMP unreachable messages to the originator from which ping and traceroute packets are received on the null 0 interface with a static route. The SRP module drops these ping and traceroute packets destined for null 0 interface without further processing and sends ICMP unreachable messages to the originator.

For ICMP unreachable messages to be sent from the router for packets that are received from clients on the static routes configured on null 0 interfaces, you must configure the router to enable generation of ICMP unreachable messages for IPv4 (ping and traceroute) that the router cannot deliver using the ip unreachables command in Interface Configuration mode.

The option to send ICMP unreachable messages is available for all IPv4 static routes in a virtual router that are configured with null 0 interface as the next-hop. The Denial of Service (DoS) protection feature can be enabled to monitor the ping and traceroute packets that are discarded from flooding the network. A new DoS type is used to apply a rate-control limit on these packets.

To enable the transmission of ICMP unreachable messages for IPv4 packets that reach the static route configured on the null 0 interface and are discarded:

• From Global Configuration mode, use the ip route command with the reject keyword.
  host1(config)#ip route 192.168.10.0/24 null0 reject

To disable the transmission of ICMP unreachable messages for IPv4 packets that reach the static route configured on the null 0 interface and are discarded:

• From Global Configuration mode, use the ip route command with the discard keyword.
  host1(config)#ip route 192.168.10.0/24 null0 discard

By default, generation of ICMP unreachable messages is enabled on an interface. If the capability to generate ICMP unreachable messages is disabled on the interface, you must enable this functionality using the ip unreachables command in Interface Configuration mode to send ICMP unreachables for packets that reached null 0 interfaces with static routes and were discarded.

If you disable generation of ICMP unreachable messages for null interfaces on the router using the no ip unreachables command, ICMP unreachable messages are not sent for packets that are dropped or not processed by such interfaces, even if you configure static routes for such interfaces to send ICMP unreachables (using the reject keyword with the ip route command).

To enable backward compatibility with versions of JunosE software in which functionality is not available, the default behavior is to discard the ping and traceroute packets destined for null 0 interfaces at the forwarding layer without the transmission of ICMP unreachable messages to the originator.

You can use the output of the show ip static command to determine whether the sending of ICMP unreachable messages is enabled on each interface for which static routes are configured. The ICMP Unreach field in the output of these commands specifies whether the reject or discard keyword is configured for each static route on the router interface.

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

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

Shutting Down an IP Interface

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

Removing the IP Configuration

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

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.

Clearing IP Interfaces

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

Setting a Baseline

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

Disabling Forwarding of Packets

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

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.

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.

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.

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.

Enabling Link Status Traps

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

Configuring the Speed

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

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.

If all the ECMP links are configured for the ip multipath round-robin command and their next hops are direct next hops, the round-robin mode uses the random algorithm for traffic distribution.

In round-robin mode, if a packet uses a path, the next packet can choose the same path or the previous path, or the next path based on the random value generated. The random algorithm does not guarantee equal distribution of the packets among the ECMP links.

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.

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.

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.

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.

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.

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.

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.

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.