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 autonomous system (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 ASes 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 only be implemented to reduce the interior border gateway protocol (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). 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 AS number. The AS numbers 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. Confederation configuration 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 for which target networks proxy ARP is attempted and prefix lists that determine for which source hosts proxy ARP is attempted.

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

See the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide for information about DHCP relay and support, as well as configuration examples.

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 auto-configuration of addresses. The scalability of multicast routing is improved by adding a scope field to multicast addresses. Also, a type of address called an anycast address is defined that 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 options in the future.

• flow labeling capability

  The capability to enable the labeling of packets belonging to 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.

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.

Use the following command to control the ECMP-like spraying for BGP-labeled IPv6 packets (6PE) and BGP-labeled IPv4 unicast routes resolving to tunnels in TTM, where the maximum number of ECMP router represents the maximum number of RSVP and SR-TE tunnels in the set representing equal-cost paths to the BGP next hop.

configure router ecmp

Use the following command to configure weighted ECMP behavior, where the load-balancing weight of the tunnel is considered in the packet spraying behavior.

configure router bgp next-hop-resolution weighted-ecmp

Weighted ECMP is disabled by default.

Strict weighted load-balancing is enabled by configuring weighted-ecmp strict in global routing mode. The strict enforcement for a load balancing weight is valid for both a base router instance and for a VPRN instance.

• With strict enforcement, a weight must be configured on each interface within a wECMP interface bundle before the interface is taken into wECMP operation.

• Without weighted-ecmp strict enforcement enabled, and if one or more interfaces within a wECMP interface bundle does not have a load-balancing-weight weight configured, then the wECMP load-balancing falls back to classic ECMP operation and equally sprays data-plane traffic across the available interfaces.

• A special case of weighted-ecmp strict is when none of the available paths or next-hops have a load-balancing-weight value associated. Then, the load-balancing falls back to the classic ECMP.

• weighted-ecmp strict is enabled in the router global context for IS-IS, OSPF, and OSPFv3. Other routing technologies follow classic weighted-ecmp operation.

Use the following command to configure CBF over IGP shortcuts.

configure router mpls class-forwarding-policy

All FCs are mapped to set 1 as soon as the policy is created. The user can make changes to the mapping of FCs as required. An FC, which is not added to the class-forwarding policy, is therefore always mapped to set 1. At most, an FC can be mapped to a single forwarding set. One or more FCs can map to the same set. Use the following command to configure the FC to a set other than set 1.

configure router class-forwarding-policy fc forwarding-set

The user can indicate the initial default set by including the default-set command option. Use the following command to configure the default-set command option.

configure router mpls class-forwarding-policy default-set

The default forwarding set is used to forward packets of any FC in cases where all LSPs of the forwarding set the FC maps to become operationally down. The router uses the user-configured default set as the initial default set. Otherwise, the router elects the lowest numbered set as the default forwarding set in a class-forwarding policy. When the last LSP in a default forwarding set goes into an operationally down state, the router designates the next lowest-numbered set as the new default forwarding set.

A mapping to a class-forwarding policy and set is added to the existing CBF configuration of an RSVP-TE or SR-TE LSP or to an LSP template. Use the following commands to perform this mapping function.

configure router mpls lsp class-forwarding forwarding-set policy set
configure router mpls lsp-template class-forwarding forwarding-set policy set

An MPLS LSP can map only to a single class-forwarding policy and forwarding set. Multiple LSPs can map to the same policy and set. If they form an ECMP set, from the IGP shortcut perspective, packets of the FCs mapped to this set are sprayed over these LSPs based on a modulo operation of the output of the hash routine on the packet's headers and the number of LSPs in the set.

When a BGP IPv4 or IPv6 prefix is resolved to a BGP next-hop, consisting of up to 64 resolved next-hops (LSPs and IP links), the default behavior of the datapath is to spray the packets over the entire ECMP set using a modulo operation of the number of resolved next-hops in the ECMP set and the output of the hash on the packet header fields.

Both the CBF feature in LDP-over-IGPv4 shortcuts and this CBF feature over IGP IPv4 shortcuts make use of the CBF class-forwarding policy. IGP always passes the CBF information populated by MPLS for each LSP used as a tunnel next-hop by an IGP prefix. The new CBF information is checked for consistency. If more than a single class-forwarding policy exists in the tunnel next-hops of a IGP prefix, IGP removes the new CBF information from all the corresponding tunnels and the behavior is as if there were no CBF info.

Use the following command to enable the CBF feature.

configure router class-forwarding

When the CBF feature is enabled, each application (BGP, CPM), when looking up a prefix in RTM, finds up to 64 IP and tunnel next-hops. This lookup is split in two subsets:

• Subset 1— tunnel next-hops with new CBF information (FCs mapped to this LSP, default LSP (true/false), CBF Policy ID>0, Set ID>0). This information is usable by both LDP and other applications.

• Subset 2— tunnel-next-hops with no CBF information and IP next-hops. Usable by all applications, except that LDP uses tunnel next-hops only.

The BGP application performs a lookup in RTM for a prefix matching each BGP next-hop of a prefix. The BGP application selects tunnels belonging to the class-forwarding sets in Subset 1 and for each BGP next-hop of a prefix. The remaining tunnels, with no CBF configuration and the IP next-hops, are still programmed to IOM. However, BGP and the datapath uses them only when all the class-forwarding sets are not available as described in the information that follows.

SR OS implements a hierarchical ECMP architecture for BGP prefixes in the datapath. The first level is the ECMP at the BGP next-hop level. The second level is ECMP at the resolved next-hop (IP or tunnel next-hop) level. The CBF feature is independently applied to the set of resolved tunnel next-hops of each BGP next-hop of a prefix. The user must make sure that the sets of LSPs that are used as IGP shortcuts to reach each of the BGP next-hops have the appropriate FC mappings.

The following procedures are enforced in the CBF feature:

• The tunnels in the full next-hop ECMP set, with set size greater or equal to 1 and less than or equal to 64, can use MPLS LSPs that terminate on multiple endpoints (BGP next-hop itself or otherwise) to reach the next-hop of a BGP prefix. The existing ECMP tunnel and IP next-hop selection behavior, when resolving a prefix over IGP shortcuts, continues to be used.

• If no LSP among the full ECMP set of a BGP next-hop has a class-forwarding policy configuration assigned, then the set is considered inconsistent from a CBF perspective. No CBF-related information is programmed in IOM and regular ECMP spraying over the full set occurs.

• If only a single class-forwarding policy is referenced by one or more LSPs in the full ECMP set of a BGP next-hop, the full set is considered consistent from a CBF perspective, and the class-forwarding policy is used to spray packets of each FC over the LSPs within each forwarding set. As a result of this processing, only the LSPs that have been selected for forwarding traffic are programmed in IOM with CBF information. The remaining LSPs and IP next-hops of the BGP next-hop, are also programmed in IOM but without any CBF information associated and, therefore, is not used for CBF.

• If multiple class-forwarding policies are referenced by LSPs in the full ECMP set of a BGP next-hop, the set is considered inconsistent from a CBF perspective. No CBF related information is programmed in IOM and regular ECMP spraying over the full set occurs.

The following describes the fallback behavior in datapath of the CBF feature:

• An FC, for which all LSPs in the forwarding set are operationally down, has its packets forwarded over the default forwarding set. The default forwarding set is either the initial default forwarding set configured by the user or the lowest numbered set in the class-forwarding policy that has one or more LSPs in the operationally UP state. If the initial or subsequently elected default forwarding set has all its LSPs operationally down, the next lower numbered forwarding set, which has at least one LSP in the operationally up state, is elected as the default forwarding set.

• If all LSPs of all forwarding sets become operationally down, the router resumes regular ECMP spraying on the remaining LSPs and IP next-hops in the full ECMP set.

• Whenever the first LSP in a forwarding set becomes operationally UP, the router triggers the re-election of the default set and selects this set as the new default set, if it is the initial default set, otherwise, it selects lowest numbered set.

The following are the limitations of the CBF feature.

• CBF applies to packets of IPv4 and IPv6 BGP prefixes only. CBF does not apply to IGP prefixes and static route prefixes resolved over IGP IPv4 shortcuts. The latter are forwarded using regular ECMP over the entire set of up to 64 tunnel next-hops.

• CPM originated packets on the router, including the control plane and OAM packets, are forwarded over a single LSP from the set of LSPs the packet's FC is mapped to, as per the CBF configuration. The CPM, however, only maintains a maximum of 64 next-hops for a specified destination prefix. Therefore, if there are multiple BGP next-hops for a prefix, CPM selects 64 tunnel next-hops by cycling over the BGP next-hops in ascending order. Then, the first LSP in the first set ID that the FC of the packet maps to is selected to forward the packet.

  Furthermore, the CBF information consistency check, the CBF default set determination, and the CBF set failover procedures are applied to this set of 64 tunnel next-hops.

  The user can configure the SGT-QoS feature to change the DSCP and FC of CPM-originated packets of a specific control plane protocol to select an LSP from a different set ID. This configuration allows, for instance, the forwarding of BGP Keep-Alive packets over an LSP of the same set ID as that of the data plane packets of the BGP prefixes destined for the same BGP next-hop.

• Weighted ECMP, at the transport tunnel level of BGP prefixes over IGP shortcuts, and the CBF feature on a per-BGP next-hop basis are mutually exclusive. Specifically, if the user enables both weighted ECMP and CBF, weighted ECMP applies as long as all the LSPs used as tunnel next-hops to reach the BGP next-hop of a prefix have a user-configured weight. Otherwise, the CBF feature applies as per the procedures described in Feature behavior.

  Use the following commands to configure weighted ECMP and class-forwarding respectively.

  configure router weighted-ecmp
  configure router class-forwarding

When a packet of a BGP IPv4 or IPv6 prefix is received, the datapath uses the FC that the packet was classified into to look up the forwarding set ID. The datapath then performs a modulo operation on the tunnel next-hops of this set ID, to select the one next-hop for forwarding the packet. Therefore, packets matching an FC are only sprayed over the ECMP tunnel-next-hops of the set ID this FC maps to.

Both the BGP or CPM application and IOM use the same algorithm for failover and default class-forwarding set determination, as described in Feature behavior and illustrated in Example configuration and default CBF set election.

If MPLS deletes an LSP from a specified set ID, the IOM handles failover within the same set ID. The IOM reprograms the datapath to spray packets of the impacted FCs over the remaining tunnel next-hops of the set ID.

Similarly, the IOM handles failover between class-forwarding sets when MPLS deletes the last LSP in a set ID. The IOM reprograms the datapath to spray packets of the impacted FCs over the tunnel next-hops of the failover set ID. In both cases, the failover does not make use of the uniform failover procedure; however, if an LSP activated its FRR backup path, it remains in the set ID and continues to forward traffic of the mapped FCs.

Finally, BGP updates the set IDs, used to reach a BGP next-hop, any time IGP updates the information in the RTM.

Assume the following user configuration:

• The FC mapping to the sets and the default forwarding set election are illustrated in Default forwarding set election.

• All sets and RSVP-TE LSPs outside of the three class-forwarding sets are up initially.

• Set 1 is elected as the default class-forwarding set (because the user did not configure an initial default set).

• If All LSPs in Set 1 go operationally down, Set 2 is elected as the default class-forwarding set.

• If Set 2 subsequently goes down, Set 3 is elected as the default class-forwarding set.

• If Set 3 subsequently goes down, then packets of BGP prefixes are ECMP sprayed over the remaining non-CBF RSVP-TE LSPs.

• If Set 2 comes back up, then Set 2 is elected as the default class-forwarding set.

The following example shows class-forwarding as true, which enables the CBF feature for BGP and CPM traffic. IGP shortcut is enabled in this IS-IS instance with both families IPv4 and IPv6 resolving to RSVP-TE LSPs. Four LSPs exist in set 1, set 2, and set 3. The final LSP configuration has no CBF options for a total of 64 LSPs to BB1.

[ex:/configure router "Base"]
A:admin@node-2# info
    class-forwarding true
    interface "system" {
        ipv4 {
            primary {
                address 192.0.2.194
                prefix-length 32
            }
        }
        ipv6 {
            address 3ffe::a14:194 {
                prefix-length 128
             }
        }
    }
    interface "toSim199" {
        port 1/1/1
        ipv4 {
            primary {
                address 10.202.5.194
                prefix-length 24
            }
            secondary 10.101.0.194 {
                prefix-length 32
            }
        }
        ipv6 {
            address 2001:db8:a0b:12f0::1 {
                prefix-length 64
             }
        }
    }
    interface "toSim213" {
        port 1/1/2
        ipv4 {
            primary {
                address 10.202.4.194
                prefix-length 24
            }
        }
    }
    interface "toSim219" {
        port 1/1/3
        ipv4 {
            primary {
                address 10.202.8.194
                prefix-length 24
            }
        }
    }
[ex:/configure router "Base"]
A:admin@node-2# info
...
    isis 0 {
       igp-shortcut {
            tunnel-next-hop {
                family ipv4 {
                    resolution filter
                    resolution-filter {
                        rsvp true
                    }
                }
                family ipv6 {
                    resolution filter
                    resolution-filter {
                        rsvp true
                    }
                }
            }
        }
    }
[ex:/configure router "Base" mpls]
A:admin@node-2# info
    cspf-on-loose-hop true
    interface "system" {
    }
    interface "toSim199" {
    }
    interface "toSim213" {
        admin-group ["olive"]
    }
    interface "toSim219" {
    }
    class-forwarding-policy "cbf1" {
        fc be {
            forwarding-set 1
        }
        fc l2 {
            forwarding-set 1
        }
        fc af {
            forwarding-set 2
        }
        fc l1 {
            forwarding-set 2
        }
        fc h2 {
            forwarding-set 2
        }
        fc ef {
            forwarding-set 3
        }
        fc h1 {
            forwarding-set 3
        }
        fc nc {
            forwarding-set 3
        }
    }
    path "empty" {
    }
    lsp "RSVP-TE_LSP-BB1-SET1" {
        type p2p-rsvp
        to 192.1.2.194
        class-forwarding {
            forwarding-set {
                policy "cbf1"
                set 1
            }
        }
        primary "empty" {
        }
    }
    lsp "RSVP-TE_LSP-BB1-SET2" {
        type p2p-rsvp
        to 192.1.2.194
        class-forwarding {
            forwarding-set {
                policy "cbf1"
                set 2
            }
        }
        primary "empty" {
        }
    }
    lsp "RSVP-TE_LSP-BB1-SET3" {
        type p2p-rsvp
        to 192.1.2.194
        class-forwarding {
            forwarding-set {
                policy "cbf1"
                set 3
            }
        }
        primary "empty" {
        }
    }
    lsp "RSVP-TE_LSP-B1[1..52]" {
        type p2p-rsvp
        to 192.1.2.194
        primary "empty" {
        }
    }

A:node-2>config>router# info
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        interface "system"
            address 192.0.2.194/32
            ipv6
                address 3ffe::a14:194/128
            exit
        exit
        interface "toSim199"
            address 10.202.5.194/24
            secondary 10.101.0.194/32
            port 1/1/1
            ipv6
                address 2001:db8:a0b:12f0::1/64
            exit
        exit
        interface "toSim213"
            address 10.202.4.194/24
            port 1/1/2
        exit
        interface "toSim219"
            address 10.202.8.194/24
            port 1/1/3
        exit
        class-forwarding
   // Enables CBF feature for BGP and CPM traffic

A:node-2>config>router>isis# info
----------------------------------------------
            igp-shortcut  
//  Enables IGP shortcut in this ISIS instance with both families IPv4 and IPv6 
resolving to RSVP-TE LSPs
                tunnel-next-hop
                    family ipv4
                        resolution filter
                        resolution-filter
                            rsvp
                        exit
                    exit
                    family ipv6
                        resolution filter
                        resolution-filter
                            rsvp
                        exit
                    exit
                exit
            exit
----------------------------------------------
A:node-2>config>router>mpls# info
----------------------------------------------
            class-forwarding-policy cbf1
                fc be forwarding-set 1
                fc l2 forwarding-set 1
                fc af forwarding-set 2
                fc l1 forwarding-set 2
                fc h2 forwarding-set 2
                fc ef forwarding-set 3
                fc h1 forwarding-set 3
                fc nc forwarding-set 3
            cspf-on-loose-hop
            exit
            interface "system"
            exit
            interface "toSim199"
            exit
            interface "toSim213"
                admin-group "olive"
            exit
            interface "toSim219"
            exit
            path "empty"
            exit
            lsp "RSVP-TE_LSP-BB1-SET1[1..4]"  // Four LSPs in Set1
                to 192.0.2.194/32
                cspf
                class-forwarding
                    forwarding-set policy ‟cbf1” set 1
                exit
                primary "empty"
                exit
            exit
            lsp "RSVP-TE_LSP-BB1-SET2[1..4]"  // Four LSPs in Set2
                to 192.0.2.194/32
                cspf
                class-forwarding
                    forwarding-set policy ‟cbf1” set 2
                exit
                primary "empty"
                exit
            exit
            lsp "RSVP-TE_LSP-BB1-SET3[1..4]"  // Four LSPs in Set3
                to 192.0.2.194/32
                cspf
                class-forwarding
                    forwarding-set policy ‟cbf1” set 3
                exit
                primary "empty"
                exit
            exit
            lsp "RSVP-TE_LSP-BB1[1..52]"  //
 Other LSP configuration with no CBF options for a total of 64 LSPs to BB1
                to 192.0.2.194/32
                cspf
                primary "empty"
                exit
            exit
----------------------------------------------

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 7450 ESS, 7750 SR, 7950 XRS, and VSR 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.

The user defines a subnet for the termination of GRE packets by applying the gre-termination command to a numbered network IP interface, including a loopback interface. Use the following command to configure GRE termination.

configure router interface gre-termination

The following rules apply to termination of IP-over-GRE and MPLS-over-GRE on a user-defined subnet.

• The termination of MPLS-over-GRE on the system interface address can be performed concurrently and extends to terminating IP-over-GRE packets as well.

• A single GRE termination subnet is permitted per router. If the user attempts to configure another subnet on another interface, the command is rejected.

• The GRE termination subnet length can be of maximum size of /16.

• The subnet of the primary IPv4 address of the numbered loopback interface or the numbered network IP interface is used as the GRE termination subnet.

• When the GRE termination subnet is enabled on a numbered network IP interface, the packet can be received from the interface itself and any other network IP interface as long as the target IPv4 termination subnet is reachable.

• The feature can terminate packets with the base 4-byte header {C=0, K=0, S=0} or with the 8-byte header which includes the Key field {C=0, K=1, S=0}. Any other GRE header setting results in the packet being dropped.

• For routers in the network to forward MPLS-over-GRE or IP-over-GRE packets to this router, the prefix of the GRE subnet must be advertised in IGP or BGP. This is performed by adding the interface to IGP or BGP. Alternatively, a static route is added to the other routers.

• The GRE termination subnet is not supported with the following interface types. If these interface types are configured, the configuration of the gre-termination command option is rejected:

  • unnumbered network IP interface

  • IES interface

  • VPRN interface

  • CSC VPRN interface

• The configuration of the gre-termination command option is also rejected when applied to the system interface, as the system interface supports the termination of MPLS-over-GRE packet on its /32 subnet with no explicit configuration.

• This feature introduces full support of LER and LSR roles for the packet after the GRE encapsulation is removed, regardless if the GRE termination was on the system interface address or the GRE termination subnet.

• In an LSR role, this feature sprays the decapsulated packets over LAG and ECMP links by attempting a hash on the SA/DA and Layer 4 ports of the inner IP header if the payload below the label stack is IPv4 or IPv6. Otherwise, a hash is performed on the SA/DA of the outer IPv4 header of the GRE encapsulation.

When a GRE packet is received over any network IP interface, the router checks if destination address matches the system interface address (exact match) or the GRE termination subnet (Longest Prefix Match). The router then processes the packet according to the following criteria:

• If a match exists and the GRE Protocol Type field indicates an MPLS payload, continue processing the MPLS label stack as normal. This includes:

  • Pop one or more labels and forward to CPM if a MPLS exception exists (TTL expiry, RA label, 127/8 destination address in underlying IP packet).

  • Pop one or more labels and look up the packet in the FIB or in a local service context. The router operates as an egress LER.

  • Pop one or more labels and swap a label out to the outgoing interface with NHLFE encapsulation pushed on the packet. The router operates as an LSR.

  • When the incoming label is swapped to an implicit-null label, the user is able to remark the DSCP field of the exposed IPv4 or IPv6 packet on egress of the datapath.

• If a match exists and the GRE Protocol Type field indicates an IPv4 or an IPv6 payload, continue processing in the pipeline as an IP packet and forward out based on FIB lookup.

• If a match exists and the GRE Protocol Type field indicates a Bridged Ethernet payload, drop the packet. To enable the feature to terminate the Bridged Ethernet payload, ensure that the termination subnet for that feature does not overlap with the GRE termination subnet of MPLS-over-GRE and IP-over-GRE termination.

• If a match exists and the GRE protocol Type field is set to any other payload value, drop the packet.

• If a match exists and the packet is not dropped, the application of ACL filter on the incoming interface matches against the inner (payload) header of the received GRE-encapsulated packet.

• If a match does not exist, continue processing in the pipeline as an IPv4 packet. In this case, the application of ACL filter on the incoming interface matches against the outer IPv4 header of the received GRE-encapsulated packet.

This feature supports GRE/IPv4 encapsulation when the payload is MPLS, IPv4, or IPv6.

All MPLS egress LER and LSR features associated with the processed label are supported.

The router sets the Ethertype field value of the outgoing packet according to the following criteria.

• If the swapped label is not the Bottom-of-Stack label, Ethertype is set to MPLS value.

• If the swapped label is the Bottom-of-Stack label and the outgoing label is not implicit-null, Ethertype is set to MPLS value.

• If the swapped label is the Bottom-of-Stack label and the outgoing label is implicit-null, Ethertype is set to IPv4 or IPv6 value when the first nibble of the exposed IP packet is 4 or 6 respectively. If the first nibble value is neither 4 nor 6, the packet is dropped.

The router sets the TTL of the outgoing packet as per the behavior of a PHP LSR:

• The TTL of a forwarded IP packet is set to MIN (MPLS_TTL-1, IP_TTL), where MPLS_TTL refers to the TTL in the outermost label in the popped stack and IP_TTL refers to the TTL in the exposed IP header.

• The TTL of a forwarded MPLS packet is set to MIN(MPLS_TTL-1, INNER_MPLS_TTL), where MPLS_TTL refers to the TTL in the outermost label in the popped stack and INNER_MPLS_TTL refers to the TTL in the exposed label.

The router sets the Ethertype field value of the outgoing packet to IPv4 or IPv6 value when the GRE protocol field value in the incoming packet is IPv4 or IPv6 respectively.

The router checks and decrements the TTL field of the inner IPv4 or IPv6 header and ignores the TTL of the outer IPv4 header.

When the router removes the GRE encapsulation, pops one or more labels including the Bottom-of-Stack (BoS) label, it acts as a LER. The exposed packet are forwarded in the global routing table or in a service context. The LAG/ECMP hashing of the packet when forwarded follow the procedures of that specific forwarding context. see ‟Traffic Load Balancing Options” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide.

When the router removes the GRE encapsulation, pops one or more labels and then swaps a label, it acts as an LSR. The LSR hashing for packets of a MPLS-over-GRE SDP or tunnel terminating on the GRE subnet follows a new procedure which is enabled automatically and overrides the LSR hashing command option enabled on the incoming network IP interface. Use the following command to configure the LSR hashing command option.

configure router interface load-balancing lsr-load-balancing

For more details, see LSR Hashing of MPLS-over-GRE Encapsulated Packet in section Changing Default Per Flow Hashing Inputs of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide.

The following example shows the configuration of a public interface.

[ex:/configure service ies "100"]
A:admin@node-2# info
    admin-state enable
    customer "1"
    interface "int-gre-tunnel-public" {
        sap pxc-1.b:100 {
            description "Public Tunnel PXC SAP"
        }
        ipv4 {
            primary {
                address 192.110.1.1
                prefix-length 30
            }
        }
    }

A:node-2>config>service# info
----------------------------------------------
        ies 100 name "100" customer 1 create
            no shutdown
            interface "int-gre-tunnel-public" create
                address 192.110.1.1/30
                sap pxc-1.b:100 create //Public interface
                    description "Public Tunnel PXC SAP"
                exit
            exit
            no shutdown
----------------------------------------------

[ex:/configure service]
A:admin@node-2# info
    customer "200" {
    }
    vprn "200" {
        customer "200"
        bgp-ipvpn {
            mpls {
                admin-state enable
                route-distinguisher "64496:1"
                vrf-target {
                    community "target:64496:1"
                }
            }
        }
        interface "int-gre-tunnel-private" {
            tunnel true
            ip-mtu 1476
            ipv4 {
                addresses {
                    address 10.1.1.1 {
                        prefix-length 30
                    }
                }
            }
            sap pxc.1.a:200 {
                ip-tunnel "gre-tunnel-1" {
                    admin-state enable
                    delivery-service "100"
                    remote-ip-address 192.120.1.1
                    backup-remote-ip-address 192.120.1.2
                    local-ip-address 192.110.1.2
                    gre-header {
                        admin-state enable
                        key {
                            admin-state enable
                            send 123
                            receive 123
                        }
                    }
                }
            }
        }
        static-routes {
            route 172.16.1.1/24 route-type unicast {
                next-hop "10.1.1.2" {
                }
            }
        }
    }

A:node-2>config>service# info
----------------------------------------------
        customer 200 name "200" create
        exit
        vprn 200 name "200" customer 200 create
            no shutdown
            interface "int-gre-tunnel-private" tunnel create
                address 10.1.1.1/30
                ip-mtu 1476
                sap pxc.1.a:200 create
                    ip-tunnel "gre-tunnel-1" create
                        gre-header send-key 123 receive-key 123
                        source 192.110.1.2
                        remote-ip 192.120.1.1
                        backup-remote-ip 192.120.1.2
                        delivery-service name "100"
                        no shutdown
                    exit
                exit
            exit
            static-route-entry 172.16.1.1/24
                next-hop 10.1.1.2
                    no shutdown
                exit
            exit
            bgp-ipvpn
                mpls
                    route-distinguisher 64496:1
                    vrf-target target:64496:1
                    no shutdown
                exit
            exit
        exit
----------------------------------------------

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 7450 ESS, 7750 SR, 7950 XRS, and VSR 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.

In a Nokia router, an interface is a logical named entity. An interface is created by specifying an interface name under the configure router context. This is the global router configuration context where objects like static routes are defined. An IP interface name can be up to 32 alphanumeric characters, must start with a letter, and is case-sensitive; for example, the interface name ‟1.1.1.1” is not allowed, but ‟int-1.1.1.1” is allowed.

If the interface name already exists, the router changes the context to maintain that IP interface. If the interface name already exists within another service ID or is an IP interface defined within the configure router commands, an error occurs, and the context does not change to that IP interface.

To create an interface, the following basic configuration tasks must be performed:

• Assign a name to the interface.

• Associate an IP address with the interface.

• Associate the interface with a network interface or the system interface.

• Configure appropriate routing protocols.

A system interface and network interface must be configured.

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 7750 SR and 7450 ESS 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
...
#------------------------------------------

The following sections describe basic system 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 command 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
...
----------------------------------------------