2. IP router configuration

This chapter provides information about commands required to configure basic router parameters.

2.1. Configuring IP router parameters

To provision services on a 7210 SAS router, logical IP routing interfaces must be configured to associate attributes, such as an IP address or the system with the IP interface.

A special type of IP interface is the system interface. A system interface must have an IP address with a 32-bit subnet mask. The system interface is used as the router identifier by higher-level protocols such as OSPF and BGP, unless overwritten by an explicit router ID.

2.1.1. Interfaces

7210 SAS routers use different types of interfaces for various functions. Interfaces must be configured with parameters, such as the interface type (system) and address. A port is not associated with a system interface. An interface can be associated with the system (loopback address).

2.1.1.1. Secondary IPv4 addresses

Secondary IPv4 addresses can be assigned to an IP interface to allow multiple IP subnets to be assigned to a single Ethernet LAN segment. This is useful in IPv4 address migration and the use of a single VLAN for multiple IP subnets in some network designs.

On the 7210 SAS, IPv4 secondary addresses are supported for the following IP interface types:

  1. IES IP interface
  2. VPRN IP interface
  3. Routed VPLS IP interface
  4. Network IP interface

The following optional functionality is supported with IPv4 secondary addresses:

  1. Use IPv4 secondary addresses with static routes.
  2. Advertise IPv4 secondary addresses through routing protocols such as OSPF or IS-IS.
  3. Use IPv4 secondary addresses with VRRP (IPv4).

The following restrictions apply to the use of IPv4 secondary addresses:

  1. An IP interface must be assigned a primary IP address before a secondary IP address can be used.
  2. Secondary IP addresses cannot be used for setting up OSPF or IS-IS neighbors.
  3. Secondary IP addresses cannot be used with MPLS protocols and PWs (such as RSVP, LDP, or BGP 3107) for specifying parameters such as path information. That is, MPLS protocols and PWs always use primary IPv4 addresses.

2.1.1.2. Network interface

A network interface (a logical IP routing interface) can be configured on a physical port.

2.1.2. System interface

The system interface is associated with the network entity (such as, a specific router or switch), not a specific interface. The system interface is also referred to as the loop-back address. The system interface is associated during the configuration of the following entities as follows:

  1. the termination point of service tunnels
  2. the hops when configuring MPLS paths and LSPs
  3. the addresses on a target router for BGP and LDP peering

The system interface is used to preserve connectivity (when routing re-convergence is possible) when an interface fails or is removed. The system interface is also referred to as the loop-back address and is used as the router identifier. A system interface must have an IP address with a 32-bit subnet mask.

2.1.3. Router ID

The router ID, a 32-bit number, uniquely identifies the router within an autonomous system (AS). In protocols such as OSPF, routing information is exchanged between areas, groups of networks that share routing information. It can be set to be the same as the loop-back address. The router ID is used by both OSPF and BGP routing protocols in the routing table manager instance.

There are several ways to obtain the router ID. On each 7210 SAS router, the router ID can be derived in the following ways:

  1. Define the value in the config>router router-id context. The value becomes the router ID.
  2. Configure the system interface with an IP address in the config>router>interface ip-int-name context. If the router ID is not manually configured in the config>router router-id context, then the system interface acts as the router ID.
  3. If neither the system interface or router ID are implicitly specified, then the router ID is inherited from the last four bytes of the MAC address.
  4. The router can be derived on the protocol level.

2.1.4. Autonomous systems

Note:

BGP protocol (only selected families) is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

Networks can be grouped into areas. An area is a collection of network segments within an autonomous system (AS) that have been administratively assigned to the same group. An area topology is concealed from the rest of the AS, which results in a significant reduction in routing traffic.

Routing in the AS takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing) or different areas (inter-area routing). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information.

Routers that belong to more than one area are called area border routers. All routers in an AS do not have an identical topological database. An area border router has a separate topological database for each area it is connected to. Two routers, which are not area border routers, belonging to the same area, have identical area topological databases.

Autonomous systems share routing information, such as routes to each destination and information about the route or AS path, with other ASs using BGP. Routing tables contain lists of next hops, reachable addresses, and associated path cost metrics to each router. BGP uses the information and path attributes to compile a network topology.

