IP router configuration

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

The router ID, a 32-bit number, uniquely identifies the router within an autonomous system (AS) (see Autonomous systems). 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 loopback 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 router, the router ID can be obtained in the following ways.

• Define the router ID. Use the following command to define the value that becomes the router ID.

  configure router

• Configure the system interface with an IP address. If the router ID is not manually configured in the configure router context, the system interface acts as the router ID. Use the following command to configure the system interface with an IP address.

  configure router interface

• If neither the system interface nor router ID are implicitly specified, the router ID is inherited from the last four bytes of the MAC address.

• The router can be obtained from the protocol level; for example, BGP.

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. The topology of an area 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.

ASs 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.

Configuring confederations is optional and should be implemented only to reduce the iBGP mesh inside an AS. An AS can be logically divided into smaller groupings called sub-confederations and then assigned a confederation ID (similar to an autonomous system number (ASN)). Each sub-confederation has fully meshed iBGP and connections to other ASs outside of the confederation.

The sub-confederations have eBGP-type peers to other sub-confederations within the confederation. They exchange routing information as if they were using iBGP. Command options such as next hop, metric, and local preference are preserved. The confederation appears and behaves like a single AS.

Confederations have the following characteristics:

• A large AS can be sub-divided into sub-confederations.

• Routing within each sub-confederation is accomplished via iBGP.

• eBGP is used to communicate between sub-confederations.

• BGP speakers within a sub-confederation must be fully meshed.

• Each sub-confederation (member) of the confederation has a different ASN. The ASNs used are typically in the private AS range of 64512 to 65535.

To migrate from a non-confederation configuration to a confederation configuration requires a major topology change and configuration modifications on each participating router. Setting BGP policies to select an optimal path through a confederation requires other BGP modifications.

There are no default confederations. Router confederations must be explicitly created. The following figure shows an example of a confederation configuration.

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 the target networks and source hosts for which proxy ARP is attempted.

In addition, the proxy ARP implementation supports 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 cannot 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. The configuration can state that if it has a packet with a specific 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.

Use the following command to provide an IP VPN command option that allows the best BGP route learned by a VPRN to be exported as a VPN-IP route even when that BGP route is inactive because of the presence of a more preferred BGP-VPN route from another PE.

configure service vprn export-inactive-bgp

This ‟best-external” type of route advertisement is useful in active or standby multihoming scenarios because it can ensure that all PEs have knowledge of the backup path provided by the standby PE.

Because DHCP requests are broadcast packets that normally do not propagate outside of their IP subnet, a DHCP relay agent intercepts such requests and forwards them as unicast messages to a configured DHCP server.

When forwarding a DHCP message, the relay agent sets the GIADDR in the packet to the IP address of its ingress interface. This allows DHCP clients to use a DHCP server on a remote network. From both a scalability and a security point of view, it is recommended that the DHCP relay agent is positioned as close as possible to the client terminals.

DHCP relay is used in a Layer 3 environment, and therefore is only supported in IES services and VPRN services.

When DHCP clients and servers are in different VPRN routing instances of which one is the Base routing instance, route leaking (GRT-leaking) should be used to relay DHCPv4 and DHCPv6 messages between a VPRN and the Global Routing Table (GRT).

While DHCP relay is not implemented in a VPLS, it is still possible to insert or modify Option 82 information.

In a routed CO environment, the subscriber interface’s group interface DHCP relay is stateful.

In network deployments where DHCPv4 client subnets cannot be leaked in the DHCPv4 server routing instance, unicast renewal messages (DHCP ACKs) cannot be routed in the DHCPv4 server routing instance, as shown in Unicast renewal routing problem. The DHCP server sets the destination IP address of the DHCP ACK to the client IP address (ciaddr) as received in the DHCP REQUEST message. Because there is no route available for the client subnet in the DHCP server routing instance, the DHCP ACK cannot be delivered.

The unicast renewal routing problem shown in Unicast renewal routing problem can be solved with a relay proxy function that enhances the DHCPv4 relay. Use the following command to resolve this problem.

• MD-CLI

  configure service ies interface ipv4 dhcp relay-proxy
  configure service ies subscriber-interface group-interface ipv4 dhcp relay-proxy
  configure service ies subscriber-interface ipv4 dhcp relay-proxy
  configure service ies interface ipv4 dhcp relay-proxy
  configure service ies subscriber-interface group-interface ipv4 dhcp relay-proxy
  configure service ies subscriber-interface ipv4 dhcp relay-proxy
  

• classic CLI

  configure service ies interface dhcp relay-proxy
  configure service ies subscriber-interface dhcp relay-proxy
  configure service ies subscriber-interface group-interface dhcp relay-proxy
  configure service vprn interface dhcp relay-proxy
  configure service vprn subscriber-interface dhcp relay-proxy
  configure service vprn subscriber-interface group-interface dhcp relay-proxy
  

With the relay-proxy command in the DHCPv4 relay on a regular interface or group interface, the unicast renewals are now also relayed to the DHCPv4 server, as described below and shown in Relay unicast messages:

