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

JUNOSe 9.1.x IP, IPv6, and IGP Configuration Guide > Configuring IP > IP Routing

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 4 and Table 5 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:

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 6 lists the default distance for each type of source from which a route can be learned. 





 Table 6:  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 Setting the Administrative Distance for a Route in JUNOSe BGP and MPLS Configuration Guide, Chapter 1, Configuring BGP Routing.

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

distance

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, Chapter 1, Configuring Routing Policy 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

Establishing a Static Route

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

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]).
    2. 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.
    3. 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, Chapter 5, Configuring BFD.

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 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.
    2. 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.
    3. 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

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:

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 7, based on the status of the associated RTR operations.





 Table 7:  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.
    2. host1(config)#interface loopback 0

    host1(config-if)#ip address 10.1.1.1 255.255.255.0

    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.
    3. 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.
    4. 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.
    2. 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
  1. 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
  1. (Optional) Configure optional probe characteristics, such as the frequency and samples-of-history kept. For information, see Configuring Optional Characteristics.
    2. host1(config-rtr)#frequency 1

    host1(config-rtr)#samples-of-history-kept 0
  2. Exit RTR Configuration mode.
    3. host1(config-rtr)#exit
  3. 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
  1. Schedule the probe operation. For information, see Scheduling the Probe.
    2. host1(config)#rtr schedule 10 life 3

    host1(config)#rtr schedule 10 restart-time 1

    host1(config)#rtr schedule 10 start now
  1. Repeat Step 4 to define RTR 11 for Fast Ethernet interface 4/1.
    2. 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
  2. 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
  1. 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

interface loopback

ip address

ip route verify rtr

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

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

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

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, Chapter 4, Configuring SNMP for more information.

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

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

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

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:

tcp path-mtu-discovery max-mtu

tcp path-mtu-discovery min-mtu

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

Shutting Down an IP Interface

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

ip shutdown

Removing the IP Configuration

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

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

ip refresh-route

Clearing IP Interfaces

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

clear ip interface

Setting a Baseline

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

baseline ip interface

Disabling Forwarding of Packets

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

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:

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

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

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.

ip description

Enabling Link Status Traps

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

snmp trap ip link-status

Configuring the Speed

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

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

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

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:

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

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

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

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

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

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, Chapter 2, Configuring MPLS for more information.

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