Wednesday, February 29, 2012

MPLS L3VPN


Today I did a lab focused on MPLS L3 VPN. Today was the first day actually configuring this from scratch so it was fun and a great learning experience. I ran into several snags along the way but that's ok.(sample topology attached)

First Task is to get the core(PE1, PE2, PE3, PE4) up and running. First thing to decide on is which protocol do we want to use to distribute the MPLS labels. By default I believe LDP is enabled now on recent versions of IOS. So on each of the PE routers I enabled LDP, configured the LDP router id as the loopback of each router. Once I got that up, I figured ok, time to check my LDP neighbor relationships come up. They did not !!!!

Took a trip to the good Doc CD and saw that when using Loopbacks for LDP distibution, we need to advertise that loopback in the network but as a /32 host route only.
http://www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/configuration/12-4t/mp-ldp-overview.html#GUID-C5755CFC-818B-4A02-B35C-741A15E422EC

So now that I advertised the loopbacks, all of my LDP neighbor relationships were established. Next, configured BGP As # 1 for the core, and configured iBGP full mesh in the core. Activated each of the neighbors in the the vpnv4 address family, and enabled the send community extended, so that the attributes could be exchanged across the MPLS cloud. When I enabled the neighbors in vpnv4 AF, you no longer can see them when using the sh ip bgp sum command. At first I thought what happened to my neighbors? I ran show tcp brief and still saw the BGP sessions established(179) and my LDP session(646). Learned when you have the neighbors configured in vpnv4, you need to use the command sh bgp vpnv4 unicast all summary commmand, and they show up phew!

Next I configured the VRF CustomerA and CustomerB(along with the appropriate RD's and route-target imports/exports and assigned then as per the diagram. Then I enabled the PE-CE routing which was pretty straightforward. On the PE side, we need to redistribution from OPSF to BGP under the ipv4 address-family VRF config mode, so that the CE routes, can transit the MPLS, and the remote Customer site, can import the route-target and get the routes in its routing table transparently.

Next was enabling BGP as the PE-CE, and this screwed me up big time. I had it all configured perfect except one commmand. For some reason, The 10.10.x.x routes were not making it across the VPN. I found after 2 hours that I needed to enable as-override. Essentially, for example, when SW4 sends an update to PE4, its an eBGP update, When that traveres the mpls, and tries to export import to SW2, SW2 denies it as it sees its own AS100. So on R1 and R4, need to configure neigbor x.x.x.x as-override, and then routes were now exchanging. Painful lesson for sure, but now I will most likely remember it ;)

Monday, February 27, 2012

First graded lab 360 completed & Passed

Today I took my first graded lab in the Cisco 360. This was good, because now I was up against the clock as I would be in the real lab. I was able to pass with a 83/100, and still, redistribution is tripping me up. For some reason I can't get my mind wrapped around it.

Most of the items in the lab I was able to complete without issue. There were a few times when I messed myself up. For example, one section in for RIP, it asked to make sure that there were only unicast updates being sent between the neighbors. I did everything right: 1. I made sure that the interfaces were passived in RIP process . 2. Configured the neighbor statement on each side. I messed up on # 2 because I configured the wrong IP address on one of the neighbor statements. Thank God I actually ran the debug ip rip events to see one side was still sending multicast updates to 224.0.0.9, or else I would have lost points.

There was one BGP task that messed me up for a minute as well. It asked me to configure a summary address for 4 prefixes learned via my iBGP neighbor, which came from an external AS. The catch is, they wanted me to advertise this to a neighboring BGP AS, but it said to make it appear as if the routes came from the Originating AS, and to do this with only a summary route, no specific subnets. At first I was getting crazy thinking ok, how Can I send an eBGP update, and make that AS thing that the orignating AS sent it. As you can imagine, that wasn't going to well. I took a quick glance at the Doc CD config guide, and command reference and quickly saw the BGP AS-SET option. This is what I needed. The as-set command when used with an aggregate address will list the path in the eBGP update, showing the AS's that the update came through, and of course starting with the AS that sent it. So in the end aggreate-address x.x.x.x mask y.y.y.y as-set summary-only, did the trick.

I new this was the last task and according to my calculations of other tasks, I needed to get these 4 points to pass the lab. Sure enough, when I get the lab results , I got 83/1000. Without these 4 points I would not have passed.

I am happy to have passed, but not satisified. I need to be better, quicker, and not make some of the silly mistakes I am making.

Until next time :)

Sunday, February 5, 2012

360 link layer labs


Today I did a 360 LAB. All was ok until the last portion where they wanted to obtain reachability from R1 to SW4 on the 172.16.100.x subnet, which as you see in the Pic, it looks directly connected, but its not.

The requirement was to configure the subinterface of R1 F0/0.1 to encapsulate in VLAN 999, and have reachability to the SW4 VLAN 1144 SVI.

The actual L2 Flow is R1(F0/1.1) --------SW2 F0/1 --------L2 trunk-------SW4 (SVI VLAN 1144)

I configured R1 like so:

interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.1
encapsulation dot1Q 999 native
ip address 172.16.100.1 255.255.255.0


SW2 confi f0/2

interface FastEthernet0/1
description R1 port 0/1
switchport access vlan 1144
switchport mode access

I did it this way because when encapsulating on a sub-interface on a router in Native VLAN, frames are sent untagged. My IP on the router is in the same VLAN as the SW4 SVI.

SW2 f0/2 is expecting only untagged frames(which we are sending due to the native command on R1), and will set the access VLAN to VLAn 1144,(same vlan/broadcast domain as SW4), and we see that everything works.

The first ping failure is due to SW2 f0/2 not being configured just yet.

R1#ping 172.16.100.44

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.100.44, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 172.16.100.44

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.100.44, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Good learning, I saw a similar VoD on 360 program that talked about this, and had some doubts, but this clears it up