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 device, 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.

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. Network interface on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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

2.1.2. System interface on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

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 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. System interface on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The system interface is associated with the network entity (such as a specific router or switch), and not a specific interface.

The system interface is associated during the configuration of the following entities:

  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, also referred to as the loopback address, is used to preserve connectivity (when routing re-convergence is possible) when an interface fails or is removed. It is also used as the router identifier. A system interface must have an IP address with a 32- bit subnet mask.

2.1.4. Unicast Reverse Path Forwarding check on 7210 SAS-K 3SFP+ 8C

The Unicast Reverse Path Forwarding Check (Unicast RPF) feature helps mitigate problems caused by the introduction of malformed or forged (spoofed) IP source addresses into a network. The feature works by discarding IP packets that lack a verifiable IP source address. For example, common types of denial-of-service (DoS) attacks, including smurf and tribe flood network (TFN), can use forged or rapidly changing source addresses to thwart efforts to locate or filter the attacks. ISPs that provide public access can use Unicast RPF to deflect such attacks by only forwarding packets with source IP addresses that are valid and consistent with the IP routing table. This protects the network of the ISP, its customer, and the rest of the Internet.

Unicast RPF is supported for both IPv4 and IPv6 on access ports only. It is supported on any IP interface configured in the IES and VPRN services.

Unicast RPF has two modes: strict and loose, but the 7210 SAS-K 3SFP+ 8C supports only strict mode in this release.

In strict mode, Unicast RPF checks whether there is a matching prefix entry for the source address of the incoming packet in the routing table, and whether the interface expects to receive a packet with this source address prefix. If urpf-check is enabled on the interface, all interfaces are assumed to be enabled for strict mode Unicast RPF check.

In the case of ECMP, the 7210 SAS-K 3SFP+ 8C allows a packet received on an IP interface configured in strict mode Unicast RPF to be forwarded, if the IP interface on which the packet is received matches any one of the interfaces used by that ECMP route.

If there is a default route, the following is included in the Unicast RPF check:

  1. If there is a default route, a strict mode Unicast RPF check only succeeds if the source address matches any route (including the default route) where the next-hop is on the incoming interface for the packet. A per node option exists to ignore the default route for a strict mode Unicast RPF check.
  2. If a match is not found, the Unicast RPF check fails.

If the source IP address matches a discard/blackhole route, the packet is treated as if it failed the Unicast RPF check.

2.1.5. Unnumbered interfaces

Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow (or link to) an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface) and use it as the source IP address for packets originating from the interface.

The benefits of using unnumbered interfaces are the following:

  1. ISP backhaul can be enabled with a single IP address allocated to the CE nodes (the network interface address is coupled with the system IP address).
  2. Nodes can be added to or deleted from a network without address changes; unnumbered interfaces are linked to a centralized IP address and therefore do not require any address change if the nodes are relocated. After a topology change, the ARP table is updated to ensure reachability, and the upper layer protocols re-establish the peering sessions.

Unnumbered interfaces are supported on:

  1. network interfaces
  2. IES interfaces
  3. VPRN interfaces

Only IPv4 addresses are supported.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, unnumbered interfaces are supported for the IS-IS and OSPF routing protocols and for MPLS routing (RSVP-TE and LDP). This feature is supported through both dynamic and static ARP. Any Ethernet port with null, dot1q, or QinQ encapsulation supports IP unnumbered interfaces.

Refer to the 7210 SAS-K 2F6C4T, K 3SFP+ 8C Routing Protocols Guide for more information about IS-IS and OSPF unnumbered interface support. Refer to “Unnumbered Point-to-Point Interface in RSVP” and “Unnumbered Interface Support in LDP” in the 7210 SAS-K 2F6C4T, K 3SFP+ 8C MPLS Guide for more information about MPLS unnumbered interface support.

Note:

Unnumbered interfaces do not support PIM routing or IGMP listener capabilities.

2.1.6. Router ID

Note:

This feature is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

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.7. Autonomous systems (AS)

Note:

  1. AS is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.
  2. 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 AS that have been administratively assigned to the same group. An area’s 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.8. Proxy ARP

Note:

