Guest

Cisco Catalyst 6500 Series Switches

Technical Review of IPv6 on the Catalyst 6500 Supervisor 2T White Paper

  • Viewing Options

  • PDF (7.2 MB)
  • Feedback

 

 

 

 

1. Introduction. 4

1.0 Supervisor 2T IPv6 highlights: 4

1.1 Overview of IPv6 Addressing. 4

1.1.1 Link-Local Unicast Addresses. 5

1.1.2 Global Unicast Addresses. 5

1.1.3 Loopback Address. 5

1.1.4 Unspecified Address. 5

1.1.5 Anycast Addresses. 5

1.1.6 Multicast Addresses. 5

1.2 Maximum Transmit Unit 6

2. Unicast Hardware FIB Table. 6

2.1 Load Balancing. 10

2.2 FIB and Adjacency Table Exception. 10

3. Unicast Routing Protocol 11

3.1 IPv6 RIP.. 11

3.2 IPv6 EIGRP.. 12

3.3 OSPFv3. 13

3.4 IS-IS for IPv6. 14

3.5 MP-BGP.. 15

3.6 Static Route. 16

3.6.1 Directly Connected Route. 16

3.6.2 Recursive Static Route. 16

3.6.3 Fully Specified Route. 16

3.6.4 Floating Static Route. 17

3.7 Policy-Based Routing. 17

4. Unicast Reverse Path Forwarding. 17

5. IPv6 Traffic Counters and Statistics. 18

5.1 Data Plane Counters. 18

5.2 Control Plane Counters. 19

5.3 IPv6 Flexible Netflow.. 20

6. First Hop Security. 22

6.1 MAC-Address Binding Entries. 22

6.2 Neighbor Discovery Inspection. 22

6.3 RA Guard. 23

6.4 Tunneling IPv6 over IPv4. 24

6.4.1 Tunnel Entry Node. 25

6.4.2 Tunnel Exit Node. 26

6.4.3 Manually Configured Tunnel 26

6.4.4 IPv6 over IPv4 Generic Route Encapsulation Tunnel 27

6.4.5 Automatic 6to4 Tunnel 27

6.4.6 Intra-Site Automatic Tunnel Addressing Protocol Tunnel 28

6.4.7 Tunnel Considerations. 29

6.5 Tunneling over IPv6. 30

7. VRF-Lite and IPv6. 31

8. IPv6 over MPLS.. 33

8.1 IPv6 Provider Edge over MPLS.. 34

8.2 Ingress 6PE node. 35

8.3 Egress 6PE Node. 36

8.4 Miscellaneous 6PE Features. 37

8.4.1 Class-Based TE Tunnel Selection. 37

8.4.2 6PE Over FRR.. 38

9. IPv6 VPN Provider Edge (6VPE) 38

10. IPv6 Access-lists. 39

11. IPv6 Control Plane Protection. 40

 

 


1. Introduction

The purpose of this document is to provide an in-depth overview of deployment considerations for IPv6 using the Catalyst 6500 platform. The new Supervisor 2T provides capabilities that support next-generation IPv6 networks, and this document will cover some of those capabilities. It is not the intent of this document to provide an IPv6 tutorial or a thorough exploration of IPv6 protocols. For general IPv6 information, refer to the configuration guides at http://www.cisco.com/go/ipv6.

As companies grow in the future, their network needs will also grow. Tomorrow's networks will grow in the IPv6 space. Today's IPv4 networks will have limited future growth. Some companies are already running out of IPv4 address space and are reallocating their existing pool. Internationally outside the US, IPv4 addresses are in even shorter supply. The Catalyst 6500 Supervisor 2T is designed for IPv6 networking. Enhancements for IPv6 were added to Supervisor 2T that are not available on previous generation hardware. There are several drivers in addition to the lack of new IPv4 address space. One of the reasons is to be compliant with US Government certifications in the public sector. Others reasons for IPv6 are to use new IPv6 only applications. IPv6 pilot deployments are not disruptive to existing IPv4 networks. There are many new transition technologies that are available on the Supervisor 2T to make an IPv6 dual stack topology or migration work.

1.0 Supervisor 2T IPv6 highlights:

   Enhanced IPv6 performance up to 30 Mpps

   IPv6 uRPF for up to 16 paths

   Separate IPv6 and IPv4 interface statistics on egress and ingress

   Full IPv6 in IPv4 tunneling support

   IPv6 and IPv4 in IPv6 GRE tunneling support

   Multiprotocol Label Switching (MPLS) encapsulation without recirculation

   Comprehensive first-hop security

   Larger access list capacity

   Stateful switchover for both intra-chassis and inter-chassis redundancy

   Router Advertisement (RA) Guard (First Hop Security)

   Neighbor Discovery (ND) Inspection

   Port-Based Access Control List (PACL)

   Device tracking

1.1 Overview of IPv6 Addressing

An IPv6 address is 128 bits long. It is represented using 32 hexadecimal characters, and is segmented by using a colon (:) every four characters. Even when using this representative form, IPv6 addresses can be difficult to remember, so this representation can be simplified by eliminating the leading 0s within each group. The IPv6 address can be further condensed by removing consecutive all-0 groups of 16- bits between consecutive colons.

The addressing architecture of IPv6 is defined in RFC 3513. Three types of IPv6 addresses have been defined:

   Unicast

   Multicast

   Anycast

IPv6 differs from IPv4 by abandoning the Broadcasts type, which is considered too resource- intensive. Instead, IPv6 adopts a new Anycast type.

IPv6 also introduces the concept of scope in its addressing scheme. Any IPv6 Unicast or Multicast address is defined as either Global or Link-Local in scope. Unlike the IPv4 implementation, each IPv6-configured interface can have more than one IPv6 address. In addition, an IPv6 Unicast address can be assigned to multiple interfaces, if the implementation treats them as one when presented to the Internet layer.

Here are some examples of IPv6 Global and Link-Local addresses:

Global Unicast: 2001:DB8:7654:3210:FEDC:BA98:7654:3210

Global Multicast: FF0E::D

Link-Local Unicast: FE80::224:C4FF:FEDC:D740

Link-Local Multicast: FF02::A

The full list of IPv6 address types is explained below:

1.1.1 Link-Local Unicast Addresses

The scope of this type of address is only the link, and is limited to the link. A node on a different link can possess the same link local address. A router must have one Link-Local address for each of its interfaces. There is no concept of ARP in IPv6 as performed in IPv4; instead, the ARP functionality is achieved in IPv6 through the Neighbor Discovery Protocol (NDP). When a router sends the Neighbor Advertisement Packet, it uses the Link-Local address as the source IP address of the packet. This address is identified by its unique prefix: FE80::0/10.

1.1.2 Global Unicast Addresses

These addresses are globally unique. There is no scope limitation on these addresses, and they can be reached from anywhere. All addresses besides the unspecified, loopback, Multicast, Link-Local Unicast, and Site-Local Unicast Address spaces are Global Unicast addresses.

1.1.3 Loopback Address

The IPv6 loopback address is 0::1/128. According to RFC 3513, the loopback address may be used by any node to send an IPv6 packet to itself, but it can never be assigned to any physical interface. It is treated as having Link-Local scope, and can never be used as the source address in an IPv6 packet. An IPv6 packet with the loopback address as the destination must never be sent outside of a single node, and must never be forwarded by an IPv6 router.

1.1.4 Unspecified Address

