CCIE Lab Preparation

Just another CCIE blog

  • Category

  • Archives

  • Advertisements

Archive for the ‘Uncategorized’ Category

Inter-AS MPLS VPN Options

Posted by Jo on September 12, 2009

I have been going through some Inter-AS MPLS VPN labs over the past couple of days. There are basically 3 different methods to achieve Inter-AS connectivity for MPLS VPNS.

Option 10A – Back to Back VRFs between ASBRs
Option 10B – VPNv4 eBGP between ASBRs
Option 10C – VPNv4 between RRs or PEs using multihop eBGP

I have labbed up all three of these methods along with the some slight variations on the specific configuration options within each of them and will be writing these up in the coming days.

These are described in RFC 2547bis of which an extract is below.

10. Multi-AS Backbones

What if two sites of a VPN are connected to different Autonomous Systems (e.g., because the sites are connected to different SPs)? The PE routers attached to that VPN will then not be able to maintain IBGP connections with each other, or with a common route reflector. Rather, there needs to be some way to use EBGP to distribute VPN-IPv4 addresses.

There are a number of different ways of handling this case, which we present in order of increasing scalability.

a) VRF-to-VRF connections at the AS (Autonomous System) border routers.

In this procedure, a PE router in one AS attaches directly to a PE router in another. The two PE routers will be attached by multiple sub-interfaces, at least one for each of the VPNs whose routes need to be passed from AS to AS. Each PE will treat the other as if it were a CE router. That is, the PEs associate each such sub-interface with a VRF, and use EBGP to distribute unlabeled IPv4 addresses to each other.

This is a procedure that “just works”, and that does not require MPLS at the border between ASes. However, it does not scale as well as the other procedures discussed below.

b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.

In this procedure, the PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then uses EBGP to redistribute those labeled VPN-IPv4 routes to an ASBR in another AS, which in turn distributes them to the PE routers in that AS, or perhaps to another ASBR which in turn distributes them …

When using this procedure, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet, or from any BGP peers which are not trusted. An ASBR should never accept a labeled packet from an EBGP peer unless it has actually distributed the top label to that peer.

If there are many VPNs having sites attached to different Autonomous Systems, there does not need to be a single ASBR between those two ASes which holds all the routes for all the VPNs; there can be multiple ASBRs, each of which holds only the routes for a particular subset of the VPNs.

This procedure requires that there be a label switched path leading from a packet’s ingress PE to its egress PE. Hence the appropriate trust relationships must exist between and among the set of ASes along the path. Also, there must be agreement among the set of SPs as to which border routers need to receive routes with which Route Targets.

c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 routes from AS to neighboring AS.

In this procedure, VPN-IPv4 routes are neither maintained nor distributed by the ASBRs. An ASBR must maintain labeled IPv4 /32 routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled /32 routes. This results in the creation of a label switched path from the ingress PE router to the egress PE router. Now PE routers in different ASes can establish multi-hop EBGP
connections to each other, and can exchange VPN-IPv4 routes over those connections.

If the /32 routes for the PE routers are made known to the P routers of each AS, everything works normally. If the /32 routes for the PE routers are NOT made known to the P routers (other than the ASBRs), then this procedure requires a packet’s ingress PE to put a three label stack on it. The bottom label is assigned by the egress PE, corresponding to the packet’s destination address in a particular VRF. The middle label is assigned by the ASBR, corresponding to the /32 route to the
egress PE. The top label is assigned by the ingress PE’s IGP Next Hop, corresponding to the /32 route to the ASBR.

To improve scalability, one can have the multi-hop EBGP connections exist only between a route reflector in one AS and a route reflector in another. (However, when the route reflectors distribute routes over this connection, they do not modify the BGP next hop attribute of the routes.) The actual PE routers would then only have IBGP connections to the route reflectors in their own AS.

This procedure is very similar to the “Carrier’s Carrier” procedures described in section 9. Like the previous procedure, it requires that there be a label switched path leading from a packet’s ingress PE to its egress PE.


Posted in Uncategorized | 1 Comment »

Inter-AS MPLS VPN Video Part 2

Posted by Jo on September 9, 2009

Here is part two…

IPexpert SP Workbook Lab 18 Inter-AS MPLS-VPN Part 2 from Jo on Vimeo.

Posted in Uncategorized | Leave a Comment »

Inter-AS MPLS VPN Video Part 1

Posted by Jo on September 9, 2009

Check out the video link below that I made of me configuring this lab scenario. This part covers the IGP and basic BGP configuration. Its best to open the video in full screen.