• In the client to server direction, the source IP address is updated and the gateway IP address (gi-address) field is added before sending the message to the intended DHCP server (the message is not broadcasted to all configured DHCP servers.

• In the server to client direction, the GI address field is removed and the destination IP address is updated with the value of the IP address (yiaddr) field.

When relay-proxy is enabled, the GI address can be configured to any local address that is configured in the same routing instance. The GI address is the only address that must be leaked in the DHCPv4 server routing instance because a DHCPv4 server always sends the response on a relayed packet to the relay agent using the gi-address as the destination IP address.

By default, unicast DHCPv4 RELEASE messages are forwarded transparently by a relay proxy function. The optional release-update-src-ip command option updates the source IP address with the value that is used for all relayed DHCPv4 messages, as shown in Relay unicast messages.

DHCPv4 FORCERENEW messages that are sent from a trusted external DHCPv4 server to a DHCPv4 relay agent configured as a relay proxy are forwarded to the DHCP client, if a corresponding DHCPv4 lease exists; otherwise, the DHCPv4 FORCERENEW messages are dropped.

The relay-proxy command can also be used to hide the DHCPv4 server address for DHCP clients. This prevents the client from learning the DHCPv4 server infrastructure details such as the IP address and number of servers. Hiding infrastructure details helps in Denial of Service (DoS) prevention.

The optional siaddr-override command option in relay-proxy enables DHCPv4 server IP address hiding toward the client. The client interacts with the relay proxy as if it is the DHCP server. In addition to the relay proxy functions as described earlier, the following actions are performed when DHCPv4 server IP address hiding is configured:

• In all DHCP messages to the client, the value of the following header fields and DHCP options containing the DHCP server IP address is replaced with the configured IP address:

  • the source IP address

  • the siaddr field in the DHCPv4 header if it is not equal to zero in the message received from the server

  • the Server Identification option (DHCPv4 option 54) if present in the original server message

• The DHCP OFFER selection occurs during initial binding. Only the first DHCP OFFER message is forwarded to the client. Subsequent DHCP OFFER messages from different servers are silently dropped.

The siaddr-override command option can be any local address in the same routing instance. If DHCP relay lease split is enabled, siaddr-override command option has priority over the emulated-server configured in the proxy server and is used as the source IP address.

The active DHCPv4 server IP address obtained from the DHCP OFFER selection is required for the IP address hiding function and is stored in the lease state record. Therefore, the following command must be enabled on the interface when siaddr-override is configured.

• MD-CLI

  configure service ies interface ipv4 dhcp lease-populate
  configure service ies subscriber-interface group-interface ipv4 dhcp lease-populate
  configure service vprn interface ipv4 dhcp lease-populate
  configure service vprn subscriber-interface ipv4 dhcp lease-populate
  configure service vprn subscriber-interface group-interface ipv4 dhcp lease-populate
  

• classic CLI

  configure service ies interface dhcp lease-populate
  configure service ies subscriber-interface group-interface dhcp lease-populate
  configure service vprn interface dhcp lease-populate
  configure service vprn subscriber-interface dhcp lease-populate
  configure service vprn subscriber-interface group-interface dhcp lease-populate

DHCP server IP address hiding/initial binding shows the initial lease binding phase of a relay proxy with DHCP server address hiding enabled. In the absence of a DHCP lease state in the initial lease binding phase, the DHCP server IP address resulting from the OFFER selection is stored in a DHCP transaction cache. After successful lease binding, the DHCP server IP address is added to the lease state record.

In a host creation failure scenario, if no transaction cache or lease state is available when a DHCP REQUEST message is received, then the DHCP REQUEST is silently dropped. The drop reason can be found by enabling DHCP debug.

DHCP server IP address hiding/lease renewal shows the lease renewal phase of a relay proxy with DHCP server address hiding enabled. A unicast REQUEST (renew) is relayed only to the DHCP server owning the lease. A broadcast REQUEST (rebind) is relayed to all configured DHCP servers.

During lease renewal, the DHCP server IP address can be updated in the lease state if the DHCP ACK is received from a different server. This optimizes the DHCP proxy relay operation in a DHCP server failover scenario. This is shown in DHCP server IP address hiding, lease renewal with active server failure.

DHCP server IP address hiding, release shows the release in a relay proxy scenario with DHCP server address hiding enabled. The RELEASE message is sent only to the DHCP server owning the lease. Optionally, the source IP address can be updated.

Relay proxy can be enabled on subscriber group-interfaces and regular interfaces in an IES or VPRN service.

A relay proxy function is not supported with a double DHCPv4 relay (Layer 3 DHCPv4 relay in front of a DHCPv4 relay with relay-proxy enabled).

[ex:/configure service vprn "1"]
A:admin@node-2# info
    customer "1"
    interface "lo0" {
        loopback true
        ipv4 {
            primary {
                address 192.0.2.10
                prefix-length 32
            }
        }
    }
    interface "lo1" {
        loopback true
        ipv4 {
            primary {
                address 192.0.2.11
                prefix-length 32
            }
        }
    }
    subscriber-interface "sub-int-1" {
        ipv4 {
            address 10.1.0.254 {
                prefix-length 24
            }
        }
        group-interface "group-int-1-1" {
            ipv4 {
                dhcp {
                    admin-state enable
                    server [172.16.1.1]
                    gi-address 192.0.2.11
                    src-ip-addr gi-address
                    lease-populate {
                        max-leases 32767
                    }
                    relay-proxy {
                        release-update-src-ip true
                        siaddr-override 192.0.2.10
                    }
                }
            }
        }
    }

A:node-2>config>service>vprn$ info
----------------------------------------------
            shutdown
            interface "lo0" create
                address 192.0.2.10/32
                loopback
            exit
            interface "lo1" create
                address 192.0.2.11/32
                loopback
            exit
            subscriber-interface "sub-int-1" create
                address 10.1.0.254/24
                group-interface "group-int-1-1" create
                    dhcp
                        server 172.16.1.1
                        lease-populate 32767
                        relay-proxy release-update-src-ip siaddr-override 192.0.2.10
                        gi-address 192.0.2.11 src-ip-addr
                        no shutdown
                    exit
                exit
            exit
----------------------------------------------

In the base router context, Ethernet ports can be configured with a router interface that supports a DHCP client. When the node operates as a DHCP client, it learns the IP address of the interface via dynamic IP address assignment. The DHCP client functionality is enabled by issuing the no shutdown command on the DHCP client in the configure router interface autoconfigure dhcp-client context. The following output shows an example of a router interface enabled as a DHCP client.

*A:DUT# config# router interface "station-wlan-ifc"
    port 1/4/4   
    autoconfigure dhcp-client
        no shutdown
        exit
    exit

The 7705 SAR Gen 2 supports up to three DHCP clients per node .

When the DHCP client is enabled, changes to the DHCP client configuration take effect when the shutdown command is issued followed by the no shutdown command.

If DHCP relay configurations exist on the node, the DHCP client cannot be enabled until the DHCP relay configurations are removed. Similarly, if DHCP client configurations exist on the node, DHCP relay cannot be enabled until the DHCP client configurations are removed.

The DHCP client only supports IPv4.

When the DHCP client first becomes operational, it learns an IP address from a remote DHCP server using a DHCP DISCOVER message.

The node only sends a DHCP DISCOVER message if:

• the DHCP client is enabled and the router interface is operationally up. Shutting down the DHCP client forces the release of the IP address.

• a DHCP NAK message is received from the DHCP server that invalidates the previous DHCP DISCOVER message or any existing lease

When a DHCP client is shut down, all cached values (such as IP addresses and DHCP options) are cleared. They are rediscovered by issuing the no shutdown command.

If the port comes operationally up while the DHCP client is enabled and a DHCP discovery was not previously completed or a DHCP release was previously issued, then DHCP discovery is performed. If the port comes operationally up while the DHCP client is enabled and there was a previously completed DHCP discovery, then the DHCP client performs a DHCP REQUEST using the previously cached DHCP information from the discovery.

The operator can force a rediscovery procedure by executing the restart command in the tools perform router autoconfigure dhcp-client interface context.

The requested DHCP lease time can be configured using the CLI; however, the DHCP server can override this value. The node tracks the DHCP lease time and sends a DHCP REQUEST when half the lease time has elapsed. An IP address lease can be renewed manually using the tools perform router autoconfigure dhcp-client interface lease-renew command.

If the router interface goes down, the DHCP client parameters are cached for the interface. When the interface comes back up, if an IP address has been allocated and the lease time has not expired, the DHCP router interface sends a DHCP REQUEST to confirm that it can continue to use the IP address associated with the lease.

DHCP options must be configured in the CLI to make use of options received by the DHCP server. Any options received from the DHCP server are ignored if the corresponding options are not specified in the CLI. The DHCP client options are router, static-route, and dns-server. They are configured in the config router interface autoconfigure dhcp-client request-options context.

The show router route-table protocol dhcp-client command can be used to view the active routes in the routing table that have been learned by the DHCP client. If the same route is received from more than one DHCP client, the route received from the DHCP server with the lowest ID (option 54) is installed in the route table.

The show router dns command can be used to view whether the DNS server has been configured to send request messages to the DHCP server. The node supports up to six DNS server entries learned by the DHCP clients. Only the first six DNS servers are stored by the node; any subsequent DNS servers that are learned are ignored.

The CLI provides the option to use the router from the DHCP OFFER as the default gateway. In some scenarios, the router that is reachable from the WLAN port or an Ethernet port is the default gateway. In other scenarios, the cellular interface has reachability to the default gateway. The DHCP client router option (under request-options) enables the router request option in the DHCP OFFER message. If the router option is enabled, the default gateway is assigned by the DHCP server.

The DHCP DISCOVER message sent from the node to the DHCP server contains the following options:

• chaddr—the MAC address of the client, either the WLAN or Ethernet port

• Option 51—the configured IP address lease time

• Option 53—the DHCP message type (DISCOVER)

• Option 60—a user-configurable vendor class identifier, either a hexadecimal string or an ASCII string

• Option 61—a user-defined client identifier: a hexadecimal string, an ASCII string, an interface name, or the client MAC address

• Option 55—the parameter request list:

  • Option 1—the subnet mask value

  • Option 3—the router option, a list of IP addresses for routers on the client subnet (unused if not enabled in the CLI)

  • Option 54—the DHCP server address

The DHCP OFFER message from the DHCP server must contain the following options at a minimum:

• yiaddr—the DHCP router interface IP address

• Option 1—the subnet mask value

• Option 3—the router option, a list of IP addresses for routers on the client subnet

• Option 51—the configured IP address lease time

• Option 53—the DHCP message type (OFFER)

• Option 54—the DHCP server address

When responding to the server DHCP OFFER or when extending the time of an existing lease, the DHCP REQUEST message sent from the node to the DHCP server contains the following options:

• chaddr—the client MAC address

• Option 50—the requested IP address; this address is the same as the address contained in the yiaddr field that was received in the DHCP OFFER message

• Option 53—the DHCP message type (REQUEST)

• Option 54—the DHCP server address; this address is the same as the address received in the OFFER message

• Option 51—the IP address lease time; this value is the same as the lease time received in the OFFER message

• Option 60—the vendor class identifier; this value is the same as the vendor class identifier in the DISCOVER message

• Option 61—the client identifier; this value is the same as the client identifier in the DISCOVER message

• Option 55—the parameter request list:

  • Option 1—the subnet mask value

  • Option 3—the router option (unused if not enabled in the CLI)

  • Option 6—the DNS server option (unused if not enabled in the CLI)

  • Option 54—the DHCP server address

  • Option 121—the static-route option (unused if not enabled in the CLI)

When the DHCP client is shut down, a DHCP RELEASE message is sent to the DHCP server.

For BGP peers to other nodes behind the WLAN AP, the BGP local address can be set using the router interface name where the DHCP client is configured so that changes in the interface address because of DHCP messages are reflected in the local address of BGP sessions using this interface as the local address.

The SR OS 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 version of the Internet Protocol designed as a successor to IP version 4 (IPv4) (RFC-791, Internet Protocol). The changes from IPv4 to IPv6 affect the following categories:

• 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 autoconfiguration 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 and is used to send a packet to any one of a group of nodes.

• 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.

• 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.

• 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.

• 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.

The following table lists IPv6 header fields and their descriptions.

Use the commands in the following context to forward packets of a static route to an indirect next-hop over a tunnel programmed in TTM:

• MD-CLI

  configure router static-routes route indirect tunnel-next-hop

  In the MD-CLI, if the tunnel-next-hop context is configured and resolution is set to none, the binding to the tunnel is removed and resolution resumes in RTM to IP next-hops.

• classic CLI

  configure router static-route-entry indirect tunnel-next-hop

  In the classic CLI, if the tunnel-next-hop context is configured and resolution is set to disabled, the binding to the tunnel is removed and resolution resumes in RTM to IP next-hops.

If the resolution is set to any, any supported tunnel type in the static route context is selected following TTM preference.

The following tunnel types are supported in a static route context: LDP, RSVP-TE, Segment Routing (SR) Shortest Path, and Segment Routing Traffic Engineering (SR-TE):

• LDP

  The ldp command option instructs the code to search for an LDP LSP with a FEC prefix corresponding to the address of the indirect next-hop. Both LDP IPv4 FEC and LDP IPv6 FEC can be used as the tunnel next-hop. However, only an indirect next-hop of the same family (IPv4 or IPv6) as the prefix of the route can use an LDP FEC as the tunnel next-hop. In other words, an IPv4 (IPv6) prefix can only be resolved to an LDP IPv4 (IPv6) FEC.

• RSVP-TE

  The rsvp-te command option instructs the code to search for the set of lowest metric RSVP-TE LSPs to the address of the indirect next-hop. The LSP metric is provided by MPLS in the tunnel table. The static route treats a set of RSVP-TE LSPs with the same lowest metric as an ECMP set.

  The user has the option of configuring a list of RSVP-TE LSP names to be used exclusively instead of searching in the tunnel table. In that case, all LSPs must have the same LSP metric in order for the static route to use them as an ECMP set. Otherwise, only the LSPs with the lowest common metric value are selected.

  A P2P auto-lsp that is instantiated via an LSP template can be selected in TTM when resolution is set to any. However, it is not recommended to configure an auto-lsp name explicitly under the rsvp-te node as the auto-generated name can change if the node reboots, which blackholes the traffic of the static route.

• SR shortest path

  When the sr-isis or sr-ospf command options are enabled, an SR tunnel to the indirect next-hop is selected in the TTM from the lowest preference IS-IS or OSPF instance, and if many instances have the same lowest preference, it is selected from the lowest numbered IS-IS or OSPF instance. Both SR-ISIS IPv4 and SR-ISIS IPv6 tunnels can be used as tunnel next-hops. However, only an indirect next-hop of the same family (IPv4 or IPv6) as the prefix of the route can use an SR-ISIS tunnel as a tunnel next-hop. In other words, an IPv4 (IPv6) prefix can only be resolved to a SR-ISIS IPv4 (IPv6).

• SR-TE

  The sr-te command option instructs the code to search for the set of lowest metric SR-TE LSPs to the address of the indirect next-hop. The LSP metric is provided by MPLS in the tunnel table. The static route treats a set of SR-TE LSPs with the same lowest metric as an ECMP set.

  The user has the option of configuring a list of SR-TE LSP names to be used exclusively instead of searching in the tunnel table. In that case, all LSPs must have the same LSP metric in order for the static route to use them as an ECMP set. Otherwise, only the LSPs with the lowest common metric value are selected.

Realize that the resolution filter, under static-route entry, does not validate the provided lsp-name type of the LSP against the requested filter context protocol type.

If one or more explicit tunnel types are specified using the resolution-filter command option, only these tunnel types are selected again following the TTM preference.

The user must set resolution to filter to activate the list of tunnel-types configured under resolution-filter.

If disallow-igp is enabled, the static route is not activated using IP next-hops in RTM if no tunnel next-hops are found in TTM.

This feature invalidates a static route based on the reachability of the next-hop in the ARP cache when the validate-next-hop command is enabled for an IPv4 static route. Use the commands in the following contexts to enable the validate-next-hop feature for an IPv4 static route:

• MD-CLI

  configure router static-routes route next-hop
  configure service vprn static-routes route next-hop

• classic CLI

  configure router static-route-entry next-hop
  configure service vprn static-route-entry next-hop

In this case, when the ARP entry for the next-hop is INVALID or not populated, the static route must remain invalid/inactive. When an ARP entry for the next-hop is populated based on a gratuitous ARP received or periodic traffic destined for it and the usual ARP who-has procedure, the static route becomes valid/active and is installed.

When LDP shortcut is enabled, LDP populates the RTM with next-hop entries corresponding to all prefixes for which it activated an LDP FEC. For an activated prefix, two route entries are populated in RTM. One corresponds to the LDP shortcut next-hop and has an owner of LDP. The other one is the regular IP next-hop. The LDP shortcut next-hop always has preference over the regular IP next-hop for forwarding user packets and specified control packets over a specific outgoing interface to the route next-hop.

The prior activation of the FEC by LDP is done by performing an exact match with an IGP route prefix in RTM. It can also be done by performing a longest prefix match with an IGP route in RTM if the aggregate-prefix-match command option is enabled globally in LDP.

The LDP next-hop entry is not exported to the LDP control plane or to any other control plane protocols except OSPF, IS-IS, and an OAM control plane specified in Handling of control packets.

This feature is not restricted to /32 IPv4 prefixes or /128 IPv6 FEC prefixes. However, only /32 IPv4 and /128 IPv6 FEC prefixes are populated in the tunnel table for use as a tunnel by services.

All user and specified control packets for which the longest prefix match in RTM yields the FEC prefix are forwarded over the LDP LSP. The following is an example of the resolution process.

Assume that the egress LER advertised a FEC for some /24 prefix using the fec-originate command. At the ingress LER, LDP resolves the FEC by checking in RTM that an exact match exists for this prefix. After the LDP activates the FEC, it programs the NHLFE in the egress datapath and the LDP tunnel information in the ingress datapath tunnel table.

Next, LDP provides the shortcut route to RTM, which associates it with the same /24 prefix. There are two entries for this /24 prefix: the LDP shortcut next-hop and the regular IP next-hop. The latter was used by LDP to validate and activate the FEC. RTM then resolves all user prefixes that succeed a longest prefix match against the /24 route entry to use the LDP LSP.

Now assume that the aggregate-prefix-match was enabled and that LDP found a /16 prefix in RTM to activate the FEC for the /24 FEC prefix. In this case, RTM adds a new, more-specific route entry of /24 and has the next-hop as the LDP LSP. However, RTM does not have a specific /24 IP route entry. RTM then resolves all user prefixes that succeed a longest prefix match against the /24 route entry to use the LDP LSP. All other prefixes that succeed a longest prefix match against the /16 route entry uses the IP next-hop. LDP shortcut also works when using RIP for routing.

See the 7705 SAR Gen 2 MPLS Guide for information about LDP-IGP synchronization.

After the LDP activates an FEC for a prefix and programs RTM, it also programs the ingress tunnel table in IOM or online cards with the LDP tunnel information.

When an IPv4 packet is received on an ingress network interface, a subscriber IES interface, or a regular IES interface, the lookup of the packet by the ingress IOM or line card results in the packet being sent labeled with the label stack corresponding to the NHLFE of the LDP LSP when the preferred RTM entry corresponds to an LDP shortcut.

If the preferred RTM entry corresponds to an IP next-hop, the IPv4 packet is forwarded unlabeled.

The switching from the LDP shortcut next-hop to the regular IP next-hop when the LDP FEC becomes unavailable depends on whether the next-hop is still available. If it is (for example, the LDP FEC was withdrawn because of LDP control plane issues) the switchover should be faster. If the next-hop determination requires IGP to re-converge, this takes longer. However, no target is set.

The switching from a regular IP next-hop to an LDP shortcut next-hop usually occurs only when both are available. However, the programming of the NHLFE by LDP and the programming of the LDP tunnel information in the ingress IOM or line cards tunnel table are asynchronous. If the tunnel table is configured first, it is possible that traffic is black-holed for some time.

When ECMP is enabled and multiple equal-cost next-hops exist for the IGP route, the ingress IOM or line card sprays the packets for this route based on the hashing routine currently supported for IPv4 packets.

When the preferred RTM entry corresponds to an LDP shortcut route, spraying is performed across the multiple next-hops for the LDP FEC. The FEC next-hops can either be direct link LDP neighbors or T-LDP neighbors reachable over RSVP LSPs, in the case of LDP-over-RSVP, but not both. This is as per ECMP for LDP.

When the preferred RTM entry corresponds to a regular IP route, spraying is performed across regular IP next-hops for the prefix.

Spraying across regular IP next-hops and LDP-shortcut next-hops concurrently is not supported.

All control plane packets do not see the LDP shortcut route entry in RTM with the exception of the following control packets, which are forwarded over an LDP shortcut when enabled:

• A locally generated or in transit ICMP ping and trace route of an IGP route. The transit message appears as a user packet to the ingress LER node.

• A locally generated response to a received ICMP ping or trace route message.

All other control plane packets that require an RTM lookup and knowledge of which destination is reachable over the LDP shortcut continues to be forwarded over the IP next-hop route in RTM.

Multicast packets cannot be forwarded or received from an LDP LSP. This is because there is no support for the configuration of such an LSP as a tunnel interface in PIM. Only an RSVP P2MP LSP is currently allowed.

If a multicast packet is received over the physical interface, the uRPF check does not resolve to the LDP shortcut because the LDP shortcut route in RTM is not made available to multicast application.

There is no interaction between an LDP shortcut for BGP next-hop resolution and the LDP shortcut for IGP route resolution. BGP continues to resolve a BGP next-hop to an LDP shortcut if the user enabled the following command option in BGP. The following example shows the configuration to enable the resolution of a BGP next-hop to an LDP shortcut.

[ex:/configure router "Base" bgp next-hop-resolution shortcut-tunnel]
A:admin@node-2# info
    family ipv4 {
        resolution-filter {
            ldp true
        }
    }

A:node-2>config>router>bgp>next-hop-res>shortcut-tunn# info
----------------------------------------------
                family ipv4
                    resolution-filter
                        ldp
                    exit
                exit
----------------------------------------------

A static route continues to be resolved by searching an LDP LSP whose FEC prefix matches the specified indirect next-hop for the route. In contrast, the LDP shortcut for IGP route resolution uses the LDP LSP as a route. The most specific route for a prefix is selected and, if both a static and IGP routes exist, the RTM route type preference is used to select one.

For the LDP shortcut to be usable, SR OS must originate a <FEC, label> binding for each IGP route it learns of even if it did not receive a binding from the next-hop for that route. The router must assume that it is an egress LER for the FEC until the route disappears from the routing table or the next-hop advertises a binding for the FEC prefix. In the latter case, SR OS becomes a transit LSR for the FEC.

SR OS originates a <FEC, label> binding for its system interface address only by default. The only way to originate a binding for local interfaces and routes that are not local to the system is by using the fec-originate capability.

Use the fec-originate command to generate bindings for all non-local routes for which this node acts as an egress LER for the corresponding LDP FEC. Specifically, this feature must support the FEC origination of IGP learned routes and subscriber/host routes statically configured or dynamically learned over subscriber IES interfaces.

An LDP LSP used as a shortcut by IPv4 packets may also be tunneled using the LDP-over-RSVP feature.

An NGE domain is a group of nodes and router interfaces forming a network that uses a single key group to create a security domain. NGE domains are created when router interface encryption is enabled on router interfaces that need to participate in the NGE domain. The NSP NFM-P assists users in managing the nodes and interfaces that participate in the NGE domain. See the NSP NFM-P User Guide for more information.

NGE Domain Transit shows various traffic types crossing an NGE domain.

In NGE Domain Transit, nodes A, B, C, and D have router interfaces configured with router interface encryption enabled. Traffic is encrypted when entering the NGE domain using the key group configured on the router interface and is decrypted when exiting the NGE domain. Traffic may traverse multiple hops before exiting the NGE domain, yet decryption only occurs on the final node when the traffic exits the NGE domain.

Various traffic types are supported and encrypted when entering the NGE domain, as illustrated by the following items on node A in NGE Domain Transit:

• Item 1: Self-generated packets

  These packets, which include all types of control plane and management packets such as OSPF, BGP, LDP, SNMPv3, SSH, ICMP, RSVP-TE, and 1588, are encrypted.

• Item 2: User Layer 3 and VXLAN packets

  Any Layer 3 user packets that are routed into the NGE domain from an interface outside the NGE domain are encrypted. Any VXLAN packets that are routed into the NGE domain from this NGE node are encrypted.

• Item 3: IPsec packets

  IPsec packets are NGE-encrypted when entering the NGE domain to ensure that the IPsec packets’ security association information does not conflict with the NGE domain.

GRE-MPLS- or MPLSoUDP-based service traffic consists of Layer 3 packets, and router interface NGE is not applied to these types of packets. Instead, service-level NGE is used for encryption to avoid double-encrypting these packets and impacting throughput and latencies. The two types of GRE-MPLS or MPLSoUDP packets that can enter the NGE domain are illustrated by items 4 and 5 in NGE Domain Transit.

• Item 4: GRE-MPLS and MPLSoUDP packets (SDP or VPRN) with service-level NGE enabled

  These encrypted packets use the key group that is configured on the service. The services key group may be different from the key group configured on the router interface where the GRE-MPLS or MPLSoUDP packet enters the NGE domain.

• Item 5: GRE-MPLS and MPLSoUDP packets (SDP or VPRN) with NGE disabled

  These packets are not encrypted and can traverse the NGE domain in clear text. If these packets require encryption, SDP or VPRN encryption must be enabled.

Creating an NGE domain from the NSP NFM-P requires the user to determine the type of NGE domain being managed. This indicates whether NGE gateway nodes are required to manage the NGE domain, and other operational considerations. The two types of NGE domains are:

• Private IP/MPLS network NGE domain

• Private over intermediary network NGE domain

An NGE domain is a group of nodes whose router interfaces in the base routing context (GRT) are enabled for router interface NGE. An interface without router interface NGE enabled is considered to be outside the NGE domain. NGE domains use only one key group when the domain is created; however, two key groups may be active at when if some links within the NGE domain are in transition from one key group to the other.

Inside and outside NGE domains illustrates the NGE domain concept. Inside and outside NGE domains configuration scenarios describes the three configuration scenarios inside the NGE domain.

A router interface is considered to be inside the NGE domain when it has been configured with group-encryption on the interface. When group-encryption is configured on the interface, the router can receive unencrypted packets or NGE-encrypted packets from any configured key group on the router, but any other type of IPsec-formatted packet is not allowed. If an IPsec-formatted packet is received on an interface that has group-encryption enabled, it does not pass NGE authentication and is dropped. Therefore, IPsec packets cannot exist within the NGE domain without first being converted to NGE packets. This conversion requirement delineates the boundary of the NGE domain and other IPsec services.

When NGE router interface encryption is enabled and only an outbound key group is configured, the interface can receive unencrypted packets or NGE-encrypted packets from any configured key group on the router. All outbound packets are encrypted using the outbound key group if the packet was not already encrypted further upstream in the network.

When NGE router interface encryption has been configured with both an inbound and outbound key group, only NGE packets encrypted with the key group security association can be sent and received over the interface.

When there is no NGE router interface encryption, the interface is considered outside the NGE domain where NGE is not applied.

See the ‟NGE Packet Overhead and MTU Considerations” section in the 7705 SAR Gen 2 Services Overview Guide for MTU information related to enabling NGE on a router interface.

NGE router interface encryption is never applied to GRE-MPLS or MPLSoUDP packets, for example:

• GRE with the GRE protocol ID set to MPLS Unicast (0x8847) or Multicast (0x8848)

• UDP packets with destination port = 6635)