This feature is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

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 Nokia 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.9. Internet Protocol versions

Note:

IPv4 and IPv6 support on the different platforms is as follows:

  1. IPv6 is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-K 2F1C2T.
  2. The 7210 SAS-D and 7210 SAS-Dxp platforms only support the use of IPv6 for management purposes. IPv6 cannot be used to deliver a service.
  3. The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms can be used as dual-stack IPv6 and IPv4 routers capable of IPv6 forwarding and the provision of IPv6 services, including IPv6 VPN (6VPE) services. IPv6 support can also be used for management of the node (in-band management is available).

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 anycast address is defined that is used to send a packet to any one of a group of nodes.
    Note:

    The 7210 SAS-Dxp supports a maximum 64-bit prefix length for IPv6 addresses. This restriction applies when configuring static routes; for example, a static route can be configured with a /64 prefix using the configure router static-route 2001::0/64 next-hop 4001::5 command.

  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.9.1. IPv6 applications for 7210 SAS-D and 7210 SAS-Dxp

The IPv6 applications for 7210 SAS-D and 7210 SAS-Dxp are:

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

2.1.9.2. IPv6 applications for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The IPv6 applications for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C are:

  1. IPv6 services
  2. IPv6 dual-stack router with capability to route/forward IPv6 packets
  3. IPv6 inband management of the node

2.1.9.3. 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 with one AS.

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

2.1.9.3.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.9.3.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.9.4. DNS

The DNS client is extended to use IPv6 as transport and to handle the IPv6 address in the DNS AAAA resource record from an IPv4 or IPv6 DNS server. An assigned name can be used instead of an IPv6 address as IPv6 addresses are more difficult to remember than IPv4 addresses.

