Posts Tagged ‘ccie sp’
I’m in the process of finalizing new updates to the Service Provider CCIE racks and publishing the new hardware specification. I’m going to be using the new hardware specification for my London SPv3 Bootcamp in two weeks before releasing it to the public. I’ve already replaced the two CE 2600XMs with four 1841′s running IOS 15.1T for the CEs. This allows for additional IPv6 VRF support along with many other newer features on the CE devices. Also having 2 extra CE devices is nice.
For VPLS we now support large scale VPLS implementation by adding a four port OC3 POS card to each SDR. This is great for the bootcamps so that students can interconnect their racks. Also if someone wants rent two racks they will be able to interconnect them to test larger scale scenarios. As far as interconnections between the racks I’ve added in a backbone GigE connection between the racks so we can do BGP peering.
From my understanding we are the only training company that offers SPv3 rack rentals and workbooks much less VPLS support. Also I’m fairly sure we’re the only training company that’s offering a dedicated rack now for each SPv3 bootcamp student. I can’t verify this since I don’t have a rearview mirror but this is just what our customers are telling me
Below is the new POS interconnection diagram.
After my London SP bootcamp in three weeks I’ll publish the new hardware specification along with finalizing our new graded Service Provider Mock Labs. These new graded SP mock labs will use two full SP racks which means 4 IOS XR SDRs, 12 7200VXRs, 4 ME3400 switches, and 8 1841′s for CE devices. These labs will be fun!
Introducing the changes
As you have probably heard already, Cisco announced changes to the CCIE SP blueprint, that go effective as of April 17th 2011. There is some good news and some bad news. On positive side, the new blueprint looks really good technology-wise – just look at the detailed checklist here: https://learningnetwork.cisco.com/docs/DOC-10145 and see the mentioning of VPLS, Carrier Ethernet, FRR and other features. On the opposite side, the equipment requirements for the new blueprint put extensive toll on an average CCIE candidate’s budget (unless you work for a big Cisco partner and can “borrow” equipment for your lab). The new test will build upon XR12000, 7600, 7200 routers and ME3400 switches – for more information look here: https://learningnetwork.cisco.com/docs/DOC-10121. One problem is that Cisco did not yet specify the detailed hardware requirements, e.g. linecards for the routers. The other problem is that “simulator” mentioned in the hardware specification. There is no doubt that Cisco has software emulators for IOS XR routers and 7600 devices, but it is not clear whether those will be available to general public.
Based on the above observations, we are still considering the impact of changes on INE product offering. While our product line will definitely stay there, we will not officially announce any changes to our hardware specification while we wait for more information from Cisco regarding the hardware and availability of simulator software. It is our priority to keep the CCIE training affordable to the students, and thus minimizing the rack hardware cost is very important.
The purpose of this blog post is to give you a brief overview of M-LSPs, the motivation behind this technology and demonstrate some practical examples. We start with Multicast VPNs and then give an overview of the M-LSP implementations based on M-LDP and RSVP-TE extensions. The practical example is based on the recently added RSVP-TE signaling for establishing P2MP LSPs. All demostrations coud be replicated using the widely available Dynamips hardware emulator. The reader is assumed to have solid understanding of MPLS technologies, including LDP, RSVP-TE, MPLS/BGP VPNs and Multicast VPNs.
Multicast Domains Model
For years, the most popular solution for transporting multicast VPN traffic was using native IP multicast in SP core coupled with dynamic multipoint IP tunneling to isolate customer traffic. Every VPN would be allocated a separate MDT (Multicast Distribution Tree) or domain mapped to a core multicast group. Regular IP multicast routing is then used for forwarding, using PIM signaling in core. Notice, that the core network has to be multicast enabled in Multicast Domains model. This model is well mature by today and allows for effective and stable deployments even in Inter-AS scenarios. However, for the long time the question with MPVNs was – could we replace IP tunneling with MPLS label encapsulation? And the main motivation for moving to MPLS label switching would be leveraging MPLS traffic-engineering and protection features.
Tag Switched Multicast
Inter-AS Multicast VPN solution introduces some challenges in cases where peering systems implement BGP-free core. This post illustrates a known solution to this problem, implemented in Cisco IOS software. The solution involves the use of special MP-BGP and PIM extensions. The reader is assumed to have understanding of basic Cisco’s mVPN implementation, PIM-protocol and Multi-Protocol BGP extensions.
mVPN – Multicast VPN
MSDP – Multicast Source Discovery Protocol
PE – Provider Edge
CE – Customer Edge
RPF – Reverse Path Forwarding
MP-BGP – Multi-Protocol BGP
PIM – Protocol Independent Multicast
PIM SM – PIM Sparse Mode
PIM SSM – PIM Source Specific Multicast
LDP – Label Distribution Protocol
MDT – Multicast Distribution Tree
P-PIM – Provider Facing PIM Instance
C-PIM – Customer Facing PIM Instance
NLRI – Network Layer Rechability Information