2.1.5. Proxy ARP

Proxy ARP is the technique in which a router answers ARP requests intended for another node. The router appears to be present on the same network as the “real” node that is the target of the ARP and takes responsibility for routing packets to the “real” destination. Proxy ARP can help nodes on a subnet reach remote subnets without configuring routing or a default gateway. Typical routers only support proxy ARP for directly attached networks; the router is targeted to support proxy ARP for all known networks in the routing instance where the virtual interface proxy ARP is configured.

To support DSLAM and other edge like environments, proxy ARP supports policies that allow the provider to configure prefix lists that determine for which target networks proxy ARP will be attempted and prefix lists that determine for which source hosts proxy ARP will be attempted.

In addition, the proxy ARP implementation will support the ability to respond for other hosts within the local subnet domain. This is needed in environments such as DSL where multiple hosts are in the same subnet but can not reach each other directly.

Static ARP is used when a 7210 SAS router needs to know about a device on an interface that cannot or does not respond to ARP requests. Therefore, the configuration can state that if it has a packet with a certain IP address to send it to the corresponding ARP address. Use proxy ARP so the router responds to ARP requests on behalf of another device.

2.1.6. Internet Protocol versions

The TiMOS implements IP routing functionality, providing support for IP version 4 (IPv4) and IP version 6 (IPv6). IP version 6 (RFC 1883, Internet Protocol, Version 6 (IPv6)) is a newer version of the Internet Protocol designed as a successor to IP version 4 (IPv4) (RFC-791, Internet Protocol). The changes from IPv4 to IPv6 effects the following categories:

  1. Expanded addressing capabilities
    IPv6 increases the IP address size from 32 bits (IPv4) to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by adding a scope field to multicast addresses. Also, a new type of address called an any cast address is defined that is used to send a packet to any one of a group of nodes.
  2. Header format simplification
    Some IPv4 header fields have been dropped or made optional to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header.
  3. Improved support for extensions and options
    Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.
  4. Flow labeling capability
    The capability to enable the labeling of packets belonging to particular traffic flows for which the sender requests special handling, such as non-default quality of service or “real-time” service was added in IPv6.
  5. Authentication and privacy capabilities
    Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for IPv6.
    The following figure shows the IPv6 header format.
    Figure 1:  IPv6 header format 
    The following table describes IPv6 header fields.
    Table 5:  IPv6 header field descriptions 

    Field

    Description

    Version

    4-bit Internet Protocol version number = 6.

    Prio.

    4-bit priority value.

    Flow Label

    24-bit flow label.

    Payload Length

    6-bit unsigned integer. The length of payload, for example, the rest of the packet following the IPv6 header, in octets. If the value is zero, the payload length is carried in a jumbo payload hop-by-hop option.

    Next Header

    8-bit selector. Identifies the type of header immediately following the IPv6 header.

    This field uses the same values as the IPv4 protocol field.

    Hop Limit

    8-bit unsigned integer. Decremented by 1 by each node that forwards the packet.

    The packet is discarded if the hop limit is decremented to zero.

    Source Address

    128-bit address of the originator of the packet.

    Destination Address

    128-bit address of the intended recipient of the packet (possibly not the ultimate recipient if a routing header is present).

2.1.6.1. IPv6 applications

The IPv6 applications for 7210 SAS are:

  1. IPv6 inband management of the node using network port IPv6 IP interface
  2. IPv6 transit traffic (using network port IPv6 IP interfaces)