2.1.10. Bidirectional forwarding detection for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 and 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.10.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 networks is specified in draft-ietf-bfd-v4v6-1hop-04.txt, BFD for IPv4 (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.10.2. Control packet format

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

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’s 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

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.10.3. BFD 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’s 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.10.4. BFD support on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms

BFD support on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms is as follows:

BFD in a VPRN service can be used for:

  1. OSPFv2 PE-CE routing protocol
  2. Static routes (IPv4)
  3. BGP for PE-CE protocol (IPv4)

BFD in IES service can be used for:

  1. OSPFv2
  2. IS-IS for IPv4 interfaces
  3. Static routes (IPv4)

BFD in Base routing instance can be used for:

  1. OSPFv2 on network IPv4 interfaces
  2. IS-IS on network IPv4 interfaces
  3. MP-BGP for vpn-ipv4 families (only multi-hop)
  4. Static routes (IPv4)
  5. RSVP-TE
  6. TLDP (IPv4)
  7. Interface LDP (link-level) (IPv4)
Note:

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, BFD processing is supported in hardware enabling faster detection (minimum timer supported is 10ms).

2.1.11. DHCP

Note:

DHCP server support on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C is designed to be used for IP address assignment used for local management access to the node or to the devices connected to the node for maintenance activities.

DHCP is a configuration protocol used to communicate network information and configuration parameters from a DHCP server to a DHCP-aware client. DHCP is based on the BOOTP protocol, with additional configuration options and the added capability of allocating dynamic network addresses. DHCP-capable devices are also capable of handling BOOTP messages.

A DHCP client is an IP-capable device (typically a computer or base station) that uses DHCP to obtain configuration parameters such as a network address. A DHCP server is an Internet host or router that returns configuration parameters to DHCP clients. A DHCP/BOOTP Relay agent is a host or router that passes DHCP messages between clients and servers.

Home computers in a residential high-speed Internet application typically use the DHCP protocol to have their IP address assigned by their Internet service provider.

The following is supported on different 7210 SAS platforms:

  1. The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms can act as a DHCP Relay agent, or a local DHCP server.
  2. The 7210 SAS-K 2F1C2T platform can act as a DHCP relay agent only.
  3. The 7210 SAS-D and 7210 SAS-Dxp platforms can act as a DHCP relay agent only.

The following paragraphs describe the functionality available on 7210 SAS as DHCP server, and as a relay agent.

For DHCP, the DHCP protocol requires the client to transmit a request packet with a destination broadcast address of 255.255.255.255 that is processed by the DHCP server. Since IP routers do not forward broadcast packets, this would suggest that the DHCP client and server must reside on the same network segment. However, for various reasons, it is sometimes impractical to have the server and client reside in the same IP network. When the 7210 is acting as a DHCP Relay agent, it processes these DHCP broadcast packets and relays them to a preconfigured DHCP server. Therefore, DHCP clients and servers do not need to reside on the same network segment.

When the 7210 SAS is acting as a local DHCP server, it processes these DHCP broadcast packets and allocates IP addresses for the DHCP client as needed.

2.1.11.1. DHCP principles

Note:

The references to spoke-SDP and mesh-SDP in this section are only applicable to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

In a Triple Play network, client devices (such as a routed home gateway, a session initiation protocol (SIP) phone or a set-top box) use DHCP to dynamically obtain their IP address and other network configuration information. The 7210 SAS auto-init procedure also uses DHCP to dynamically obtain the BOF used for first-time booting of the system (along with IP address required to retrieve the BOF, the configuration file and the TiMOS software image from the network). DHCP is defined and shaped by several RFCs and drafts in the IETF DHC working group including the following:

  1. RFC 2131, Dynamic Host Configuration Protocol
  2. RFC 3046, DHCP Relay Agent Information Option

The DHCP operation is shown in the following figure.

Figure 3:  IP address assignment with DHCP 
  1. During boot-up, the client device sends a DHCP discover message to get an IP address from the DHCP Server. The message contains the following:
    1. destination MAC address - broadcast
    2. source MAC address - MAC of client device
    3. client hardware address - MAC of client device
    If this message passes through a DSLAM or other access node (possibly a 7210 SAS device), typically the Relay information option (Option 82) field is added, indicating shelf, slot, port, VPI, VCI and other fields, to identify the subscriber.
    DHCP relay is enabled on the first IP interface in the upstream direction. Depending on the scenario, the DSLAM, 7210 SAS access node, or the BSR will relay the discover message as a unicast packet toward the configured DHCP server. DHCP relay is configured to insert the giaddr to indicate to the DHCP server in which subnet an address should be allocated.
  2. The DHCP server will lookup the client MAC address and Option 82 information in its database. If the client is recognized and authorized to access the network, an IP address will be assigned and a DHCP offer message returned. The BSA or BSR will relay this back to the client device.
  3. It is possible that the discover reached more than one DHCP server, and therefore that more than one offer was returned. The client selects one of the offered IP addresses and confirms it needs to use this in a DHCP request message, sent as unicast to the DHCP server that offered it.
  4. The DHCP server confirms that the IP address is still available, updates its database to indicate it is now in use, and replies with a DHCP ACK message back to the client. The ACK also contains the Lease Time of the IP address.

2.1.12. DHCP relay

The 7210 SAS provides DHCP/BOOTP Relay agent services for DHCP clients. DHCP is used for IPv4 network addresses. DHCP is known as stateful protocols because they use dedicated servers to maintain parameter information. In the stateful auto-configuration model, hosts obtain interface addresses and/or configuration information and parameters from a server. The server maintains a database that keeps track of which addresses have been assigned to which hosts.

DHCP relay on different 7210 SAS platforms is as follows:

  1. 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T support DHCP Relay on the base router, and on access IP interfaces associated with IES service used for management.
  2. 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support DHCP Relay on the base router, and on access IP interfaces associated with IES service and VPRN service.

2.1.13. DHCP relay agent options

DHCP options are codes that the router inserts in packets being forwarded from a DHCP client to a DHCP server. Some options have additional information stored in sub-options.

The 7210 SAS supports Option 60 and Option 61 as specified in RFC 2132. Option 60 is the vendor class identifier, which can contain information such as the client's hardware configuration. Option 61 is the client identifier.

The 7210 SAS supports the Relay Agent Information Option 82 as specified in RFC3046. The following sub-options are supported for the base router:

  1. action
  2. circuit ID
  3. copy-82
  4. remote ID

2.1.13.1. Option 82

Option 82, or the relay information option is specified in RFC 3046, DHCP Relay Agent Information Option, allows the router to append some information to the DHCP request that identifies where the original DHCP request arrives from.

There are two sub-options under Option 82:

  1. Agent Circuit ID Sub-option (RFC 3046, section 3.1): This sub-option specifies data which must be unique to the box that is relaying the circuit.
  2. Remote ID Sub-option (RFC 3046 section 3.2): This sub-option identifies the host at the other end of the circuit. This value must be globally unique.

Both sub-options are supported by the 7210 SAS and can be used separately or together.

Inserting Option 82 information is supported independently of DHCP relay.

When the circuit id sub-option field is inserted by the 7210 SAS, it can take following values:

  1. sap-id - the SAP index (only under an IES service)
  2. ifindex - the index of the IP interface (only under an IES service)
  3. ascii-tuple - an ASCII-encoded concatenated tuple, consisting of [system-name|serviceid| interface-name] (for IES) or [system-name|service-id|sap-id] (for VPLS).
  4. vlan-ascii-tuple - an ASCII-encoded concatenated tuple, consisting of the ascii-tuple followed by Dot1p bits and Dot1q tags

When a DHCP packet is received with Option 82 information already present, the system can do one of three things. The available actions are:

  1. Replace
    On ingress the existing information-option is replaced with the information-option parameter configured on the 7210 SAS. On egress (toward the customer) the information-option is stripped (per the RFC).
  2. Drop
    The DHCP packet is dropped and a counter is incremented.
  3. Keep
    The existing information is kept on the packet and the router does not add any additional information. On egress the information option is not stripped and is sent on to the downstream node.

In accordance with the RFC, the default behavior is to keep the existing information; except if the giaddr of the packet received is identical to a local IP address on the router, then the packet is dropped and an error incremented regardless of the configured action.

The maximum packet size for a DHCP relay packet is 1500 bytes. If adding the Option 82 information would cause the packet to exceed this size, the DHCP relay request will be forwarded without the Option 82 information. This packet size limitation exists to ensure that there will be no fragmentation on the end Ethernet segment where the DHCP server attaches.

In the downstream direction, the inserted Option 82 information should not be passed back toward the client (as per RFC 3046, DHCP Relay Agent Information Option). To enable downstream stripping of the option 82 field, DHCP snooping should be enabled on the SDP or SAP connected to the DHCP server.

2.1.13.2. Local DHCP server on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C supports local DHCP server functionality on the base router and on access IP interfaces associated with VPRN, by dynamically assigning IPv4 addresses to access devices that request them. This standards-based, full DHCP server implementation allows a service provider the option. The 7210 SAS can support public and private addressing in the same router, including overlapped private addressing in the form of VPRNs in the same router. The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C acts as a DHCP server.

An administrator creates pools of addresses that are available for assigned hosts. Locally attached hosts can obtain an address directly from the server. Routed hosts receive addresses through a relay point in the customer's network. When a DHCP server receives a DHCP message from a DHCP Relay agent, the server looks for a subnet to use for assigning an IP address. If configured with the use-pool-from-client command, the server searches Option 82 information for a pool name. If a pool name is found, an available address from any subnet of the pool is offered to the client. If configured with the use-gi-address command, the server uses the gateway IP address (GIADDR) supplied by the Relay agent to find a matching subnet. If a subnet is found, an address from the subnet is offered to the client. If no pool or subnet is found, then no IP address is offered to the client.

IPv4 address assignments are temporary and expire when the configured lease time is up. The server can reassign addresses after the lease expires.

If both the no use-pool-from-client command and the no use-gi-address command or no use-link-address command are specified, the server does not act.

2.1.13.3. DHCP server options

Options and identification strings can be configured on several levels.

DHCP servers support the following options, as defined in RFC 2132:

  1. Option 1 - Subnet Mask
  2. Option 3 - Default Routers
  3. Option 6 - DNS Name Servers
  4. Option 12 - Host Name
  5. Option 15 - Domain Name
  6. Option 44 - Netbios Name Server
  7. Option 46 - Netbios Node Type Option
  8. Option 50 - IP Address
  9. Option 51 - IP Address Lease Time
  10. Option 53 - DHCP Message Type
  11. Option 54 - DHCP Server IP Address
  12. Option 55 - Parameter Request List
  13. Option 58 - Renew (T1) Timer
  14. Option 59 - Renew (T2) Timer
  15. Option 60 - Class Identifier
  16. Option 61 - Client Identifier

DHCP servers also support Sub-option 13 Relay Agent Information Option 82 as specified in RFC 3046, to enable the use of a pool indicated by the DHCP client.

These options are copied into the DHCP reply message, but if the same option is defined several times, the following order of priority is used:

  1. subnet option
  2. pool options
  3. options from the DHCP client request

A local DHCP server must be bound to a specified interface by referencing the server from that interface. The DHCP server will then be addressable by the IP address of that interface. A normal interface or a loop-back interface can be used.

A DHCP client is defined by the MAC address and the circuit identifier. This implies that for a certain combination of MAC and circuit identifier, only one IP address can be returned; if more than one request is made, the same address will be returned.

2.1.13.4. Trusted and untrusted

There is a case where the relay agent could receive a request where the downstream node added Option 82 information without also adding a giaddr (giaddr of 0). In this case the default behavior is for the router to drop the DHCP request. This behavior is in line with the RFC.

The 7210 SAS supports a command trusted, which allows the router to forward the DHCP request even if it receives one with a giaddr of 0 and Option 82 information attached. This could occur with older access equipment. In this case the relay agent would modify the request's giaddr to be equal to the ingress interface. This only makes sense when the action in the information option is keep, and the service is IES. In the case where the Option 82 information gets replaced by the relay agent, either through explicit configuration or the VPLS DHCP Relay case, the original Option 82 information is lost, and the reason for enabling the trusted option is lost.

2.1.13.5. DHCP snooping

To support DHCP based address assignment in L2 aggregation network, 7210 supports DHCP snooping. 7210 can copy packets designated to the standard UDP port for DHCP (port 67) to its control plane for inspection, this process is called DHCP snooping.

DHCP snooping can be performed in two directions:

  1. From the client to the DHCP server (Discover or Request messages) to insert Option 82 information; For these applications, DHCP snooping must be enabled on the SAP toward the subscriber.
  2. From the DHCP server (ACK messages), to remove the Option 82 field toward the client. For these applications, DHCP snooping must be enabled on both the SAP toward the network and the SAP toward the subscriber.

2.1.14. IGP-LDP and static route-LDP synchronization on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 re-advertised. IGP will announce a new best next-hop and LDP will use it if the label binding for the neighbor’s 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.

2.2. Process overview on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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’s 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 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. Process overview of 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

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 (if supported by the platform).

2.4. 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. On 7210 SAS-D and 7210 SAS-Dxp 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 CLI command config>system>resource-profile>max-ipv6-routes. 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. Please see the following example and the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information.
  4. On 7210 SAS-D, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, a separate route table (or a block in the route table) is used for IPv6 /128-bit prefix route lookup. A limited amount of IPv6 /128 prefixes route lookup entries is supported. The software enables lookups in this table by default (that is, no user configuration is required to enable IPv6 /128-bit route lookup).
  5. On 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, IPv6 interfaces are allowed to be created without allocating IPv6 route entries. With this only IPv6 hosts on the same subnet will be reachable.

2.4.1. Configuration guidelines for DHCP relay and snooping

The following configuration guidelines must be followed to configure DHCP relay and snooping:

  1. 7210 SAS devices do not support the ARP populate based on the DHCP lease, assigned to the DHCP client
  2. 7210 SAS devices do not maintain the DHCP lease assigned to the client
  3. 7210 SAS devices do not perform IP spoofing checks and MAC spoofing checks based on the DHCP parameters assigned to the client
  4. MAC learning must be enabled in the VPLS service, for DHCP snooping.
  5. DHCP snooping is not supported for B-SAPs in B-VPLS services and I-SAPs in I-VPLS services.
  6. Ingress ACLs cannot be used to drop DHCP control packet.
  7. On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, DHCP packets received over an SDP are identified and option-82 inserted by the node can be removed by the node, in the downstream direction. SAP or a SDP, as applicable. DHCP snooping configuration on an SDP is supported only on the7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.