GRE-MPLS and MPLSoUDP packets that enter the NGE domain or transit the NGE domain are forwarded as is.

Because these GRE-MPLS and MPLSoUDP packets provide transport for MPLS-based services, they already use the NGE services-based encryption techniques for MPLS, such as SDP or VPRN-based encryption. To avoid double encryption, the packets are left in cleartext when entering an NGE domain or crossing intermediate nodes in the NGE domain, and are forwarded as needed when exiting an NGE domain.

NGE router interface encryption does not differentiate between EVPN-VXLAN tunnels and other L3 traffic, and therefore encrypts all EVPN-VXLAN traffic that egresses the node.

For received encrypted EVPN-VXLAN packets, if the VXLAN tunnel terminates on the node (that is, the destination IP is for a VTEP on this node), then the NGE packet is decrypted and the EVPN-VXLAN traffic is processed as if NGE encryption never took place.

In some cases, Layer 3 packets may need to cross the NGE domain in clear text, such as when an NGE-enabled router needs to peer with a non-NGE-capable router to exchange routing information. This can be accomplished by using a router interface NGE exception filter applied on the router interface for the required direction, inbound or outbound.

Router interface NGE exception filter example shows the use of a router interface NGE exception filter.

The inbound or outbound exception filter is used to allow specific packet flows through the NGE domain in clear text, where there is an explicit inbound and outbound key group configured on the interface. The behavior of the exception filter for each router interface configuration is as follows:

