Thursday, November 19, 2009

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.


Monday, November 9, 2009

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.


Tuesday, November 3, 2009

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