Part 2 is on the way also, just need to upload it to Vimeo, but being on a 100kb/s upstream link doesnt quite work out to well 🙂

IPexpert SP Workbook Lab 18 Inter-AS MPLS-VPN Part 1 from Jo on Vimeo.

Posted in Uncategorized | Leave a Comment »

A new friend

Posted by Jo on September 2, 2009


  1. Bridging and Switching
    1. VTP, VLAN, Trunk, Spanning tree
    2. Frame Relay, DLCI, FR multilink
    3. ATM PVC, SVC, FR/ATM interworking
    4. PPPoE
  2. IGP Routing
    1. IS-IS, Level 1/2, Metric
    2. OSPF, LSA, Area
    3. Redistribution, Summarization, Filtering
    4. Policy routing
  3. EGP Routing
    1. IBGP, EBGP
    2. BGP attributes
    3. Confederation, Route reflector
    4. Synchronization, Aggregation, Stability
    5. Redistribution, Filtering
    6. Multipath
  4. SP Multicast
    2. Auto RP, Static RP, BSR, Anycast RP
    3. MP-BGP for multicast, MSDP
  5. MPLS
    1. Label distribution, LDP/ TDP
    2. Label filtering, Label merging, Multipath
    3. MPLS COS
    4. MPLS Netflow
    5. MPLS over ATM
    6. MPLS Traffic Engineering
  6. L3/L2 VPN
    1. MPLS VPN, MP-iBGP
    2. PE-CE routing, RIPv2, OSPF, EIGRP, Static, ISIS, EBGP
    3. BGP Extended Community
    4. Inter AS MPLS VPN
    5. Carrier Supporting Carrier
    6. VRF-Lite, VRF Select
    7. Multicast MPLS VPN
    8. GRE, multipoint GRE
    9. AToM, L2TPv3
    10. 802.QinQ
  7. SP QoS and Security
    2. Marking, Shaping, Policing
    3. CAR, FRTS
    4. WRQ, CBWFQ, LLQ, PQ, CQ
    5. RED, WRED
    6. LFI, cRTP
    7. RSVP
    8. ACL, RPF, Filtering
    9. Routing update security
    10. Common attacks
  8. High Availability
    1. NSF, GLBP
    2. Fast reroute, Link/Node protection
    3. HSRP, VRRP
  9. Management
    2. Accounting
    3. Netflow
    4. NTP

Posted in Uncategorized | 1 Comment »

My Lab Experience – Part I

Posted by Jo on October 8, 2008

So things have calmed down a little bit for me since yesterday. Firstly I would like to say thanks for all the comments on the site and via email – its great to hear from so many people! Id like to write a little bit about my lab experience in Brussels – it wont go into too much detail about the contents of the lab, but more general covering the complete experience.

Getting there and the night before

I planned to be in Brussels for just one night, but due to a general strike starting on Sunday night for 24 hours I was notified by Eurostar that my return journey on Monday evening had been canceled, so I had to rebook for the next morning. Not a big deal, but it meant I had to take an extra day off from work and pay for another night in the hotel – but at least I would get to Brussels in time, which was the main thing.

The journey was painless from London to Brussels on the train, once I got to the station I had to make my way to Diegem, the suburb where Cisco is located, and had about an hours wait for the connecting train. Once there I headed to my hotel. I booked in at the Formule 1 Hotel, mainly because it was €43 per night and I was on a budget (do yourself a favour – if you are spending $1400+ on the lab exam, spend however much it costs to stay at a decent hotel, like the NH or Holiday Inn, the night before). If I had the choice I wouldnt go back to this hotel, it was pretty basic with no bathroom in the room itself, but out in the hall way cubicle style and shared with all other guests. The TV only had 2 English TV channels (Eurosport and MTV – which was mostly in German). I brought some notes with me and a few solutions guides from IE and IPexpert, and made a start reading through them. I wouldnt recommend doing any last minute cramming, just more of a general read through of some of the basics.

When I got bored with reading (it didnt take long) I got some rest before heading out to check out the Cisco campus and make sure I knew where to go the next day. The weather on Sunday evening was terrible, lashing down with rain and blowing a storm – good job I brought my umbrella. Once at Cisco I had a wander around the deserted campus. The first building I went to I banged on the door and spoke to the security guard who directed me to another building where the lab would be the next morning. I made my way back to the hotel which was a 10 minute walk away – and my umbrella broke under the force of the wind half way there, so I spent the next 5 minutes getting soaked through going back to the hotel. Now that I was umbrella-less I booked a cab for 7.20 the next morning so I wouldnt turn up to the lab looking like a Titanic survivor if the weather was the same.