• NGE enabled, no inbound or outbound key group

  In this scenario, the router does not encrypt outbound traffic, and so the outbound exception filter is not applied. The router can still receive inbound NGE packets, so the exception filter is applied to inbound packets. If the filter detects a match, clear text packets can be received and forwarded by the router.

• Outbound key group, no inbound key group

  The outbound exception filter is applied to outbound traffic, and packets that match the filter are not encrypted on egress. The router can receive inbound NGE packets without an inbound key group set and applies the exception filter to inbound packets. If the filter detects a match, clear text packets can be received and forwarded by the router.

• Inbound and outbound key group

  The inbound and outbound exception filters are applied, and any packets that match are passed in clear text.

IPsec packets can cross the NGE domain because they are still considered Layer 3 packets. To avoid confusion between the security association used in an IPsec packet and the one used in a router interface NGE packet, the router always applies NGE to any IPsec packet that traverses the NGE domain.

IPsec packets that originate from a router within the NGE domain are not allowed to enter the NGE domain. The only exception to this restriction is OSPFv3 packets.

IPsec packets transiting an NGE domain shows how IPsec packets can transit an NGE domain.

An IPsec packet enters the router from outside the NGE domain. When the router determines that the egress interface to route the packet is inside an NGE domain, it selects an NGE router interface with one of the following configurations.