The IPv6 Unspecified Address is ::/128. It can never be assigned to any node, nor used as a destination address of an IPv6 packet. It is used in the source address field of any IPv6 packets sent by an initializing host before it learns its own address.

1.1.5 Anycast Addresses

These are allocated from the Unicast Address space. When an address is assigned to more than one interface, typically belonging to different nodes, it is turned into an Anycast Address. A packet sent to an Anycast Address is routed to the nearest interface having this address. These addresses are assigned to router interfaces only. Each IPv6 router interface gets an automatic assigned Anycast Address, and it is used as the subnet-router Anycast Address.

1.1.6 Multicast Addresses

Each of these addresses has the FF00::0/8 prefix, and identifies a group of nodes interested in receiving the same data. A packet with a Multicast Destination Address (DA) is delivered to all members of the group identified by that address. IPv6 Multicast Addresses are also scoped as a way to contain traffic within the intended domain.

1.2 Maximum Transmit Unit

The IPv6 minimum Maximum Transmit Unit (MTU) requirement is 1280 octets. To avoid fragmentation, which can only be performed by the processor, RFC 2460 recommends the use of Path MTU Discovery (PMTUD), a technique used by end nodes to discover the maximum MTU that is usable to reach a specific destination. PMTU works as follows:

1.     The source node sends a frame to the destination, using its local MTU.

2.     If an intermediate router has a smaller MTU size, it will reply back to the source, using an ICMPv6 message (“Type 2 Packet Too Big”) specifying the new MTU value.

3.     The source node resends the frame, using the new MTU value.

4.     The process is repeated by nodes having a smaller MTU, until the packet reaches its destination.

5.     The destination node acknowledges the request establishing the MTU for that path.

The maximum IPv6 packet size supported is 65,536 octets long, limited by the 2 Bytes value of the Payload Length field.

2. Unicast Hardware FIB Table

Contrary to the IPv4 routing implementation on Cisco switches and routers, the IPv6 routing capabilities are not active by default. To activate the IPv6 forwarding features, you need to configure ipv6 unicast-routing. This command transforms the Supervisor in a dual-stack router, capable of forwarding both IPv4 and IPv6 frames.

The Supervisor 2T constructs its IPv6 hardware forwarding table in a similar fashion to IPv4, where each IPv6 routing processes creates its own routing table, referred to as the routing protocol Routing Information Base (RIB). Each routing protocol RIB is compiled into the master IPv6 RIB, using the Administrative Distance as the discriminator. The master IPv6 RIB is then used to populate the IPv6 FIB table, and the IPv6 ND protocol is used to build the adjacency table. Next, those two tables are pushed from the Route Processor (RP) down to the Supervisor PFC4 and through the Ethernet Out-of-Band Channel (EOBC), to all DFC4 present in the system (see Figure 1).

Figure 1.      IPv6 FIB and Adjacency Creation Process

On the PFC4/DFC4, IPv6 addresses share the same FIB and Adjacency table as the IPv4 and MPLS forwarding entries. However, each IPv6 prefix consumes two physical entries in the hardware FIB table. This reduces the total capacity of the FIB (assuming a full load of IPv6 forwarding entries) to half of what it can store with a full complement of IPv4 forwarding entries. For a FIB that is fully-loaded with IPv6 entries, that equates to 128 K total entries for the non-XL version of the PFC4/DFC4 and 512 K total entries for the XL version of the PFC4/DFC4). The following output shows how each protocol gets a set of dedicated 1K entries, and shares the remaining 248 K entries within a PFC4.

Figure 2.      PFC4 Default Hardware FIB Allocation Per Protocol

A certain number of entries of the FIB can also be reserved exclusively for IPv6, using the command “platform hardware cef maximum-routes ipv6 <amount of 1K entries>”.

As with IPv4, each FIB entry can have a different associated status that defines the action to be performed by the hardware. For example, an IPv6 global address is configured on any interface, then that unique address creates two FIB entries. The first entry is a “receive” entry, with a “receive” adjacency that allows traffic destined for that IPv6 address to be processed by the RP. The second entry is an “attached” entry with a “glean” adjacency for the local subnet that will send traffic to the RP, if the host address is not present in the neighbor table. Once the host mac-address is resolved through the NDP process, a third “resolved” entry corresponding to that host’s unique address will be created, and a complete set of rewrite information will be installed in the adjacency table (see Table 1 and Table 2 and 2 for the FIB and adjacencies entry types and actions).

Figure 3.      Global Address Hardware FIB and Adjacency Entry

Table 1.       Types of FIB Entries

FIB Type

Comments

Possible Adjacency Type

Resolved

Immediate next hop is known

Resolved with complete rewrite info

Connected

FIB entry is the interface IPv6 prefix

Glean

Receive

FIB entry is the interface IPv6 address

Receive

Attached

Static or Connected

Glean or Resolved

Table 2.       Types of Adjacency entries

Adjacency Type

Action

Resolved

Rewrite Layer 2 header and forward

Receive

Send to router

Glean

Send to router and trigger NDP resolution

Drop

Drop the packets

As soon as IPv6 is enabled on the system using the command ipv6 unicast-routing, the following routing entry will be installed:

Figure 4.      IPv6 Default Route Entry

This routing entry and its corresponding FIB entry will send all IPv6 Multicast traffic to the RP, which is the Supervisor 2T’s CPU.

There are two additional entries that are not displayed in the routing table but are present in the system:

Figure 5.      IPv6 Link-Local, System Loopback, and Unspecified Route Entry

The entry “FE80::/9” is installed in the RIB to catch all the link local addresses. A corresponding entry in the hardware FIB table will punt to the RP all the traffic hitting this entry to the RP. This directly implies that only one default Link-Local addresses will be maintained in the FIB table. A strict control plane policy must be set to protect the RP from excessive link local address traffic.

Supervisor 2T supports scope enforcement on both source and destination addresses for all packets. If the source IP of the packet has a Link-Local scope, EARL8’s hardware will verify that the ingress scope matches the egress scope by comparing the ingress Link-ID and the egress link-id. Packets will be forwarded only if these two Link-IDs are the same. If the scope differs, EARL8 will generate an exception, causing traffic to be either be dropped or redirected.

Figure 6.      Link Local FIB and Adjacency Entry

The route entry (“::/127”) is installed to catch the unspecified address (“::/128”), as well as the system loopback address (“0::1/128”). Both of these addresses should never appear as destination addresses and are dropped automatically by the Supervisor.

Figure 7.      Unspecified and System Loopback Adjacency

An extra FIB default entry (“::/0”) will also be present if no default route is configured. Traffic hitting this entry will be dropped unless the traffic hits an exception (see Exception Table).

Figure 8.      Default Adjacency for Non-Specified Routes

Figure 9.      Hardware FIB and Adjacency

When performing the forwarding decision, Supervisor 2T benefits from the performance of the Hardware Forwarding Engine available on the PFC4/DFC4. The forwarding process is performed in two passes, allowing features to be applied on ingress (before the rewrite is performed) and on egress (after the rewrite is performed). Each PFC4/DFC4 is capable of performing both passes at a rate of 30 Mpps for IPv6 frames (60 Mpps for IPv4).

2.1 Load Balancing

Load sharing at the FIB levels occurs when a single prefix possesses multiple adjacencies. This is usually achieved by using multiple equal cost paths to the destination. This situation is highly desirable for redundancy purposes. The Supervisor 2T is capable of load-balancing traffic for up to 16 paths for each single prefix (IPv4 or IPv6). Load balancing is performed on a per-flow basis and the following configuration can be used to program the load-balancing hash:

