INE Vol 1 - Lab 16 - Multihop MP-eBGP for VPNv4 Exchange

Finally finished this lab, but experienced and oddity...

I saw the routes in the CE routers for the remote CE but wasn't able to ping. I even sourced my pings from a loopback that was being advertised in the CE-PE routing protocol. Weird.

Other than that, this was an interesting one, the 2 routers that join the 2 BGP ASes, were configured as eBGP peers and configured to send-label. Then the the eBGP VPNv4 relationship was farther spread apart, it was actually a peering of the PE to PE across 2 BGP ASes.

All in all, a good lab, but I'm troubled by why I can't seem to ping from CE to CE in either VRF.

On to the next one.

UPDATE------------ Issue resolved.
The problem was something so silly, I didn't have MPLS IP configured on R4, R5, and R6 in my ISIS domain. A good lesson, if your control plane looks good (ie your routing table) then the problem has to be in your forwarding plane. Thanks to Vignesh for his help.

INE Vol 1 - Lab 15 - finished - MP-BGP for Inter VRF

So it's taken awhile to finish this lab, mostly due to the my new role at work. I'm supporting production networks and troubleshooting issues and while it's interesting to some degree, it does take away from studying.

Anyhow, this lab was the same setup as the last one, back to back VRFs, but uses MP-BGP to leak routes between BGP domains. The thing to note on this lab is BGP automatically filters route-targets that it doesn't need to know of (meaning it doesn't have a link configured for). So in order to exchange VPN routes it needs to stop this filtering by...
'no bgp default route-target filter' under the BGP process. That way, it can know the VRF routes and leak them between it's MP-eBGP peer of the other network.

I'm afraid my progress will continue to slow, I hope once things settle down I'll be able to return more aggressively to my studies.

INE Vol 1 - Lab 14 - finished - Back to Back VRF

Pretty straight forward lab on using 2 routers and a single Fast Ethernet interface, dot1q trunked or "router on a stick", to exchange VRF information for 2 ASes to interconnect CEs. Yeah, that's a long sentence. So the 2 CE's span 2 different BGP ASes, and the 2 BGP ASes meet at a single point where the 2 routers share a dot1q FE trunk. The sub interfaces of the FE are configured like CE connections, meaning that the links are configured for a specific vrf on both routers. Then there are 2 BGP peering sessions for each VRF in the IPv4 table. RDs for the VRFs are the same even if the BGP Peering isn't direct.

The BGP peering point just looks like a connection to another CE on each AS.

Good lab, have a feeling a similar configuration is done for VRF-Lite and I'll see it when I do that lab.

INE Vol 1 - Lab 13 - finished - VPNv4 Route Reflection

This lab was interesting. Basically, the lab asks you to use a router (R2) to be VPNv4 route reflector for 3 BGP clients R3, R4, and R6. The 3 clients (or PEs) have a MPLS VPN configured but the route-reflector doesn't. I'm going to liken R2 as a P-core router.

This lab also demonstrates another router, R1, to be the IPv4 route-reflector for it's BGP peers. R1 is the route-reflector for R2 through R6. R1 is also eBGP peered with BB3 and is receiving routes. This portion demonstrates how ipv4 bgp routes are unaffected by VPNv4 BGP routes and vice versa.

This one would be good to go back to, to keep VPNv4 and IPv4 BGP straight.

INE Vol 1 - Lab 12 - finished - OSPF Domain-ID.

In this lab we were asked to peer with the PE routers from 4 remote CE sites using different OSPF AS numbers. The 4 routers were put into 2 VPNs (as most of these labs require). Using different RDs and importing and exporting different RTs, only the members of a vpn were able to talk to each other.

The part that this lab tests you on is OSPF Domain-ID. Using the same domain-id for OSPF on the PEs for the CE members in the same VPN allows the OSPF routes on the CEs to look like inter-area (ia) routes instead of external (e2) routes. This means that over mpls cloud, the 2 sites are looking like they're separated by an area-boarder router when in actuality they're still mutually redistributed into BGP.

On to the next lab.

INE Vol 1 - Lab 11 - finished - OSPF Sham Link.

The gist of this lab was when using OSPF to interconnect 2 remote sites to 2 PEs and they have a back door link to each other (ie a private line) then because the routers are in the same area 0, routes within an area are preferred over routes that are INTER area and OSPF has a lower AD then iBGP. To get around this, between the two PEs you can create an ospf sham-link and then change the cost of the backdoor link to be worse.

config:

Router1(config-if)# area 1 sham-link 10.2.1.1 10.2.1.2 cost 40

verify:

show ip ospf sham-links

INE Vol 1 - Lab 10 - finished - BGP SOO.

This lab was interesting in that there is a "gotcha".

The CE's in 2 different locations are using the SAME BGP AS number (AS 100) so inherently they won't exchange routes due to the loop prevention mech. That being said, using AS-OVERIDE on the neighboring CEs will replace any AS number (AS 100) that is the same with the PE AS number (AS 1), thus allowing connectivity.

The purpose of BGP SOO, which is a BGP extended community attribute, is to provide a loop prevention mechanism. A route-map applied on the PE to 2 CE neighbors "tags" the prefixes learned with a SOO. When tagging to 2 CEs off the same PE, the effect is that the PE won't advertise a learned route with the same SOO to another CE, effectively preventing a loop. An assumption is that the 2 CE's have a backdoor connection between themselves.

1 Thing to note, the solution guide config for SW1 doesn't have a bgp neigh peer statement for SW2, iBGP. But SW2 has a neighbor statement for SW1. (since one side is missing they are not iBGP peering)

On to the next one.