INE Vol 1 - Lab 15 - Inter-AS MPLS VPNs with MP-eBGP for VPNv4 Exchange

Notes:

Same physical setup as the previous lab, the important point to note here, is that if a you are using VPNv4 for route exchange between ASes, hence Inter-AS, then you have to disable BGP's default behavior of filter route-targets that it doesn't need. "Doesn't need" meaning no interfaces that are configured for that VRF.

R2 and R4 are "PEs" and they sit in 2 different BGP ASes, the eBGP peer in the VPNv4 AFI (MP-eBGP) but they won't have the VPNv4 routes from their respective PEs since they don't have interfaces in the particular VRFs. This means those VPNv4 routes are filter until you disable the feature.

Configs:

R2

R2#sh run | b router bgp

router bgp 1

no bgp default ipv4-unicast

no bgp default route-target filter

bgp log-neighbor-changes

neighbor 150.1.3.3 remote-as 1

neighbor 150.1.3.3 update-source Loopback0

neighbor 150.1.24.4 remote-as 2

!

address-family vpnv4

neighbor 150.1.3.3 activate

neighbor 150.1.3.3 send-community extended

neighbor 150.1.3.3 next-hop-self

neighbor 150.1.24.4 activate <- notice there's no "next-hop-self" because ebgp next hop is the

neighbor 150.1.24.4 send-community extended neighbor

exit-address-family

!

R4

router bgp 2

no bgp default ipv4-unicast

no bgp default route-target filter

bgp log-neighbor-changes

neighbor 150.1.6.6 remote-as 2

neighbor 150.1.6.6 update-source Loopback0

neighbor 150.1.24.2 remote-as 1

!

address-family vpnv4

neighbor 150.1.6.6 activate

neighbor 150.1.6.6 send-community extended

neighbor 150.1.6.6 next-hop-self

neighbor 150.1.24.2 activate

neighbor 150.1.24.2 send-community extended

exit-address-family

!

INE Vol 1 - Lab 14 - Inter-AS MPLS VPNs with Back to Back VRF

Notes:

As the title suggests, or rather blatantly states, 2 BGP ASes that are MPLS enabled with an interconnect between R2 and R4, a VPN that spans both ASes.

So how is this accomplished? R2 and R4 have dot1q trunk between them and each subinterface belongs to a separate VRF. IPV4 eBGP between them. For the purpose of trying to keep it straight and simple. R2 and R4 both seem to act as PEs and CEs at the same time. The connections between them belong to VRFs and no label distribution protocol is deployed.

For example, R2 sends all it's routes in the VRFs via ebgp (the CE-PE routing protocol) R4 then sends them to the other PE via VPNv4 routes. And vice versa, R4 sends all it's routes in the VRFs via the same eBGP (CE-PE routing protocol) connections to R2 and then R2 sends them as VPNv4 routes to the other PE in it's AS.

Config:

R2

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.3.3 remote-as 1

neighbor 150.1.3.3 update-source Loopback0

neighbor 150.1.100.4 remote-as 2

neighbor 150.1.200.4 remote-as 2

!

address-family vpnv4

neighbor 150.1.3.3 activate

neighbor 150.1.3.3 send-community extended

neighbor 150.1.3.3 next-hop-self

exit-address-family

!

address-family ipv4 vrf SW2-BB2

neighbor 150.1.200.4 remote-as 2

neighbor 150.1.200.4 activate

no synchronization

exit-address-family

!

address-family ipv4 vrf SW1-BB1

neighbor 150.1.100.4 remote-as 2

neighbor 150.1.100.4 activate

no synchronization

exit-address-family

R2#sh run int f2/0.100

Building configuration...

Current configuration : 127 bytes

!

interface FastEthernet2/0.100

encapsulation dot1Q 100

ip vrf forwarding SW1-BB1

ip address 150.1.100.2 255.255.255.0

end

R2#sh run int f2/0.200

Building configuration...

Current configuration : 127 bytes

!

interface FastEthernet2/0.200

encapsulation dot1Q 200

ip vrf forwarding SW2-BB2

ip address 150.1.200.2 255.255.255.0

end

R4

router bgp 2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.6.6 remote-as 2

neighbor 150.1.6.6 update-source Loopback0

!

address-family vpnv4

neighbor 150.1.6.6 activate

neighbor 150.1.6.6 send-community extended

neighbor 150.1.6.6 next-hop-self

exit-address-family

!