Figure 10.    Load-Sharing Configuration

The load balancing algorithm compresses the IPv6 source and destination addresses to 32-bit values, and uses these values to create the load-balancing hash. The Layer 4 ports are used as-is, if they are part of the load-balancing algorithm.

2.2 FIB and Adjacency Table Exception

An exception syslog event will be generated if the software tries to add a new entry in the hardware FIB table where the table capacity is already exhausted. While this event is active, the software will reprogram existing prefixes in the hardware FIB with the failed ones, to allow a graceful degradation in forwarding. Reprogrammed entries will also have their adjacencies changed to “receive,” and traffic will be redirected to the routing processor. When the hardware FIB table recovers its resources, the software will repopulate the hardware FIB table with the missing prefixes, and the software will generate a syslog message.

If there is no space in the adjacency table to add new entries, the corresponding FIB entry will use a default wild-card entry, and punt all traffic hitting that entry to the routing processor. There, the packets will be forwarded in software.

The following command is usefull to assert the current FIB utilization inside the system and to verify status of the hardware FIB:

Figure 11.    Hardware FIB Utilization and Status

3. Unicast Routing Protocol

Supervisor 2T supports all the IPv6 routing protocols available in IOS. IPv6 routing protocols operate as ships-in-the-night and function independently with their IPv4 counterpart. The function of those protocols is no different to the same protocols in other IOS routers.

Since IPv6 uses the Link-Local address of their next-hop to identify the adjacency, the global IPv6 addresses configured on those interfaces is therefore not relevant.

With release 15.0(1)SY1, all IPv6 routing protocols will support Stateful Switch Over (SSO) and Nonstop Forwarding (NSF). The SSO process maintains all the software and hardware tables, and synchronizes the active and standby supervisors and other tables, including the FIB and adjacency tables. The NSF process allows a router to continue forwarding packets while routing protocols converge, therefore avoiding a route flap on switchover. When an RP failover occurs, the FIB marks installed paths as stale by incrementing a special variable referred to as the epoch. Subsequently, the routing protocols reconverge and populate the RIB and FIB. Once all NSF routing protocols converge, any stale routes held in the FIB are removed. A failsafe timer is required to delete stale routes, in case the routing protocols fail to repopulate those entries in the RIB and FIB.

3.1 IPv6 RIP

Routing Information Protocol (RIP) enhancements for IPv6 are detailed in RFC 2080. Supervisor 2T complies to RFC 2080, including support for IPv6 addresses and prefixes. The all-RIP-routers Multicast group address FF02::9 is the destination address for RIP update messages.

In the Cisco implementation of IPv6 RIP, each IPv6 RIP process uses a text string as a unique identifier, and each process maintains its local RIB. Note that this unique identifier alone cannot be used to separate multiple instances. Instance separation can be achieved using a different Multicast group address or port number for each different process.

By default, IPv6 RIP supports split horizon with poison reverse, and has the same Administrative Distance as its IPv4 counterpart. Features such as distribute list, route-map, and prefix-list are also supported.

The following examples illustrate the handling of IPv6 routes by the Supervisor in a VSS environment. They show the IPv6 local RIB, the IPv6 global RIB, a specific route for the software FIB, and a route for the hardware FIB and adjacencies.

Figure 12.    IPv6 RIP

3.2 IPv6 EIGRP

EIGRP for IPv6 differs slightly from EIGRP IPv4, as it is directly configured on the interfaces over which it runs. This removes the previous required network statement under the IPv6 process definition. It allows EIGRP for IPv6 to be configured without the use of a global IPv6 address, and removes the need to put any type of configuration on a passive interface. Contrary to EIGRP for IPv4, summarization is disabled by default, since IPv6 is classless by design. Split horizon has also been removed from EIGRP for IPV6 to support the multiple IPv6 addresses per interface capabilities.

EIGRP for IPv6 protocol instance requires a router ID before it can start running. Additionally, from Cisco IOS Release 12.2(50)SY, the no shutdown command must be explicitly configured when enabling the EIGRP IPv6 router process in order for the process to start.

EIGRP for IPv6 provides route filtering using the distribute-list prefix-list command. Use of the route-map command is not supported for route filtering with a distribute list.

EIGRP for IPv6 still relies on MD5 for authentication, and support for IPsec will be provided in a later release.

Figure 13.    Useful IPv6 EIGRP

3.3 OSPFv3

