Archive

These are my study notes regarding IPv6 deployment in SP networks in preparation for the CCDE exam.

Drivers for implementing IPv6

External drivers

SP customers that need access to IPv6 resources

SP customers that need to interconnect their IPv6 sites

SP customers that need to interface with their own customers over iPv6

Internal drivers

Handle problems that may be hard to fix with IPv4 such as large number of devices (cell phones, IP cameras, sensors etc)

Public IPv4 address exhaustion

Private IPv4 address exhaustion

Strategic drivers

Long term expansion plans and service offerings

Preparing for new services and gaining competitive advantage

Infrastructure

SP Core Infrastructure

Native IPv4 core

L2TPv3 for VPNs

MPLS core

MPLS VPNs

My reflection is that most cores would be MPLS enabled, however there are projects such as Terastream in Deutsche Telekom where the entire core is IPv6 enabled and L2TPv3 is used in place of MPLS.

IPv6 in Native IPv4 Environments

Tunnel v6 in v4

Native v6 with dedicated resources

Dual stack

The easiest way to get going with v6 was to tunnel it over v4. The next logical step was to enable v6 but on separate interfaces to not disturb the “real” traffic and to be able to experiment with the protocol. The end goal is dual stack, at least in a non MPLS enabled network.

IPv6 in MPLS environments

6PE

6VPE

6PE is a technology to run IPv6 over an IPv4 enabled MPLS network. 6VPE does the same but with VRFs.

Native IPv6 over Dedicated Data Link

Dedicated data links between core routers

Dedicated data links to IPv6 customers

Connection to an IPv6 IX

Dual stack

All P + PE routers capable of v4 + v6 transport

Either two IGPs or one IGP for both v4 + v6

Requires more memory due to two routing tables

IPv6 multicast natively supported

All IPv6 traffic is routed in global space (no MPLS)

Good for content distribution and global services (Internet)

6PE

IPv6 global connectivity over an IPv4 MPLS core

Transition mechanism (debatable)

PEs are dual stacked and need 6PE configuration

IPv6 reachability exchanged via MPBGP over iBGP sessions

IPv6 packets transported from 6PE to 6PE inside MPLS

The next-hop is an IPv4 mapped IPv6 address such as ::FFFF:1.1.1.1

BGP label assigned for the IPv6 prefix

Bottom label used due to P routers not v6 capable and for load sharing

neighbor send-label is configured under BGP address-family ipv6

6PE is viewed as a transition mechanism but this is arguable, if you transport IPv4 over MPLS, you may want to do the same with IPv6 as well for consistency. Running 6PE means that there is fate sharing between v4 and v6 though, which could mean that an outage may affect both protocols. This could be avoided by running MPLS for IPv4 but v6 natively.

Core network (P routers) left untouched

IPv6 traffic inherits MPLS benefits such as fast-reroute and TE

Incremental deployment possible (upgrade PE routers first)

Each site can be v4-only, v4-VPN-only, v4+v6, v4-VPN+v6 and so on

Scalability concerns due to separate RIB and FIB required per customer

Mostly suitable for SPs with limited amount of PEs

6vPE

Equivalent of VPNv4 but for IPv6

Add VPNv6 address family under MPBGP

Send extended communities for the prefixes under the address family

It is a common misconception for 6PE and 6vPE that traceroutes are not possible, that is however not entirely true. A P router can generate ICMPv6 messages that will follow the LSP to the egress PE and then the ICMPv6 error message is forwarded back to the originator of the traceroute.

Route reflectors for 6PE and 6vPE

Needed to scale BGP full mesh

Dedicated RRs or data path RRs

Either dedicated RR per AF or have multiple AFs per RR

6PE-RR must support IPv6 + label functionality

6vPE-RR must support IPv6 + label and extended communities functionality

PA vs PI

PA advantages

Aggregation towards upstreams

Minimizes Internet routing table size

PA disadvantages

Customer is “locked” with the SP

Renumbering can be painful

Multi-homing and TE problems

The main driver here is if you are going to multi home or not. Renumbering is always painful but at least less so on IPv6 due to being able to advertise multiple IPv6 prefixes through Router Advertisements (RA).

PI advantages

Customers are not “locked” to the SP

Multi homing is straight forward

PI disadvantages

Larger Internet routing table due to lack of efficient aggregation

Memory and CPU needs on BGP speakers