Examples of the IPv6 applications supported by the -TiMOS include:

  1. IPv6 Internet exchange peering
    The following figure shows an IPv6 Internet exchange where multiple ISPs peer over native IPv6.
    Figure 2:  IPv6 Internet exchange 
  2. IPv6 transit services
    The following figure shows IPv6 transit provided by an ISP.
    Figure 3:  IPv6 transit services 
  3. IPv6 services to enterprise customers and home users
    The following figure shows IPv6 connectivity to enterprise and home broadband users.
    Figure 4:  IPv6 services to enterprise customers and home users 
  4. IPv6 over IPv4 relay services
    IPv6 over IPv4 tunnels are one of many IPv6 transition methods to support IPv6 in an environment where not only IPv4 exists but native IPv6 networks depend on IPv4 for greater IPv6 connectivity. The 7210 SAS supports dynamic IPv6 over IPv4 tunneling. The ipv4 source and destination address are taken from configuration, the source address is the ipv4 system address and the ipv4 destination is the next hop from the configured 6over4 tunnel.
    IPv6 over IPv4 is an automatic tunnel method that gives a prefix to the attached IPv6 network. The following figure shows IPv6 over IPv4 tunneling to transition from IPv4 to IPv6.
    Figure 5:  IPv6 over IPv4 tunnels 

2.1.6.2. IPv6 Provider Edge router over MPLS (6PE)

6PE allows IPv6 domains to communicate with each other over an IPv4 MPLS core network. This architecture requires no backbone infrastructure upgrades and no re-configuration of core routers, because forwarding is purely based on MPLS labels. 6PE is a cost effective solution for IPv6 deployment.

The following figure shows an example of a 6PE topology within one AS.

Figure 6:  Example of a 6PE topology within one AS 

2.1.6.2.1. 6PE control plane support

The 6PE MP-BGP routers support:

  1. IPv4/IPv6 dual-stack
  2. MP-BGP can be used between 6PE routers to exchange IPv6 reachability information as follows:
    1. The 6PE routers exchange IPv6 prefixes over MP-BGP sessions running over IPv4 transport. The MP-BGP AFI used is IPv6 (value 2).
    2. An IPv4 address of the 6PE router is encoded as an IPv4-mapped IPv6 address in the BGP next-hop field of the IPv6 NLRI. By default, the IPv4 address that is used for peering is used. It is configurable through the route policies.
    3. The 6PE router binds MPLS labels to the IPv6 prefixes it advertises. The SAFI used in MP-BGP is the SAFI (value 4) label. The router uses the IPv6 explicit null (value 2) label for all the IPv6 prefixes that it advertises and can accept an arbitrary label from its peers.
  3. LDP is used to create the MPLS full mesh between the 6PE routers and the IPv4 addresses that are embedded in the next-hop field are reachable by LDP LSPs. The ingress 6PE router uses the LDP LSPs to reach remote 6PE routers.

2.1.6.2.2. 6PE data plane support

The ingress 6PE router can push two MPLS labels to send the packets to the egress 6PE router. The top label is an LDP label used to reach the egress 6PE router. The bottom label is advertised in MP-BGP by the remote 6PE router. Typically, the IPv6 explicit null (value 2) label is used but an arbitrary value can be used when the remote 6PE router is from a vendor other than Nokia.

The egress 6PE router pops the top LDP tunnel label. It sees the IPv6 explicit null label, which indicates an IPv6 packet is encapsulated. It also pops the IPv6 explicit null label and performs an IPv6 route lookup to find out the next hop for the IPv6 packet.

2.1.7. Bidirectional Forwarding Detection

Note:

This feature is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

Bidirectional Forwarding Detection (BFD) is a light-weight, low-overhead, short-duration mechanism to detect failures in the path between two systems. If a system stops receiving BFD messages for a long enough period (based on configuration) it is assumed that a failure along the path has occurred and the associated protocol or service is notified of the failure.

The following are the advantages of implementing the BFD mechanism:

  1. used for activity detection over any media type
  2. can be used at any protocol layer
  3. proliferation of different methods can be avoided
  4. can be used with a wide range of detection times and overhead

BFD is implemented in asynchronous mode, in this mode periodic BFD control messages are used to test the path between the systems.

A path is declared operational when two-way communication has been established between both the systems. A separate BFD session is created for each communication path and data protocol between two systems.

BFD also supports the Echo function defined in draft-ietfbfd-base-04.txt, Bidirectional Forwarding Detection. In this scenario one of the systems send a sequence of BFD echo packets to the other system which loops back the echo packets within the systems forwarding plane. If many of the echo packets are lost, the BFD session is declared as down.

2.1.7.1. BFD control packet