OSPFv3 has been defined in RFC 2740. The basic mechanics of the protocol (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. Neighboring routers are still identified by a 32-bit router ID, but several changes from OSPFv2 for IPv4 exist to accommodate the specificity of IPv6. Those changes include:

   New Link LSAs announce the IPv6 Link-Local address of the neighbors, and inform these neighbors of a list of IPv6 addresses and options associated with the link

   Intra-Area Prefix LSAs carry all IPv6 prefix information within an area (this was performed by the router LSA and network LSA under OSPFv2)

   Inter-Area Prefix LSAs advertise internal networks to routers in other areas (this was performed by the network summary or type 3 LSAs under OSPFv2)

   Inter-Area Router LSAs advertise the location of the Autonomous System Boundary Router (this was performed by the ASBR summary or type 4 LSAs under OSPFv2)

OSPFv3 now runs on a per-link basis, instead of on a per-IP-subnet basis, and neighbors always advertised their link-local addresses. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6’s Authentication Header (AH) and Encapsulating Security Payload (ESP). Authentication and Encryption for OSPF is not yet supported in 12.2(50)SY, but will be supported in a later release.

OSPFv3 supports the capability to run multiple instances of the routing process on a single link. An 8-bit instance ID is used to discriminate between instances, and it can be use as an alternative to authentication in a shared media environment.

All of the OSPFv2 optional capabilities, including on-demand circuit support, NSSA areas, and the Multicast extensions to OSPF (MOSPF) are also supported in OSPFv3.

Figure 14.    Useful IPv6 OSPFv3 Commands

3.4 IS-IS for IPv6

IS-IS support for IPv6 does not introduce any major changes. A new protocol-id (0x8E) and two new TLVs, IPv6_Reachability (0xEC) and IPv6_Interface_Address (0x8E), are used by neighboring routers to signal their capability to support IPv6. By default, IS-IS runs a single topology for both IPv4 and IPv6 and it applies the same metric for both protocols.

Multi Topology IS-IS is an enhancement that will allows IS-IS to run independent topologies per set of address families, and will be supported in a later release.

Figure 15.    IPv6 IS-IS

3.5 MP-BGP

Multiprotocol BGP is a set of extensions that allow BGP4 to carry routing information for multiple network layer protocol. MP-BGP is widely used to carry MPLS labels, and RFC 2545 extends MP-BGP to IPv6 prefixes.

To distinguish between different network layer protocols, MP-BGP adds an Address Family Identifier (AFI) and a Subsequent Address Family Identifier (SAFI) to specific attributes. IPv6 Unicast will have a two-tuple (AFI:2, SAFI:1), IPv6 Multicast will have (AFI:2, SAFI:2), etc. During the initial OPEN message of protocol negotiation, MP-BGP peers negotiate capabilities, and each peer could end up with many AFI/SAFI negotiated capabilities.

MP-BGP works the same way as BGP4 for any particular AFI/SAFI. In fact, the protocol used to establish the neighbor session is independent of the AFI/SAFI being advertised. For example, one single BGP session can transport multiple address families.

Figure 16.    IPv6 MP-BGP

Figure 17.    MP-BGP Configuration Example

3.6 Static Route

Static routes are manually configured, and define an explicit path between two networking devices. There are different types of IPv6 static routes.

3.6.1 Directly Connected Route

In this type of static route, only the output interface is specified. The destination is assumed to be directly attached to this interface, so the packet destination is used as the next hop address.

3.6.2 Recursive Static Route

Only the next hop is specified in this route. The output interface is derived from the next hop by performing an extra lookup in the existing RIB. It is not normally useful to manually configure a self-recursive static route, although it is not prohibited.

3.6.3 Fully Specified Route

In this route, both the output interface and next hop are specified. The next hop must be directly attached to the specified output interface. Adding an output interface is required when using a link local address as a next hop, because this address is derived from the MAC address. Since the MAC address of the switch is identical on all its interfaces, it is likely that two different interfaces share the same link local address on the neighbor switch. This form of static route is also used when the output interface is a VLAN interface with multiple neighbors.

3.6.4 Floating Static Route

This static route is used to back up dynamic routes learned through configured routing protocols. A floating static route is configured with a higher administrative distance than the dynamic routing protocol it is backing up. As a result, the dynamic route learned through the routing protocol is always preferred to the floating static route.

All static routes are supported in hardware with Supervisor 2T.

3.7 Policy-Based Routing

Policy-based routing (PBR) conditionally overrides routing results determined by the RIB. The conditions are evaluated in an access-control list (ACL), and routing and some other actions are determined in a route map. In the context of a policy route map, an ACL permit entry means the traffic should be policy routed, and an ACL deny entry means skipping the current sequence and evaluating the next sequence. If the result of the last sequence entry is a deny, the switch will skip the policy routing for these packets, and submit them to regular RIB forwarding.

Although Supervisor 2T does not currently supports IPv6 PBR, the feature will be supported in hardware with version 15.0(2)SY, but with certain restrictions. The PFC4/DFC4 provides the capability to match on the packet length and DSCP value and to set the either the interface or the next hop address for policy result.

Tracking option, as well as a setting the DSCP value, are not supported by the PFC4/DFC4.

4. Unicast Reverse Path Forwarding

Unicast Reverse Path Forwarding (uRPF) is an Internet security tool that can be used to defeat some Denial of Service (DoS) attacks that uses IPv6 source address spoofing. The basic function of uRPF is to perform network ingress filtering and only allow packets that have an IPv6 source address that can be traced back to the interface on which those packets were received.

Supervisor 2T supports three uRPF modes: strict mode, loose mode, and VRF mode. In strict mode, the packet must be received on the interface that the router would use to send the return packet. In loose mode, the source address only needs to have a matching prefix in the routing table. If a default route is present in the FIB, Supervisor 2T supports the “allow-default” option, which grants the use of the default route in the source verification process. (Unicast RPF in VRF mode is covered later in this document.)

IPv6 uRPF is configurable on a per-interface basis, and is totally independent of uRPF for IPv4. Supervisor 2T will perform the uRPF verification in hardware even if there are multiple equal-cost “best” return paths in the FIB (up to 16 paths are supported in hardware).

IPv6 uRPF and security access-lists can appear simultaneously on the same interface. In this case, the hardware will evaluate the ACL before evaluating the RPF. If both checks are successful, the packet will be forwarded.

ACL can also be configured to condition the uFPF check. If an ACL is specified, it is applied only when a packet fails the RPF strict check. The ACL is either used to override an RPF drop decision for special cases, or to help enable logging of spoofed IP packets, which is useful for tracking the source of a DoS attack.

Since the FIB TCAM contains only a default link local address (see Unicast hardware FIB table section), packets with link-local source address can be dropped by the RPF check.

The following example illustrates the configuration and hardware configuration verification for both strict and loose mode uRPF on the switch:

Figure 18.    Strict and Loose uRPF

The following example shows how the administrator can verify the RPF reachability of a specific prefix. If the RPF check fails for specific flows, an entry in a special purpose table, called the exception table, is incremented.

Figure 19.    uRPF Statistics and uRPF Verification for Specific Prefix

A more complex example will only permit traffic with IPv6 source address 2011:ff::0/64 to go through, even if it failed the RPF check. However, it will notify the administrator on a regular basis.

Figure 20.    uRPF with Access List Logging

5. IPv6 Traffic Counters and Statistics

5.1 Data Plane Counters

Supervisor 2T allows for the accounting of IPv4, IPv6 and MPLS traffic separately. Those additional counters are maintained by the PFC4/DFC4. As a consequence, they are only updated by traffic being switched through the switch, not by traffic that is destined to the switch’s own interfaces.

Loopback and Tunnel interfaces do not have those separate counters available.

Supervisor 2T also allows for the collection of statistics on a per-prefix basis. This feature is disabled by default, and up to 64 prefixes can be configured for statistics collection.

Figure 21.    Data Plane Counters

Supervisor 2T also includes the support for the revised IP-MIB that includes statistics collection for IPv6. In the example shown below, a SNMP walk is performed on the system wide IPv6 statistics table, and filtered to display only the incoming traffic statistics.

Figure 22.    SNMP Data Plane Objects

5.2 Control Plane Counters

Supervisor 2T collects statistics for traffic that needs to be processed by the routing processor (RP). Those statistics are collected for all interfaces by default and divided into multiple protocol bucket. Once ipv6 traffic interface-statistics is configured, those statistics are collected and can be cleared on a per-interface basis.

Figure 23.    Control Plane Counters

The revised IP-FORWARD-MIB is also supported. In the following example, a SNMP walk is performed on the routing table, and filtered to display only the routes learned by OSPFv3 (The Unix program sed is used to display a more user-friendly output by removing “:00”). Note that the table is indexed by IPv6 destination prefixes, subnet mask (e.g.:2002:1::/64), and next hop address.

Figure 24.    SNMP Control Plane Objects

5.3 IPv6 Flexible Netflow

One of the many enhancements that Supervisor 2T offers from its predecessor is the support for flexible Netflow. This powerful monitoring framework allows the administrator to select which information on what interface needs to be collected.

Compared to Supervisor 720, which allowed Netflow policies to be configured only in input, Supervisor 2T allows policy to be applied to interfaces and sub-interfaces on input and output.

Supervisor 2T allows the administrator to collect the followings IPv6 fields: destination address, source address, protocol type, DSCP, precedence, and traffic-class.

Supervisor 2T will be able to support up to one million Netflow entries for both IPv4 and IPv6, Supervisor 720 consumed two Netflow entries for each IPv6 entry, effectively dividing the capacity for IPv6 by two. This limitation does not apply to Supervisor 2T.

In order to use Netflow, four configuration steps need to be performed:

1.     Define a Flow Record: This definition consists of fields that trigger the creation of a new entry every time their value changes (match statement), and fields that accumulate collected data for their respective entry (collect statement).

2.     Define a Flow Export: These statements contain the definitions of the external host that will accumulate the data collected.

3.     Define a Flow Monitor: This configuration associates the defined record to the defined export. This allows the association of multiple export destinations to a single record.

4.     Apply the Flow Monitor: This is applied to an interface for a specific direction.

If the switch is dual stack, both IPv4 and IPv6 information can be collected within the same record or separately.

Figure 25.    Flexible Netflow Configuration Example

Each Flow Monitor has an associated cache that is maintained on each PFC4/DFC4. This cache can be viewed at the command prompt.

Figure 26.    Flexible Netflow Cache

6. First Hop Security

The first hop is strategically positioned in front of the end-system, and, as such, is particularly exposed to a numbers of threats. While a few of these threats directly address the first hop, many others exploit link operations vulnerabilities. Attackers can insert themselves as a rogue first hop, and deceive end systems. Many of these threats are not new with IPv6, even though they may take advantage of IPv6 specific protocol flaws. For instance, an attacker could prevent end-systems from initializing their addresses, prompt them to build illegal addresses, announce illegal default gateway, and more.

While first hop is vulnerable, it is also placed in a strategic physical location to protect end-systems before the attack reach them, as well as prevent end-systems from entering local domains with malicious intentions. A large part of the mitigation mechanisms that can be put in place at the first hop deal with some deep knowledge of addressing allocation, and the capability to bind the knowledge at Layer 3 with the knowledge at Layer 2.

6.1 MAC-Address Binding Entries

One way of preventing rogue hosts overflowing the router neighbor cache is to limit the maximum amount of IPv6 addresses that can be bound to a single MAC-address. Without this feature, a malicious host can potentially create a DoS by saturating a portion of the memory on the first hop router. The maximum number of IPv6 addresses that can be bound to a single MAC-address can be configured globally, on a per-MAC/per-port or per-vlan basis using the ipv6 neighbor binding max-entries <Number of entries> <mac-limit>|<port-limit> |<vlan-limit> command.

6.2 Neighbor Discovery Inspection

NDP runs on top of IPv6 and ICMPv6, and its messages encompass a subset of ICMP messages. They replace and enhance the functions performed by ARP on IPv4. The security features concentrates only on a subset of the NDP messages (RS, RA, NS, NA, and REDIR). See Table 3.

Table 3.       ICMPv6 Message Type

ICMP Type

Message Description

Role

Reference

133

Router Solicitation (RS)

Prompt routers for sending RA quickly

RFC 4861

134

Router Advertisement (RA)

Advertise:

  Default router
  On-link prefixes
  Reachable prefixes
  Operation parameters

RFC 4861

135

Neighbor Solicitation (NS)

  Request the link-layer address of a target node
  Part of the Duplicate Address Detection process (DAD)

RFC 4861

136

Neighbor Advertisement (NA)

  Responds to NS
  Advertise link-layer address changes

RFC 4861

137

Redirect Message (REDIR)

Inform hosts of a better first-hop router

RFC 4861

6.3 RA Guard

RAs are special ICMP messages sent to the Multicast address FF02::1. Those messages are used to notify hosts that a router is present on the link and inform them about the routing prefix (or prefixes) for that segment.

Rogue RAs can be generated maliciously or unintentionally by unauthorized or improperly configured routers connected to VLANs.

RA Guard is configured on Layer 2 interfaces. It examines incoming RAs and decides whether to switch or block them, based solely on information found in the message or in the Layer 2 device configuration. Typical information available in the frames received, useful for RA validation, is:

   Port on which the frame was received

   IPv6 source address

   Prefix list

The following configuration information created on the Layer 2 device can be made available to RA-Guard, to validate against the information found in the received RA frame:

   Allowed/Disallowed ports for receiving RA-guard messages

   Allowed/Disallowed IP source addresses of RA-sender

   Allowed Prefix list and Prefix ranges

   Control Router Preference

Once the Layer 2 device has validated the content of the RA frame against the configuration, it switches the RA to destination, whether Unicast or Multicast. Otherwise, the RA is dropped.

Supervisor 2T implements RA guard at the PFC4/DFC4 level. This allows for a high rate of RA inspection without CPU intervention.

When configuring RA guard, the Layer 2 port needs to be assigned to one of the following defined roles:

1.     “Host” device or devices attached to the port are hosts, and therefore all the inbound RA/Redirect messages are blocked.

2.     “Router” device or devices attached to the port are routers. In this role, all messages (RS/RA/Redirect) are allowed on the port.

3.     “Monitor” will not allow inbound RA/Redirect on the port, but multicast Router Solicitation messages are switched to the other ports of the VLAN.

4.     “Switch” will not allow inbound RA/Redirect

The following example illustrates a RA guard policy applied on a trunk interface, and allows only router R3 connected to a remote switch to announce one global route. The routing scope is defined by the prefix list, whereas the router is defined by an access-list using the Link-Local address.

6.4 Tunneling IPv6 over IPv4

As the Internet transitions to IPv6, the existing IPv4 routing infrastructure can remain functional and can be used to carry IPv6 traffic. To facilitate coexistence and interoperability of the current IPv4 world with the IPv6 protocol, hosts and routers can tunnel IPv6 packets over the IPv4 topology by encapsulating them within IPv4 packets.

The end nodes of an IPv6 over IPv4 tunnel must be dual stack systems. Based on how the destination IPv4 address is derived, IPv6 in IPv4 tunnels are either manually configured or dynamic. The destination IPv4 address of a Manually Configured Tunnel (MCT) is configured on the tunnel interface, whereas in a dynamic tunnel, the destination IPv4 address is dynamically extracted from the packet’s IPv6 destination address.

The underlying mechanisms for tunneling are:

   The entry node of the tunnel creates an encapsulating IPv4 header and transmits the encapsulated packet

   The network transports the encapsulated packet using IPv4 routing protocols

   The exit node of the tunnel receives the encapsulated packet, reassembles the packet if needed, removes the IPv4 header, and processes the received IPv6 packet

Supervisor 2T supports the following types of IPv6 in IPv4 tunnels:

   IPv6 over IPv4 (IPv6IP)

   IPv6 using Generic Routing Encapsulation (GRE) header over IPv4

   IPv4-compatible (deprecated by IETF and not covered here)

   6to4

   Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

IPv6IP and GRE tunnel are MCT tunnels. IPv6IP tunnels are formed by adding an IPv6 payload directly after the IPv4 header (using Protocol ID 47). This form of tunnel is more efficient than using a GRE header but restrict the tunneled traffic to IPv6 only. IPv4GRE tunnels (Protocol ID 41) are a more generic type of tunnel that can be used to transport IPv6 or other type of traffic. The GRE header adds a 20 Bytes overhead, but allows CLNS, for example (the transport protocol of ISIS), to be carried inside the tunnel.

Figure 27 shows the encapsulation/de-capsulation of IPv6 packets in IPv4 headers through a static tunnel.

Figure 27.    MCT Encapsulation/Decapsulation Process

To inspect tunnel traffic, the following rules apply:

   The IPv4 protocol type field must be set to 41 or 47

   The IPv4 source address identifies the encapsulating end-point of the tunnel, so it is one of the IPv4 addresses of the encapsulating node

   The IPv4 destination address identifies the decapsulating end-point of the tunnel, so it is one of the IPv4 addresses of the decapsulating node

   The time to live (TTL) and type of service (TOS) of the IPv4 tunnel header are set at the source endpoint

6.4.1 Tunnel Entry Node

When Supervisor 2T acts as an encapsulating end-point of a tunnel (see Figure 28), the initial FIB lookup of the IPv6 packet does not return the final result, but points to a tunnel encapsulation rewrite entry. The rewrite entry contains the IPv4 header information required to encapsulate the packet. This encapsulated IPv4 packet is then recirculated back to the forwarding engine. On the second pass, the forwarding engine performs an IPv4 FIB lookup. The final rewrite entry contains the MAC-address rewrite information required to forward the packet to the next hop and to its destination IPv4 address. As mentioned earlier, the encapsulating IPv4 header uses a protocol value of 41 or 47 to identify itself as an IPv6-in-IPv4 packet.

Figure 28.    Tunnel Encapsulating Process

6.4.2 Tunnel Exit Node

At the decapsulation point of a tunnel, the IP destination address of an incoming tunneled packet is typically one of the switch’s IP addresses. Packets with one of the router’s IP addresses as the destination address can be either tunneled or non-tunneled packets. Non-tunneled packets are destined for the router and need to be processed by the software. Tunneled packets need to be decapsulated and the inner packets are to be forwarded. Since tunnel traffic cannot be identified by their destination address only, a three-tuple (source address, destination address, and protocol type) is required to identify traffic from a MCT, and a pair (destination address and protocol type) is required to identify an automatic tunnel. FIB lookup based on the destination address only is not enough to determine the input tunnel interface.

For this reason, an egress ACL is used to fully identify the tunnel interface where the packets arrive. The main differences between normal IPv4 forwarding and forwarding of tunnel exit point packets is that FIB lookup provides a fixed adjacency pointer for all packets destined to its own IP addresses.

The egress ACL of all packets destined to the router’s IP address will determine if the packet has reached the exit point of a tunnel and should be decapsulated. The packet is then recirculated back to the forwarding engine for a second lookup on the inner IPv6 packet’s destination address. In most cases, the IPv6 FIB lookup results in a Layer 2 rewrite entry, which triggers the MAC rewrite and forwards the packet out of the system. (Figure 29)

Figure 29.    Tunnel Decapsulation Process

6.4.3 Manually Configured Tunnel

A manually configured tunnel (MCT) provides a permanently established connection between two IPv6 domains over an IPv4 backbone. The primary use is for regular communication between two edge routers, between an end system and an edge router, or for connection to remote IPv6 networks.

The following example configures a manual IPv6 tunnel between SUP2T-1 and SUP2T- 2. The tunnel interface 0 for both switches is manually configured with a global IPv6 address and an IPv4 address. The tunnel destination is also manually configured, and should be one of the IP addresses of the other end-point of the tunnel. The tunnel mode “ipv6ip” specifies that this is a manually configured IPv6 over IPv4 tunnel (Protocol ID: 47).

Figure 30.    Configuration of IPv6IP Tunnel

6.4.4 IPv6 over IPv4 Generic Route Encapsulation Tunnel

IPv6 traffic can be carried over IPv4 Generic Route Encapsulation (GRE) tunnels using the standard GRE tunneling technique, which is designed to provide the services necessary to implement any standard point-to-point encapsulation scheme. The GRE header contains a protocol field that identifies the encapsulated protocol. GRE tunnels permit IS-IS or IPv6 to be specified as tunneled protocol, which allows both IS-IS and IPv6 traffic to run over the same tunnel.

The following example shows an IPv6 over IPv4 GRE tunnel between SUP2T-1 and SUP2T- 2. Tunnel interface 0 for both switches is manually configured with a global IPv6 address and an IPv4 address. The tunnel destination is also manually configured, and should be one of the IP addresses of the other end-point of the tunnel. The tunnel mode “gre ip” specifies that GRE IPv4 as the encapsulating protocol for the tunnel.

Figure 31.    Configuration of IPv4 GRE Tunnel

6.4.5 Automatic 6to4 Tunnel

6to4 is a mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup (RFC 3056). These tunnels are multipoint tunnels because the IPv4 address embedded in the IPv6 addresses is used to find the other end of the tunnel automatically.

An automatic 6to4 tunnel may be configured on a border-router in an isolated IPv6 network, which creates a tunnel on a per-packet basis to a border-router or a host in another IPv6 network. The tunnel destination is determined by the IPv4 address of the border-router extracted from the IPv6 address that starts with the prefix 2002::/16, where the format is as follows:

Figure 32.    6to4 Address Format

Following the embedded IPv4 address are 16 bits that can be used to number networks within the site. A 6to4 router designates a router which implements 6to4 tunneling. An IPv6 site which has a 6to4 router is called a 6to4 site. Each 6to4 site has at least one valid, globally unique 32-bit IPv4 address assigned to the border router. The site can then use the 6to4 address prefix for its IPv6 networks. Note that the endpoint of a 6to4 tunnel does not have to be the same as the destination address of the packet being tunneled, since the IPv4 address is embedded in the prefix of the IPv6 address.

The following example configures a 6to4 tunnel between SUP2T-1 and SUP2T- 2. An interface on both switches is configured with a global IPv6 address and an IPv4 address. Tunnel interface 0 for both switches is configured without an IPv4 or IPv6 address, because the IPv4 or IPv6 addresses on the interface of both routers are used to construct a tunnel source address. A tunnel destination address is not specified on either router, because the destination address is automatically constructed on a per-packet basis. Tunnel mode is set to “ipv6ip 6to4” to specify a 6to4 tunnel. An IPv6 static route for network 2002::/16 to tunnel interface 0 are configured on both routers.

Figure 33.    Configuration of 6to4 tunnel

6.4.6 Intra-Site Automatic Tunnel Addressing Protocol Tunnel

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) defines an IPv6-in-IPv4 tunneling mechanism that allows dual-stack nodes not directly connected to an IPv6 router to automatically tunnel packets to the IPv6 next-hop address through IPv4. ISATAP mechanisms use a EUI-64 based interface identifier format that embeds an IPv4 address in the IPv6 address. The embedded IPv4 address can be a globally assigned or a private IPv4 address. Contrary to the 6to4 tunnel method, ISATAP does not require special IPv6 network prefixes, both local and global IPv6 Unicast prefixes can be used with the new interface identifier format.