• NGE enabled with no inbound or outbound key group configured

  This link cannot forward the IPsec packet without adding the NGE ESP, but because nothing is configured for the outbound key group, the packet must be dropped.

• NGE enabled with outbound key group configured and no inbound key group configured — the packet originates outside the NGE domain, so the router adds an ESP header over the existing ESP and encrypts the payload using the NGE domain keys for the configured outbound key group.

• NGE enabled with both inbound and outbound key groups configured — the packet originates outside the NGE domain, so the router adds an ESP header over the existing ESP and encrypts the payload using the NGE domain keys for the configured outbound key group.

OSPFv3 IPsec support also uses IPsec transport mode packets. These packets originate from the CPM, which is considered outside the NGE domain; however, the above rules for encapsulating the packets with an NGE ESP apply and allow these packets to successfully transit the NGE domain.

Multicast packets that traverse an NGE domain can be categorized into two main scenarios:

• Scenario 1

  Multicast packets that ingress the router on an interface that is outside the NGE domain. These packets can egress a variety of interfaces that are either inside or outside the NGE domain.

• Scenario 2

  Multicast packets that ingress the router on an interface that is inside the NGE domain. These packets can egress a variety of interfaces that are either inside or outside the NGE domain. This scenario has two cases:

  • Scenario 2a

    The ingress multicast packet is not yet NGE-encrypted.

  • Scenario 2b

    The ingress multicast packet is NGE-encrypted.