That night I didnt do any more reviewing of my notes – if I didnt know it by now it was too late – I put the TV on and watched Southpark and Family Guy in German (and didnt understand any of it). I managed to get to sleep somewhere between 12-1am as my mind was racing a little, but thankfully I woke up at 6.30 to get ready for the big day.

Lab day

In the morning I got up, showered went down to have breakfast. The weather was better than the day before but I still had a cab booked which turned up at 7.15 so in I jumped. I was at Cisco by 7.20 and headed into the building. There were three guys there already so we all said hello, but conversation wasnt flowing for obvious reasons. One guy was there to do his R&S lab like me and it was his second attempt, the other two were in to do SP and Voice. Over the next 20 minutes the reception filled up with around 10 of us in total, some people were chatting others were concentrating on the day ahead. We were due to be collected by the proctor at 7.45, but by 7.50 there was still no sign of anyone, which added to the anticipation and nervousness! We all kind of got our hopes up each time someone entered the foyer hoping it was the proctor. Bruno the Brussels proctor finally turned up at about 8.15 and apologised for being late but he was stuck in traffic due to the strike – but we didnt need to worry as the lab is 8 hours based on the start time. We all headed up to the lab, showed our ID and sat at our stations. We were given a briefing by Bruno to check the configs on our racks to see if they tie up with the workbooks. Then the exam started.

I did what all vendors tell you to do and read through the exam – twice. My first impressions were kind of OK – there is a lot of information to digest. Reading the exam twice took about 15 minutes, I wasnt studying it just seeing if I could handle the contents. Once I finished reading I checked over the rack. Initially I was a little confused, there may be troubleshooting tasks in the lab, so I was expecting some errors in the initial config. One thing I wasnt sure about was the level of any preconfiguration that may or may not be applied to the rack. What I was seeing was a fully configured lab in front of me, with totally different IP address schemes. I was thinking to myself I know this is the CCIE lab but this amount of troubleshooting is ridiculous! I jumped up and spoke to the proctor to verify and he said that I still had the config from last Fridays candidate! It turned out that 4 other guys also had the same issue and Bruno may have to grade these labs before clearing the config and giving us our labs. I think its a good job I didnt change anything, and I hope the guy before me passed his lab!

This meant we had to go to the break room for 45 minutes while this took place – we all had a laugh about it, and it gave us a chance to introduce ourselves to each other properly. There was a good mix of people there, a guy from Australia who now lives in Denmark doing his Security exam, a fellow Londoner (via India) who was on his second attempt at R&S, a guy from Norway and a guy from Nigeria (working in Sweden) who were both on their first attempts at R&S. A couple of these guys were flying back to Denmark at 18:45 so were worrying about what time the lab would now end for them, and if they would make check-in for the flight. Luckily for me I was now going home the following day, so no such worry for me.

Once we got the call to come back in to the lab 45 minutes later, we were told that our end time was 45 minutes after everyone else. I made a start on the lab properly. I wont go into any detail about the contents of the lab itself, but it was a solid exam with parts of it that make you think about the solutions. There were a few tasks that I wasnt sure on, but the great thing about this exam is that the answers are all the in the documentation somewhere – its up to you to find it, digest it and apply it appropriately. I know for sure that I used the docs to answer some questions that I didnt know the answer to, but was lucky enough to track down.

I was actually done with the exam (including my first check through) by 15:30, and was due to finish now at 17:43, so I had plenty of time to double check things again. I wasnt 100% confident on all of the solutions, but I had to trust my instinct a little. I was actually really terrified of changing too much, but I answered every question in the lab. My usual weak areas of Multicast and QoS I was sure I had nailed – which was a great confidence booster. I know I missed some points in the core IGP sections, as I had workarounds in place, so I concentrated on these, but didnt change them in the end due to paranoia of breaking other things that I knew were working!

On leaving the exam, I thought I had a good chance of passing. A lot of it is down to interpretation, but I checked a few things with the proctor, who was helpful if you asked him nicely and didnt fish for the answer. He basically would say – ‘what is the question you are asking’ if he felt you were probing too much. The other guys all finished up at 17:43 and we headed out. All of them were sure they would be back for another attempt, and I was feeling quietly confident inside, but never sure. It would be a long wait until I got the result…

Posted in CCIE Blog, CCIE LAB, Lab Schedule, Uncategorized | 9 Comments »