The new interface identifier format embeds the IPv4 address in the lower 32 bits, followed by 0x5EFE (see Figure 34)

Figure 34.    ISATAP Address Format

Figure 35.    ISATAP Tunnel Address Example

In the following example, an ISATAP tunnel is configured between SUP2T-1 and SUP2T-2. The tunnel source command must point to an interface with an IPv4 address configured. Tunnel mode is specified as “ipv6ip isatap”. The ISATAP IPv6 address and prefixes to be advertised are configured using IPv6 address command. Note that the IPv6 address has to be configured as a EUI-64 address, since the last 32 bits in the interface identifier is used as the IPv4 destination address.

6.4.7 Tunnel Considerations

Endpoint Interfaces

A new technology called Logical Interface (LIF) mapping, embedded in the forwarding engine of Supervisor 2T, allows multiple tunnels to share their endpoints interfaces. This was not possible with the previous Supervisor 720 and Supervisor 32 family of Supervisors. (For more information on LIF, please refer to the Supervisor 2T Architecture Document.)

MTU

Supervisor 2T does not support per-packet dynamic path MTU checking, based on the IPv6 destination address. Therefore, the MTU of an IPv6 tunnel must be programmed with a value comprised of a value between the IPv6 minimum MTU of 1280 Bytes and the MTU of the output interface minus the encapsulation size.