The base BFD specification does not specify the encapsulation type to be used for sending BFD control packets. Choice of the appropriate encapsulation-type to be implemented is based on the network and medium. The encapsulation for BFD over IPv4 and IPv6 networks is specified in draft-ietf-bfd-v4v6-1hop-04.txt, BFD for IPv4 and IPv6 (Single Hop). This specification requires that BFD control packets be sent over UDP with a destination port number of 3784 and the source port number must be within the range 49152 to 65535.

Note:

  1. The TTL of all transmitted BFD packets must have an IP TTL of 255
  2. If authentication is not enabled, all BFD packets received must have an IP TTL of 255.
  3. If authentication is enabled, the IP TTL should be 255. In case the IP TTL is not 255 the BFD packets are still processed, if packet passes the enabled authentication mechanism.
  4. If multiple BFD sessions exist between two nodes, the BFD discriminator is used to demultiplex the BFD control packet to the appropriate BFD session.

2.1.7.2. Control packet format

The BFD control packet has 2 sections, a mandatory section and an optional authentication section. The mandatory section is as follows.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Vers |  Diag   |Sta|P|F|C|A|D|R|  Detect Mult  |    Length     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       My Discriminator                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Your Discriminator                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Desired Min TX Interval                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Required Min RX Interval                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Required Min Echo RX Interval                 |

The following table describes BFD control packet fields.

Table 6:  BFD control packet field descriptions  

Field

Description

Vers

The version number of the protocol. The initial protocol version is 0.

Diag

A diagnostic code specifying the local system reason for the last transition of the session from Up to some other state.

Possible values are:

0-No diagnostic

1-Control detection time expired

2-Echo function failed

3-Neighbor signaled session down

4-Forwarding plane reset

5-Path down

6-Concatenated path down

7-Administratively down

H Bit

The “I Hear You” bit. This bit is set to 0 if the transmitting system either is not receiving BFD packets from the remote system, or is in the process of tearing down the BFD session for some reason. Otherwise, during normal operation, it is set to 1.

D Bit

The “demand mode” bit. (Not supported)

P Bit

The poll bit. If set, the transmitting system is requesting verification of connectivity, or of a parameter change.

F Bit

The final bit. If set, the transmitting system is responding to a received BFD control packet that had the poll (P) bit set.

Rsvd

Reserved bits. These bits must be zero on transmit and ignored on receipt.

Detect Mult

The “Detect time multiplier”. In the Asynchronous mode, Detection time = Detect time Multiplier * transmit interval. If a BFD control packet is not received from the remote system within the detection time, implies that a failure has occurred.

Length

Length of the BFD control packet, in bytes.

My Discriminator

A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems.

Your Discriminator

The discriminator received from the corresponding remote system. This field reflects back the received value of my discriminator, or is zero if that value is unknown.

Desired Min TX Interval

This is the minimum interval, in microseconds, that the local system would like to use when transmitting BFD control packets.

Required Min RX Interval

This is the minimum interval, in microseconds, between received BFD control packets that this system is capable of supporting.

Required Min Echo RX Interval

This is the minimum interval, in microseconds, between received BFD echo packets that this system is capable of supporting. If this value is zero, the transmitting system does not support the receipt of BFD echo packets.

2.1.7.3. Echo support

In the BFD echo support scenario, the 7210 SAS loops back received BFD echo messages to the original sender based on the destination IP address in the packet.

The echo function is useful when the local router does not have sufficient CPU power to handle a periodic polling rate at a high frequency. As a result, it relies on the echo sender to send a high rate of BFD echo messages through the receiver node, which is only processed by the receiver forwarding path. This allows the echo sender to send BFD echo packets at any rate.

The 7210 SAS supports only response to echo requests and does not support sending of echo requests.

2.1.7.4. BFD IPv4 support on 7210 SAS platforms

BFD IPv4 support on 7210 SAS platforms is as follows.

BFD IPv4 in a VPRN service is supported for:

  1. OSPV2 PE-CE routing protocol
  2. static routes
  3. VRRP
  4. BGP for PE-CE protocol
  5. PIM for PE-CE protocol for ng-MVPN