Infrastructure Addressing (LLA vs global)

What type of addresses should be deployed on infrastructure links?

Link Local Address FE80::/10

Non routeable address

Less attack surface

Smaller routing tables

Can converge faster due to smaller RIB/FIB

Less need for iACL at edge of network

Can’t ping links

Can’t traceroute links

May be more complex to manage with NMS

Use global address on loopback for ICMPv6 messages

Will not work with RSVP-TE tunnels

Global only 2000::/3 (current IANA prefix)

Globally routeable

Larger attack surface unless prefix suppression is used

Use uRPF and iACL at edge to protect your links

Easier to manage

It would be interesting to hear if you have seen any deployments with LLA only on infrastructure links. In theory it’s a nice idea but it may corner you in some cases, preventing you from implementing other features that you wish to deploy in your network.

Use /126 or /127 on P2P links which is the equivalent of /30 or /31 on IPv4 links. For loopbacks use /128 prefixes. Always assign addresses from a range so that creating ACLs and iACLs becomes less tedious.

Using another prefix than /64 on an interface will break the following features:

With everything going on in the industry, what is happening to the CCIE program?

I recently watched a webinar on coming updates to the CCIE program. I have also been talking to the CCIE and CCDE program managers which I am proud to call my friends. The certifications are a big part of Cisco’s business, people are afraid that certifications will lose value as Software Defined Networking (SDN) gains more traction in the industry. What is Cisco’s response to the ever changing landscape of networking?

We have already seen Cisco announce the CCNA cloud and CCNA industrial which shows that Cisco follows the market. Will we see a CCIE cloud or CCIE SDN? Doubtful… Why? Because SDN is not a track in itself, it will be part of all tracks… The CCIE DC will be refreshed to include topics like Application Centric Infrastructure (ACI) in the blueprint. When? It’s not official yet which means you have at least 6 months. My guess is that we will see an announcement before this year ends which would mean that the update is around a year away.

CCIE DC is the natural fit for SDN. What about the other tracks? Expect other tracks to get updated as well. The CCIE RS will add the Application Policy Infrastructure Controller Enterprise Module (APIC-EM) for sure and maybe some other topics as well. We will definitely see more of Intelligent WAN (IWAN) in the next update. The CCIE RS was recently bumped to version 5 so I would expect it to take a bit longer than the DC to refresh but it should not be that far out either. I think we can expect more refreshes since the networking is moving at a much faster pace now.

The CCIE SP will include topics such as Segment Routing (SR), Network Function Virtualizaiton (NFV), service chaining, Netconf and YANG and so on. At least that is what I expect. The CCIE SP recently moved to version 4 so I don’t expect it to change just yet but I’m sure Cisco is working on the next refresh already.

A change we have all been waiting to see is that Cisco is going to implement dual monitors in the CCIE lab. This has been discussed for a long time. According to Cisco only 6% of candidates have requested the dual monitors though which shows how important it is to give Cisco feedback. I’m sure more than 6% were bothered by the single screen in the lab. The delay in implementing it has been due to make sure that all lab centers get the same conditions at the same time to not create any debate about the testing environment.

Cisco is also working a lot with exam integrity, they have made changes to the lab delivery system in the backend to prevent people from leaking the material. There is also a much bigger pool of questions and topologies, a lot thanks to the virtualized environment. The Diagnostic (DIAG) section has also been successful in getting the passing rates down to the expected levels. Cisco does a lot of work with statistics to see how their material is received and what makes sense to ask about and if they need to rephrase something or remove it from the topology. They can also do statistical analysis to look for strange behavior from the candidates at the lab. Exam integrity is the #1 focus from my discussions with Cisco.

You have the chance to leave comments when you are taking an exam. I have been lazy in supplying comments in my tests which I will change from now on. From my discussions with the CCIE program managers this is very important feedback for them and their main source of information for how the test is being received.

If you are truly interested in improving the certifications of Cisco and you are already certified, you can apply to become a Subject Matter Expert (SME), SME’s help Cisco in exam development and in picking out the path of the certifications to include new topics and remove old ones.

I still believe in the CCIE program, it’s not going away. I think it would be a huge mistake for people to start diving into SDN without first getting the basic concepts straight. Everything can’t magically go into a fabric and never fail. Read some of Ivan Pepelnjak’s posts to get some perspective on large layer 2 domains. History always repeats itself.