address-family ipv4 vrf SW2-BB2

neighbor 150.1.200.2 remote-as 1

neighbor 150.1.200.2 activate

no synchronization

exit-address-family

!

address-family ipv4 vrf SW1-BB1

neighbor 150.1.100.2 remote-as 1

neighbor 150.1.100.2 activate

no synchronization

exit-address-family

!

!

interface FastEthernet2/0.100

encapsulation dot1Q 100

ip vrf forwarding SW1-BB1

ip address 150.1.100.4 255.255.255.0

!

interface FastEthernet2/0.200

encapsulation dot1Q 200

ip vrf forwarding SW2-BB2

ip address 150.1.200.4 255.255.255.0

!

INE Vol 1 - Lab 13 - MPLS VPNs with VPNv4 Route Reflection

Notes:

This one is pretty straight forward, the ability to use AFI and disabling bgp default ipv4-unicast, you can separate VPNv4 RR and IPv4 RR.

* Regarding GNS3/dynamips, for some reason LDP didn't come up in the core right away, it took awhile, minutes, for LDP to come up but eventually it did on its own.

INE Vol 1 - Lab 12 - MPLS VPNs with OSPF Domain ID

Notes:

When using OSPF as the CE-PE routing protocol and using unique OSPF process IDs and you want the routes at different vpn sites but the same VRF to have IA - Inter Area routes and not E2 - external (redistributed) routes, you can use the same OSPF Domain ID on the PEs for a single VRF. This changes the routes from E2 to IA.

Configs:

PE 1

R4#sh run | b router ospf

router ospf 5 vrf R5-SW1

domain-id 1.1.1.1

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

!

router ospf 6 vrf R6-SW2

domain-id 2.2.2.2

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

!

PE2

R3#sh run | b router os

router ospf 7 vrf R5-SW1

domain-id 1.1.1.1

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

!

router ospf 8 vrf R6-SW2

domain-id 2.2.2.2

log-adjacency-changes

redistribute bgp 1 subnets

network 10.1.0.0 0.0.255.255 area 0

CE - before using domain-id

R5#sr os

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O E2 10.1.7.7/32 [110/2] via 10.1.45.4, 00:00:39, FastEthernet1/0

O E2 10.1.37.0/24 [110/1] via 10.1.45.4, 00:00:39, FastEthernet1/0

R5#

CE - After using domain-id

R5#sr os

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O IA 10.1.7.7/32 [110/3] via 10.1.45.4, 00:00:17, FastEthernet1/0

O IA 10.1.37.0/24 [110/2] via 10.1.45.4, 00:00:27, FastEthernet1/0

INE Vol 1 - Lab 11 - OSPF Sham Link

Notes: OSPF Sham link is a "virtual link" between 2 PEs, this is used because the CE-PE protocol is OSPF and it gets redistributed into MP-BGP and then back to OSPF making the routes over MPLS WAN an Inter Area route. The backdoor connection is an Intra Area route and would always take precedence. To over come this, the Sham link is created between the 2 PEs and the the routes no longer are Inter Area routes.

Some things to remember, create a new loopback on the PEs and put them in the VRF, the advertise the Loopback interfaces in the IPv4 VRF in BGP to create reachability. Also remember to add a high OSPF cost on the backdoor link.

Configs:

R3#sh run | b router os

router ospf 1 vrf R6-SW1

log-adjacency-changes

area 0 sham-link 10.1.3.3 10.1.4.4

redistribute bgp 1 subnets

network 10.1.37.3 0.0.0.0 area 0

!

router isis

net 00.0000.0000.0003.00

is-type level-2-only

!

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.4.4 remote-as 1

neighbor 150.1.4.4 update-source Loopback0

!

address-family vpnv4

neighbor 150.1.4.4 activate

neighbor 150.1.4.4 send-community extended

exit-address-family

!

address-family ipv4 vrf R6-SW1

redistribute ospf 1 vrf R6-SW1

no synchronization

network 10.1.3.3 mask 255.255.255.255

exit-address-family

!

interface Loopback1

ip vrf forwarding R6-SW1

ip address 10.1.3.3 255.255.255.255

end

R3#

INE Vol 1 - Lab 10 - SOO

(The best explanation I can give is the one I already gave)

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 - Export Map

No issues with this one as well, just using an Export map within the VRF to change the RTs for some prefixes. Create a route-map, match an acl for the prefix, set the extcommunity rt and then in the vrf specify the route-map as an EXPORT map.