If the original IPv6 packet exceeds the path MTU, the packet is discarded and an ICMPv6 “Packet Too Big” message is sent to the source address of the original packet.

If the original IPv6 packet is equal or smaller than the path MTU, the original packet is encapsulated. The resulting tunneled packet may be subsequently fragmented if it exceeds the MTU of the physical output interface. The fragmentation process will be performed by the software.

If the encapsulated traffic is fragmented at the output physical interface or within the tunnel path, the fragments will not be reassembled by the forwarding engine. Instead, they will be directed to the control plane for reassembly.

Forwarding Rate

The forwarding rate of packets which need to be tunnel encapsulated or decapsulated is half of the normal forwarding rate of IPv6 Unicast packets (15Mpps). This is due to the recirculation process that needs to take place at both tunnel endpoints (see above). Encapsulated traffic is forwarded at IPv4 rate (60Mpps)

TOS/Traffic Class

The tunnel interface command tunnel tos allows setting the TOS value in the encapsulating IPv4 header of a tunneled packet. The values can be in the range of 0-255. If the command is not issued on the tunnel interface, the TOS/Traffic class value of the tunnel header is copied from the inner header. The capability to separate QoS values between IPv4 and IPv6 was not possible with previous Supervisors and offers additional flexibility to redefine QoS policies independently in IPv6.