Processing multicast packets shows these scenarios.

Multicast packets received from outside the NGE domain (Scenario 1) are processed similarly to multicast packets received from inside the NGE domain (Scenarios 2a and 2b).

The processing rule is that multicast packets are always forwarded as clear text over the fabric. This means that for Scenario 2b, when a multicast packet is received on an encryption-capable interface and is NGE-encrypted, the packet is always decrypted first so that it can be processed in the same way as packets in Scenarios 1 and 2a.

On egress, the following scenarios apply:

• Egressing an interface outside the NGE domain

  Packets are processed in the same way as any multicast packets forwarded out a non-NGE interface.

• Egressing an NGE router interface and no inbound or outbound key group is configured

  The router forwards these packets out from the egress interface without encrypting them because there is no outbound key group configured. This behavior also applies to unicast packets in the same scenario.

• egressing an NGE router interface with the outbound key group configured — the router encrypts the multicast packet using the SPI keys of the outgoing SA configured in the key group. This behavior also applies to unicast packets in the same scenario.

When NGE is enabled on a router interface, BFD packets that originate from the network processor on the adapter card or from the system are encrypted in the same way as BFD packets that are generated by the CPM.

When NGE is enabled on a router interface, the ACL function is applied as follows:

• on ingress

  Normal ACLs are applied to traffic received on the interface that could be either NGE-encrypted or clear text. For NGE-encrypted packets, this implies that only the source, destination, and IP options are available to filter on ingress, as the protocol is ESP, and the packet is encrypted. If an IP exception ACL is also configured on the interface, the IP exception ACL is applied first to allow any clear text packets to ingress as needed. After the IP exception ACL is applied and if another filter or ACL is configured on the interface, the other filter processes the remaining packet stream (NGE-encrypted and IP exception ACL packets), and other ACL functions such as PBR or Layer 4 information filtering could be applied to any clear text packets that passed the exception ACL.