BFD IPv4 in an IES service is supported for:

  1. OSPFv2
  2. IS-IS for IPv4 interfaces
  3. static routes
  4. VRRP

BFD IPv4 in the base routing instance is supported for:

  1. OSPFv2 on network IPv4 interfaces
  2. IS-IS on network IPv4 interfaces
  3. VRRP on network IPv4 interfaces
  4. MP-BGP for vpn-ipv4 and vpn-ipv6 family (only multi-hop)
  5. static routes
  6. RSVP-TE
  7. PIM
  8. TLDP
  9. interface LDP (link-level)

BFD IPv4 for MPLS-TP is supported for:

  1. BFD for MPLS-TP LSP linear protection, only on 7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Note:

  1. See BFD IPv6 support on 7210 SAS platforms for more information about BFD IPv6 support on 7210 SAS platforms.
  2. On the 7210 SAS-T, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx 1/10GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp, BFD processing is supported in hardware, enabling faster detection (minimum timer supported is 10 ms). Hardware-based BFD sessions are supported only for an IP interface configured on a port. For IP interfaces configured over LAG and for BFD sessions using system IP addresses or loop-back IP addresses, CPM CPU-based sessions are supported with a minimum timer of 100ms.

2.1.7.5. BFD IPv6 support on 7210 SAS platforms

Note:

  1. BFD for IPv6 interfaces is supported only the 7210 SAS-Mxp.
  2. On the 7210 SAS-Mxp, BFD IPv6 processing is supported in hardware, enabling faster detection (the minimum timer supported is 10 ms). Hardware-based BFD sessions are supported only for an IP interface configured on a port.
  3. For IP interfaces using the IPv6 addresses of interfaces configured over LAG and for BFD sessions using system IPv6 addresses or loopback IPv6 addresses, CPM CPU-based sessions are supported with a minimum timer of 100 ms.

BFD IPv6 is supported on the 7210 SAS-Mxp in VPRN, IES, and R-VPLS services and network IPv6 interfaces. The following table indicates the support matrix for BFD IPv6 on the 7210 SAS-Mxp.

Table 7:  BFD IPv6 support matrix  

Service

Routing protocol

Hardware or central CPU-based BFD IPv6 session

IP address used by BFD IPv6 session

Hardware

Central

Link local

Global IPv6 address

Network Interface

OSPF

✓

✓

✓

IS-IS

✓

✓

✓

BGP

✓

✓

✓

Static Route

✓

✓

✓

VRRP

✓

✓

✓

IES

OSPF

✓

✓

✓

IS-IS

✓

✓

✓

BGP

✓

✓

✓

Static Route

✓

✓

✓

VRRP

✓

✓

✓

R-VPLS

OSPF

✓

✓

IS-IS

✓

✓

BGP

✓

✓

Static Route

✓

✓

VRRP

✓

✓

VPRN

OSPF

IS-IS

BGP

✓

✓

✓

Static Route

✓

✓

✓

VRRP

✓

✓

✓

2.1.8. IGP-LDP and static route-LDP synchronization

With LDP, FECs learned from an interface do not necessarily link to that interface state. As long as the router that advertised the labels is reachable, the learned labels are stored in the incoming label map (ILM) table.

Although this feature gives LDP a lot of flexibility, it can also cause problems. For example,  when an interface comes back up from a failure or from a shutdown state, the static routes bound to that interface are installed immediately. However, the LDP adjacency to the next hop might not be up, which means that the LDP SDP remains down. In this case, the MPLS traffic will be blackholed until the LDP adjacency comes up.

The same issue also applies to dynamic routes (OSPF and IS-IS).

To resolve this issue, the LDP synchronization timer enables synchronization of IGP or static routes to the LDP state.

With IGP, when a link is restored after a failure, IGP sets the link cost to infinity and advertises it. The value advertised in OSPF is 0xFFFF (65535). The value advertised in IS-IS regular metric is 0x3F (63) and in IS-IS wide-metric is 0xFFFFFE (16777214).