6.5 Tunneling over IPv6

Supervisor 2T supports only two MCT tunnels in hardware: IPv6 and IPv6 GRE.

   IPv6 encapsulation: The original packet is encapsulated using an IPv6 header at the tunnel entry point and de-capsulated at the tunnel exit point.

   GRE over IPv6: At the tunnel entry point, the original packet is first encapsulated with a GRE header (protocol id: 0x2F). The resulting GRE frame is then encapsulated using an IPv6 header, the reverse operation occurs at the tunnel exit point.

Only the IPv6 GRE tunnel allows multiple protocols to be encapsulated (see Figure 37 for configuration example).

Like other tunnel technologies, the Supervisor 2T will require a packet recirculation at both tunnel endpoints.

Figure 36.    IPv6 GRE Tunnel

Figure 37.    IPv6 GRE Tunnel Configuration Example

7. VRF-Lite and IPv6

VPN Routing and Forwarding (VRF) instances are used to create multiple instances of the routing table on the same routing device. This feature is usually associated with MPLS, and is used by service provider to separate the traffic of multiple customers.

VRF-Lite is VRF without MPLS. In a borderless network, VRF-Lite allows the administrator to create multiple routing instances on the same device, achieving the primary goal of separating traffic without deploying a complete MPLS solution. The VRF itself can be seen as an extra key in the FIB table allowing the isolation of entries that have different or identical IPv6 addresses. Addresses and routes that are not part of a specific VRF are often referred to as “global” addresses and have a default VRF associated with them.

Since it does not use MPLS, VRF-Lite does not take the propagation of the VRF into consideration. This task needs to be achieved manually, either on a hop-by-hop basis using 802.1q trunks or end-to-end using tunnels.

When using a hop-by-hop method to propagate the VRF, the administrator usually creates a sub-interface and associate that interface with a specific VRF on the connection between neighboring switches. Thanks to the Logical Interface (LIF) mapping, the hop-by-hop propagation is facilitated by allowing the configuration of the same VLAN Identification on two different primary interfaces. (For more information on LIF, please refer to the “Supervisor 2T Architecture” document.) In the topology below, SUP2T-2 was assigned VLAN10 to the interfaces connecting to SUP2T-1 and SUP2T-2 for VRF-1.

Figure 38.    Hop-by-Hop VRF Propagation

Figure 39.    Hop-by-Hop VRF Configuration Example

Supervisor 2T allows for the tunnel endpoints to reside in a VRF. This permit the connection of multiple IPv6 VRFs across an IPv4 network. The following example illustrates the possibility of terminating the two tunnels on the same loopback interface, where the first tunnel is a GRE tunnel encapsulating both IPv4 and IPv6 traffic, and the second tunnel carries IPv6 traffic only.

Figure 40.    IPv6 VRF Tunnel Configuration Example

Figure 41.    Dual Stack GRE Tunnel FIB Table

8. IPv6 over MPLS

MPLS is an infrastructure technology used by service providers and large enterprises. It allows for easy integration of services, such as Virtual Private Network (VPN), Traffic Engineering (TE), Quality of Service (QoS), and fast convergence (FRR or Fast ReRoute). The MPLS terminology defines three types of nodes; the Provider Edge (PE), which sits at the border of the MPLS network, facing the Customer Edge (CE) on one side and the Providers (P) node on the other. The P nodes may also be referred to as a Label Switching Router (LSR), as they base their forwarding decision on the MPLS label, rather than the IPv4 header.

As a packet enters the MPLS network at the ingress PE, it is label-switched up to the egress PE. The path followed by a specific packet is called a Label Switching Path (LSP), and is set up by a control-plane protocol, such as Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP). Multiple labels can be stacked inside the original frames and each of those labels is a qualifier that can be imposed by protocols or manual configuration. The routing decision within the LSP operates generally on the topmost label and is refered to as label swaping.(Please refer to the book MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard for detailed information on MPLS.)

Supervisor 2T provides all the features necessary to support MPLS switching at both the PE and P level, including Layer 2 services such as Ethernet over MPLS (EoMPLS) and Virtual Private LAN Service (VPLS). (The support of these features is discussed in more depth in the “Supervisor 2T and Network Virtualization” white paper.)

8.1 IPv6 Provider Edge over MPLS

IPv6 Provider Edge (6PE) is an alternative solution to the traditional IPv6 over IPv4 tunnel. It provides the same benefit of IPv6 over IPv4 tunnel, but removes the tunnel’s scalability and overhead limitations, while adding the benefit of MPLS technologies (QoS, TE, FRR, etc.).

Transporting IPv6 over an MPLS network only requires the PE routers to be dual stack, and the core routers do not need any additional modifications. The IPv6 traffic received by the ingress PE is transported to the destination IPv6 network, using the existing MPLS/IPv4 infrastructure. In the MPLS core, all the control-plane protocols, including LDP and IGPs such as OSPF and IS-IS that are used to exchange route updates and establish connectivity remain on IPv4. On the data plane side, the P routers in the MPLS domain are unaware of switching IPv6 packets, as they exclusively use the MPLS labels to switch packets.

Figure 42.    6PE Topology Example

Figure 43.    6PE Configuration Example

8.2 Ingress 6PE node

The following example illustrates the LSP that now exists between the 2 MP-iBGP neighbors. On the ingress PE, outgoing traffic will be imposed with Label 29 by the forwarding engine, in addition to the regular Layer 2 rewrite. This label has been assigned by LDP and is present in the MPLS forwarding table which is the label switching equivalent of the routing table).This label is now pushed during the rewrite operation in the hardware adjacency table.

Figure 44.    6PE Labels in the MPLS forwarding Table and the CEF Table.

The IPv6 prefixes advertised by SUP2T-2 over MP-iBGP are reachable through next hop 5.5.5.5 as shown below. The next hop (::FFFF:5.5.5.5) is the IPv4-mapped IPv6 address built from the IPv4 address of the LSP endpoint. It identifies the LSP to be used to reach the advertised prefixes.

Figure 45.    6PE MP-BGP Next Hop

The MP-iBGP process will install an IPv6 recursive route that points, in our example, to the IPv4 loopback of the MP-iBGP neighbor. The MP-iBGP process will also provide an additional label (Label 20) that fully defines the IPv6 LSP. The forwarding engine will thus push two labels to the original frame during the rewrite operation.