• on egress

  ACLs are applied to packets before they are NGE-encrypted as per normal operation without NGE enabled.

Typically, ICMP works as expected over an NGE domain when all routers participating in the NGE domain are NGE-capable; this includes running an NGE domain over a private IP/MPLS network. When an ICMP message is required, the NGE packet is decrypted first, and the original packet is restored to create a detailed ICMP message using the original packet’s header information.

When the NGE domain crosses a Layer 3 service provider, or crosses over routers that are not NGE-aware, it is not possible to create a detailed ICMP message using the original packet’s information, as the NGE packet protocol is always set to ESP. Furthermore, the NGE router that receives these ICMP messages drops them because the messages are not NGE-encrypted.

The combination of dropping ICMP messages at the NGE border node and the missing unencrypted packet details in the ICMP information can cause problems with diagnosing network issues.

To help with diagnosing network issues, additional statistics are available on the interface to show whether ICMP messages are being returned from a foreign node. The following statistics are included in the group encryption NGE statistics for an interface:

• Group Enc Rx ICMP DestUnRch Pkts

• Group Enc Rx ICMP TimeExc Pkts

• Group Enc Rx ICMP Other Pkts

These statistics are used when clear text ICMP messages are received on an NGE router interface. The Invalid ESP statistics are not used in this situation even though the packet does not have a correct NGE ESP header. If there is no ingress exception ACL configured on the interface to allow the ICMP messages to be forwarded, the messages are counted and dropped.