After IGP advertises the link cost, the LDP hello adjacency is brought up with the neighbor. The LDP synchronization timer is started by IGP from the time the LDP session to the neighbor is up over the interface. This synchronization timer allows time for the label-FEC bindings to be exchanged.

When the LDP synchronization timer expires, the link cost is restored and is readvertised. IGP will announce a new best next-hop and LDP will use it if the label binding for the neighbor FEC is available.

The preceding behavior is similar for static routes. If the static route is enabled for ldp-sync, the route is not enabled immediately after the interface to the next hop comes up. Routes are suppressed until the LDP adjacency with the neighbor comes up and the synchronization timer expires. The timer does not start until the LDP adjacency with the neighbor node is fully established.

Note:

  1. IGP-LDP synchronization is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.
  2. Static route-LDP synchronization is supported on all 7210 SAS platforms as described in this document, except platforms operating in access-uplink mode.

2.1.9. IP fragmentation

Note:

This feature is supported only on the 7210 SAS-Mxp.

The 7210 SAS does not support native IP fragmentation for IP packets that exceed the configured MTU. However, in situations where IP fragmentation is necessary, the CPM can be configured to extract oversized IPv4 packets from the datapath, fragment them using the system CPU, and insert the fragmented packets back into the datapath.

Run the configure system ip allow-cpu-fragmentation command to enable IP fragmentation. Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about this command.

Caution:

  1. CPU-fragmented packets are subject to additional delay when compared to non-fragmented datapath forwarded packets.
  2. IP fragmentation in the CPM CPU competes for CPU cycles as a low-priority task. The number of fragmentations at any given time is limited to ensure system performance.

Even when IP fragmentation is enabled, packets that exceed the configured MTU are dropped if the Do not Fragment (DF) bit is set in the IP header.

IP fragmentation on the 7210 SAS is supported in the following contexts:

  1. network IP interface
  2. IES including R-VPLS
Note:

On R-VPLS interfaces, the decision to fragment a packet is based on the egress port MTU and the fragment size is determined by the service MTU.

2.2. Process overview

The following items are components to configure basic router parameters:

  1. interface
    A logical IP routing interface. When created, attributes like an IP address, port, link aggregation group or the system can be associated with the IP interface.
  2. address
    The address associates the device system name with the IP system address. An IP address must be assigned to each IP interface.
  3. system interface
    This creates an association between the logical IP interface and the system (loop-back) address. The system interface address is the circuit-less address (loop-back) and is used by default as the router ID for protocols such as OSPF and BGP.
  4. router ID
    (Optional) The router ID specifies the router's IP address.
  5. autonomous system
    (Optional) An autonomous system (AS) is a collection of networks that are subdivided into smaller, more manageable areas.

2.3. Configuration notes

The following information describes router configuration guidelines:

  1. A system interface and associated IP address should be specified.
  2. Boot options file (BOF) parameters must be configured before configuring router parameters.
  3. IPv4 and IPv6 route table lookup entries are shared. Before adding routes for IPv6 destinations, route entries in the routed lookup table needs to be allocated for IPv6 addresses. This can be done using the config system resource-profile max-ipv6-routes CLI command. This command allocates route entries for /64 IPv6 prefix route lookups. The system does not allocate any IPv6 route entries by default and user needs to allocate some resources before using IPv6. For the command to take effect the node must be rebooted after making the change. Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information.
  4. A separate route table (or a block in the route table) must be used for IPv6 /128-bit prefix route lookup. A limited number of IPv6 /128 prefixes route lookup entries are supported. The software enables lookups in this table by default, so no user configuration is required to enable IPv6 /128-bit route lookup.
  5. IPv6 interfaces are allowed to be created without allocating IPv6 route entries; only IPv6 hosts on the same subnet are reachable.
  6. In 7210 SAS, the FIB is shared among all routing instances (Base instance, management instance, and VPRN service instances).
  7. Software shuts down control protocols (for example, OSPF) if the routing FIB (either IPv4 FIB or IPv6 FIB) size limit is exceeded. Users must ensure through proper network design that the FIB size is not exceeded. Use the available tools (that is, route policies) to ensure that all the features that share the IPv4/IPv6 FIB do not install routes more than the available FIB size.