Figure 46.    6PE and IGP Label Push

An IPv6 FIB entry, with the destination IPv6 prefix, is installed in the hardware FIB table. The corresponding adjacency entry is programmed to push two MPLS labels (L1 and L2), and also to provide the MAC rewrite information of the output interface (illustrated below).

Figure 47.    6PE Label Imposition

8.3 Egress 6PE Node

At the egress 6PE node, two operations will occurred simultaneously, The aggregate BGP label will be looked up and popped, the corresponding adjacency table will contain the Virtual Private VLAN identifier that the packet needs to be forwarded to. In the case of 6PE, this adjacency points to the global table, since this label does not identify any VPN. A separate FIB lookup is performed using the IPv6 header. The corresponding adjacency entry provides the egress interface and the MAC rewrite information.

Figure 48.    Egress 6PE label

Figure 49.    Egress 6PE Label Disposition

It is important to note that, contrary to tunnels, 6PE does not require any type of recirculation at both ingress and egress PE, which provide better bandwidth.

8.4 Miscellaneous 6PE Features

8.4.1 Class-Based TE Tunnel Selection

The idea of Class-Based MPLS TE Tunnel Selection (CBTS) is to allows different parallel TE tunnel between the same head end and tail end to each carry a different subset of class of service (CoS). The tunnels are created by adding an extra label to the stack, Supervisor 2T supports the imposition of up to five labels in a single pass through the forwarding engine. See the configuration example below:

Figure 50.    MPLS TE Tunnel Configuration Example

CBTS will dynamically route IPv6 packets into those different parallel tunnels. Each of these tunnels is assigned an EXP value, and the CBTS selection is based on the EXP value.

8.4.2 6PE Over FRR

MPLS Traffic Engineering uses MPLS label switch path tunnel to forward traffic between pairs of routers along the path. If a tunnel becomes disconnected because of a link or node failure along its path, the failure will be reported to the tunnel head, which will then attempt to reestablish an alternate path to the tunnel end. Unfortunately, the delay in the reestablishment of the tunnel may be substantial, and cause service interruption for time-sensitive applications such as voice and video. As a result, a FRR (Fast Reroute) mechanism is used to improve the delay in the tunnel reestablishment.

The basic theory of FRR is to have a redundancy link or node, so that if a link or node fails, the traffic can be rerouted to the alternate link or node in a very short period time, and will minimize service interruption for those applications.

9. IPv6 VPN Provider Edge (6VPE)

6VPE uses MP-BGP to provide Virtual Private Network (VPN) extension over IPv4 or IPv6-based MPLS core. The principle is similar to 6PE, with the advantage of segregating IPv6 networks in different VPNs.

Figure 51.    6VPE Configuration Example

From the hardware FIB perspective, 6VPE works in a similar fashion as 6PE. At the ingress PE router, the forwarding engine does an IPv6 lookup in the VRF table and imposes two labels, the outer IGP/LDP label and the inner label (VPN label) advertised by MP-BGP. At the egress router, the forwarding engine pops the VPN label (as explained in the 6PE section) and does the lookup based on inner IPv6 destination address in the corresponding VRF table (instead of the global table as in the 6PE case).

The PFC4 VRF table supports up to 4K IPv6 VPNs.

Figure 52.    6VPE MP-BGP Routes

In addition to the declared MP-BGP routes, each VRF mirrors all the default routes contains in the global CEF table.

Figure 53.    6VPE VRF Routing Table

10. IPv6 Access-lists

In order to perform classification in the hardware, the Supervisor 2T is equipped with Ternary Content Addressable Memory (TCAM).

The IPv6 ACL TCAM supports both standard and extended IPv6 ACLs. An IPV6 Standard ACL supports both source and destination addresses. This is different from an IPV4 standard ACL, which supports the source address only. IPv6 Extended ACLs support the IPV6 source and destination address, along with upper layer protocol information, which includes:

   TCP and UDP protocol type

   Source and destination port numbers

   TCP flags, including SYN, ACK, FIN, PSH, URG, RST, and Established (ACK and RST)

   ICMPv6 packets with source or destination address and ICMP type

The ACL process is performed in two steps. During the first step, the ACL assessment that provides a result (permit or deny) is performed in the second step, and the statistics for the ACL are incremented, as illustrated in Figure 54.

Statistics for packets that match the IPv6 ACL in hardware are aggregated for all line cards, and can be displayed using the show ipv6 access-list command. In Supervisor 720 and Supervisor 32, this process implied bridging the packet to the RP. A maximum of 4K counters are supported for the entire system.

The TCAM ACLs can store up to 256K entries when the system is functioning in PFC4XL mode, but requires two entries for each IPv6 ACL Entry (ACE). The TCAM space is shared between both the QoS classification process and the security classification process. The Default allocation reserve one bank of TCAM for the QoS process, which leaves up to 96K IPv6 ACL entries in the system (192K for IPv4) for IPv6 ACL. With 288 bits available for each IPv6 ACE, and an internal compression mechanism, manual IPv6 address compression for EUI-64 is no longer required. A total of 208 Logical Operator Units (LOUs) are also available for those extended ACLs that are configured using logical operators (gt, lt, and eq keywords).

Figure 54.    ACL Block Diagram

Supervisor 2T includes support for Port-Based Access Control List (PACL), which provides the ability to perform access control on specific Layer 2 ports for IPv6 traffic. PACLs are supported on ingress direction only on access and trunk ports.

11. IPv6 Control Plane Protection

Protecting the CPU resources from misconfiguration, protocol error, defective equipment, and malicious applications is one of the most daunting tasks of the network administrator. If the control plane interface is over protected, control plane performance and reconvergence can be affected. If it is in adequately protected, CPU utilization can inadvertently spike and affect network operation.

Like Supervisor 720 and Supervisor 32, Supervisor 2T comes with two control plane protection mechanisms:

   Rate Limiter

   Control Plane Policing

Rate Limiter is used to control how the Supervisor will react to network events. Control Plane Policing (CoPP) can be seen as a QoS Policy applied to the control plane interface.

For example, when the destination address of a packet is not present in the ND cache, the forwarding engine punts the packet to the control plane to perform the address resolution.

The CEF GLEAN rate limiter will limit the amount of traffic that requires address resolution. This rate limiter is active by default and limits the amount of ND generated by the CPU to 1000 requests per second.

Unlike Supervisor 720 and Supervisor 32, QoS capabilities of Supervisor 2T are activated by default, Supervisor 2T comes with a preconfigured Control Plane Policy which follows the Modular QoS CLI (MQC) configuration scheme. For example, the following policy controls the rate at which several NDP packets can be forwarded to the Control Plane Processor. The policy is constructed using four steps:

1.     Access-group definition which list identifies the packet that will be subject to the policer.

2.     Class-map definition which enrolls one or several access-list definitions.

3.     Policy map definition which is preconfigured with the keyword policy-default-autocopp and contains all the class-map definition.

The policy map defines the rate that will be applied to each class using the “leaky bucket: algorithm; the set-discard-class-transmit keyword sets the discard-class internal label to a specified value (in this case, 48) and transmits the packet to the processor queue. The internal DSCP value set by the policer controls the priority at which the CPU will process the specific class of messages when congestion within the processor queue is occurring.

4.     The policy map is applied in the ingress direction to the control plane interface.

Extensive accounting is provided on a per-class basis within the CoPP policy.