If more information is required for these ICMP messages, such as source or destination address information, a second ICMP filter can be configured on the interface to allow logging of the ICMP messages. If the original packet information is also required, an egress exception ACL can be configured with the respective source or destination address information, or other criteria, to allow the original packet to enter the NGE domain in clear text and determine which flows are causing the ICMP failures.

If a router interface is enabled for encryption and Layer 3 1588v2 packets are sent, they are encrypted using NGE. This means that if port timestamping is enabled on a router interface with NGE, the port timestamp is applied to the Layer 3 1588v2 packet using software-based timestamping instead of hardware-based timestamping, and consequently, timing accuracy may degrade. The exact level of timing or synchronization degradation is dependent on many factors, and testing is recommended to measure any impact.

If there is a need to support Layer 3 1588v2 with better accuracy for frequency or better time using port timestamping, an NGE exception ACL is required to keep the Layer 3 1588v2 packets in clear text. The exception ACL must enable UDP packets with destination port 319 to be sent in clear text.

See each specific chapter for specific routing protocol information and command syntax to configure protocols such as IS-IS and BGP.

The most basic router configuration must have the following:

• system name

• system address

The following example shows the 7705 SAR Gen 2 router configuration.

[ex:/configure router "Base"]
A:admin@node-2# info
    autonomous-system 100
    router-id 10.10.10.103
    confederation {
        confed-as-num 1000
        members 100 { }
        members 200 { }
        members 300 { }
    }
...
    interface "system" {
        ipv4 {
            primary {
                address 10.10.10.103
                prefix-length 32
            }
        }
    }
    interface "to-104" {
        port 1/1/1
        ipv4 {
            primary {
                address 10.0.0.103
                prefix-length 24
            }
        }
    }
...
    isis 0 {
        loopfree-alternate {
        }
    }

A:node-2>config# info
. . .
#------------------------------------------
# Router Configuration
#------------------------------------------
    router
        interface "system"
            address 10.10.10.103/32
        exit
        interface "to-104"
            address 10.0.0.103/24
            port 1/1/1
            exit
        exit
        autonomous-system 100
        confederation 1000 members 100 200 300
   router-id 10.10.10.103
...
    exit
    isis
    exit
...
#------------------------------------------

This section describes the basic system configuration tasks.

The system command sets the name of the device and is used in the prompt string. Only one system name can be configured. If multiple system names are configured, the last one configured overwrites the previous entry.

Use the following syntax to change the system name.

configure system name

The following example shows the system name change.

[ex:/configure system]
A:admin@node-2# info
    name "node-2"
    location "Mt.View, CA, NE corner of FERB 1 Building"
    coordinates "37.390, -122.05500 degrees lat."
    management-interface {
        configuration-mode mixed
    }

A:node-2>config>system# info
#--------------------------------------------------
echo "System Configuration"
#--------------------------------------------------
        name "node-2"
        location "Mt.View, CA, NE corner of FERB 1 Building"
        coordinates "37.390, -122.05500 degrees lat."
        management-interface
            configuration-mode mixed
        exit
...
#--------------------------------------------------

Use the following commands to change the key group on a router interface. The following example shows the inbound and outbound key groups being changed from key group 6 to key group 8.

*A:node-2>config>router# interface demo
*A:node-2>config>router>if# group-encryption
*A:node-2>config>router>if>group-encryp# no encryption-keygroup 6 direction inbound
*A:node-2>config>router>if>group-encryp# encryption-keygroup 8 direction outbound
*A:node-2>config>router>if>group-encryp# encryption-keygroup 8 direction inbound

A:node-2config>router# info 
----------------------------------------------
...
        interface demo
            group-encryption
                encryption-keygroup 8 direction inbound
                encryption-keygroup 8 direction outbound
                exit
            no shutdown
            exit
        exit
...
----------------------------------------------