INE Vol 1 - Lab 26 - finished - Mulicast over MPLS VPNs

I completed this lab, albeit, I had to cheat and look at the solutions for some parts since I wasn't sure what to do.

Question:

1. What is the purpose of MDT under the VRF?

I suppose, I'll Cisco Univercd or google it.

Also my verifications didn't come up. When I do a "show ip pim vrf SW1-SW2 neighbor" I don't actually see the tunnel0 interface of R3 or R6. The tunnel interface is up/up though.

Think I have to read about Multicast over MPLS A LOT more.

INE Vol 1 - Lab 24 - finished - TE Unequal Cost Load Balancing

Completed this lab pretty easily since it was combination of the 2 before it, one dynamic tunnel and one explicit tunnel, manipulating the tunnel bandwidth for unequal cost load balancing via OSPF.

Something I don't understand is why INE didn't have TE labs based on ISIS, the 3 TE labs were using OSPF. I understand they are pretty similar to each other with an addition of using Wide Metric (metric style wide) under the physical interfaces. But still, it would have been nice to through 1 lab in there with IS-IS.

On to the next lab.

INE Vol 1 - Lab 23 - finished - TE Explicit PE to PE tunnel.

Very similar with the last lab with exception of creating an
'ip explicit-path name ABC enable' and then on the tunnel interface
'tunnel mpls traffic-eng path-option 1 explicit name ABC'

One gotcha is to make sure that the HOPs in the list are correct... I had a 10.x.x.x network but I put it in as 150.x.x.x because the rest of the network was like that.

Another good one to review and dissect.

INE Vol 1 - Lab 22 - finished - TE Dynamic PE to PE tunnels

This one was my first exposure to Traffic Engineering (TE) and it was an eye opening lab on how much I don't know about TE.

Notes:
1. enable 'mpls traffic-eng' globally on MPLS routers (PE and P)
2. enable 'mpls traffic-eng' on a per interface basis for the links that are MPLS enabled
3. enable 'mpls traffic-eng' under the OSPF process specifying a router-id and area
4. configure RSVP on a per interface basis for the tunnel path
5. configure tunnel interfaces on the PE end points
6. advertise the tunnel interface/ip in OSPF.

TE is something I need to read up on but doing the lab before hand actually will help understand what I'm going to read.

INE Vol 1 - Lab 20 - finished - VRF Lite (Multi VRF)

Good lab to get an understanding of doing VRF Lite on the CE routers which can be done when a customer subscribes to more then 1 VRF at a site but with only 1 CE router.

From the CE's perspective, it has multiple logical (can be physical) interfaces up stream to the PE. Each link is put into it's own VRF. Downstream to other customer internal routers, each link is put into the respective VRFs. The VPN/VRF table is extended to the CEs. This segregates the 2 networks even when there's only 1 CE. One thing to note, on the CE's there's no need to import or export Route Targets, that's still done on the PE.

The PE's put the logical interfaces into different VRFs and reference the same RDs used on the CEs for their corresponding links/VRFs, for route targets. Basically the PE configuration stays the same EXCEPT for the fact the link to the CE is a single physical link but with multiple logical links.

Good lab to review and build by just looking at the topology.

INE Vol 1 - Lab 19 - CSC Hierarchical MPLS VPNs

This one was pretty straight forward as well and the name implies the structure of the VPNs. One CSC VPN/VRF to connect the Customer Providers network and then the Customer Provider has End Customers so each of them will have their own VRF.

Main point is that redistribution occurs on the Main Service Providers network and then once again on the Customer Service Providers network to get end to end reachability.

On to the next one.

INE Vol 1 - Lab 18 - CSC MPLS enabled.

Pretty straight forward, although I should definitely read up on the theory on these. This lab, compared to the last one, was a bit easier since there were less BGP peerings since the links were MPLS enabled throughout both Service Providers. In the last lab, not all links in the provider cloud was MPLS enabled, hence the title, IP ONLY.

On to the next one.

INE Vol 1 - Lab 17 - CSC IP Only

First lab for Carrier Supporting Carrier (CSC) and it's still not very clear to me on some of configurations. Still got it to work by following the tasks but not as intuitive as the other labs.

I still made the same mistake, although I caught it much faster this time, as in the previous lab. "MPLS IP" was missing from some of the provider links, the control plane (ie. the routing table) look good, saw the BGP route but the forwarding plane was messed up because I couldn't ping.

At least I'm learning.

BGP AS 2 was used as the Service Provider servicing the Customer Service Provider and BGP AS 1 was used as the Customer Service Provider's network. BGP AS 65001 and 65002 were customer CEs connecting to the Customer Service Provider's network.

Within AS 1, I had to use route-reflectors in order to get around the fully meshed iBGP peering rule and another note I had to mutually redistribute on the Service Provider routers supporting the Customer Service Provider before iBGP could be formed. This was asked to be done in the last step.

On to the next one.

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.

INE Vol 1 - Lab 9 - finished - Export Maps.

This one was pretty straight forward as well...

Use an export map to gain connectivity to ONLY certain subnet in a different VRF, similar to a Extranets and subsequently Common Services VRF but more restrictive (granular). The VRF offering the different subnets still needs to import the rt's from all the other VRFs for connectivity back. Using an Export map (route-map), you set the extended community to designate an rt associated with the matching subnet.

I THINK I'm getting a better handle on VRFs as I go through these labs, I hope I can keep it up.

On to the next one.

INE Vol 1 - Lab 8 - finished - Extranet.

Building off the concept of Central Services, you can use an Extranet to "leak" vrf/routes between two or more VRFs.

Since you can't establish more then 1 Route Distinguisher, you can use an "artificial" rd by route-target export/import and use the "artificial rds.

On to the next one...

INE Vol 1 - Lab 7 - finished - Central Services.

Finished this lab with no issues.

Basically using importing and exporting of RD's for certain VRFs to limit communications between different sites/vrfs.

On to the next one.

INE Vol 1 - Lab 6 - finished - EBGP.

Pretty straight forward, no redistribution necessary since it's bgp.

The one thing I wanted to verify was the eBGP routes on a PE. Something like "show ip bgp ipv4 vrf ... " but there's no command to do that.

Is that right?

On to the next one.

INE Vol 1 - Lab 5 - finished - EIGRP as CE-PE IGP.

I figured I'd just remove the CE-PE IGP from the last lab instead of recreating the whole topology from scratch. This time it was EIGRP.

Things to keep in mind, EIGRP is like BGP in that it uses address-families, within the address families you need to make sure you specify and antonymous-system to match the CE instance. Redistributing EIGRP into BGP use the configure AS and the rest is pretty much the same.

Trekking along on this rainy Friday.