INE Vol 1 - Lab 26 - Multicast over MPLS VPNs ?

Notes:

For the second time, I couldn't get the tunnel to show up on PE R3 when executing a "show ip pim vrf SW1-SW2 neighbor"

I see the tunnel interface as up/up but I can't seem to see the other end, R6 the remote PE, as neighbor through the tunnel.

I did a show ip pim mdt and shows the loopback.

Not sure what's wrong...

Configs:

R3 -PE

hostname R3

!

boot-start-marker

boot-end-marker

!

logging message-counter syslog

!

no aaa new-model

ip source-route

ip cef

!

no ip domain lookup

ip vrf SW1-SW2

rd 1:2

route-target export 1:2

route-target import 1:2

mdt default 232.0.0.1

!

ip multicast-routing

ip multicast-routing vrf SW1-SW2

no ipv6 cef

!

interface Loopback0

ip address 150.1.3.3 255.255.255.255

ip router isis

ip pim sparse-mode

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface Serial1/0

ip address 150.1.13.3 255.255.255.0

ip router isis

ip pim sparse-mode

mpls ip

serial restart-delay 0

!

interface FastEthernet2/0

ip vrf forwarding SW1-SW2

ip address 10.1.37.3 255.255.255.0

ip pim sparse-mode

duplex auto

speed auto

!

interface FastEthernet2/1

no ip address

shutdown

duplex auto

speed auto

!

router isis

net 00.0000.0000.0003.00

is-type level-2-only

log-adjacency-changes

!

router rip

!

address-family ipv4 vrf SW1-SW2

redistribute bgp 100 metric 1

network 10.0.0.0

no auto-summary

version 2

exit-address-family

!

router bgp 100

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.6.6 remote-as 100

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

exit-address-family

!

address-family ipv4 vrf SW1-SW2

redistribute rip

no synchronization

exit-address-family

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

!

ip pim ssm default

ip pim vrf SW1-SW2 rp-address 10.1.37.7

!

R6 - PE router

hostname R6

!

boot-start-marker

boot-end-marker

!

logging message-counter syslog

!

no aaa new-model

ip source-route

ip cef

!

!

!

!

no ip domain lookup

ip vrf SW1-SW2

rd 1:2

route-target export 1:2

route-target import 1:2

mdt default 232.0.0.1

!

ip multicast-routing

ip multicast-routing vrf SW1-SW2

no ipv6 cef

!

interface Loopback0

ip address 150.1.6.6 255.255.255.255

ip router isis

ip pim sparse-mode

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface FastEthernet1/0

ip address 150.1.56.6 255.255.255.0

ip router isis

ip pim sparse-mode

duplex auto

speed auto

mpls ip

!

interface FastEthernet1/1

ip vrf forwarding SW1-SW2

ip address 10.1.68.6 255.255.255.0

ip pim sparse-mode

duplex auto

speed auto

!

router isis

net 00.0000.0000.0006.00

is-type level-2-only

log-adjacency-changes

!

router rip

!

address-family ipv4 vrf SW1-SW2

redistribute bgp 100 metric 1

network 10.0.0.0

no auto-summary

version 2

exit-address-family

!

router bgp 100

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.3.3 remote-as 100

neighbor 150.1.3.3 update-source Loopback0

!

address-family vpnv4

neighbor 150.1.3.3 activate

neighbor 150.1.3.3 send-community extended

exit-address-family

!

address-family ipv4 vrf SW1-SW2

redistribute rip

no synchronization

exit-address-family

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

!

ip pim ssm default

ip pim vrf SW1-SW2 rp-address 10.1.37.7

!

INE Vol 1 - Lab 25 - MPLS QoS

Notes:

QoS in MPLS is similar to doing a translation on PEs.

The objective was to guarantee 640 kbps of Voice traffic as a priority through the SP. Therefor, on the PEs, you need to classify VOIP coming from the CE and also VOIP-Translated coming from the P. Keep in mind that within the MPLS VPN, the labels carry EXP bits (3) so with the SP network you should be dealing with EXP exclusively.

Config:

R3 - PE router

class-map match-all VoIP

match access-group name VoIP

class-map match-all QOS_GROUP_5

match qos-group 5

class-map match-all MPLS_EXP_5

match mpls experimental topmost 5

policy-map TO_P

class MPLS_EXP_5

priority 640

class MPLS_EXP_1

bandwidth 1000

random-detect

policy-map FROM_P

class MPLS_EXP_5

set qos-group 5

class MPLS_EXP_1

set qos-group 1

policy-map TO_CE

class QOS_GROUP_5

priority 640

class QOS_GROUP_1

bandwidth 1000

random-detect

policy-map FROM_CE

class VoIP

set qos-group 5

set mpls experimental imposition 5

class class-default

set qos-group 1

set mpls experimental imposition 1

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

Notes:

The objective asks you to configure TE tunnels with a total of 10 Mbps between 2 PE routers, R3 and R4. One third of the traffic between these PEs need to transit thru R5.

In order to accomplish this, I created to TE tunnels, Tun 0 and Tun 1, both explicit paths. Tun 0 bypassed R5 and Tun 1 went thru R5. The setup is identical until you get to the tunnels bandwidth statement. Since 1/3 has to go through R5, tunnel 1 has a bandwidth of 3333 kbps and tunnel 0 has 6667 kbps.

This is a good exercise to show that the RSVP Total BW is 10 Mbps so the sum of the individual tunnel bandwidths must be no more then 10 Mbps. This also achieves unequal cost load balancing via the bandwidth statements.

Config:

R3 - PE and TE Head End

interface Loopback0

ip address 150.1.3.3 255.255.255.255

!

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 3 3

tunnel mpls traffic-eng bandwidth 6667

tunnel mpls traffic-eng path-option 1 explicit name THRU_R4

no routing dynamic

!

interface Tunnel1

ip unnumbered Loopback0

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 3 3

tunnel mpls traffic-eng bandwidth 3333

tunnel mpls traffic-eng path-option 1 explicit name THRU_R5

no routing dynamic

!

interface Serial1/0

bandwidth 155000

ip address 150.1.13.3 255.255.255.0

mpls traffic-eng tunnels

mpls ip

fair-queue 64 256 313

serial restart-delay 0

ip rsvp bandwidth 10000

!

interface FastEthernet2/0

ip vrf forwarding SW1-SW2

ip address 10.1.37.3 255.255.255.0

duplex auto

speed auto

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

log-adjacency-changes

network 150.1.0.0 0.0.255.255 area 0

!

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

neighbor 150.1.4.4 next-hop-self

exit-address-family

!

address-family ipv4 vrf SW1-SW2

neighbor 10.1.37.7 remote-as 2

neighbor 10.1.37.7 activate

no synchronization

exit-address-family

!

ip explicit-path name THRU_R4 enable

next-address 150.1.13.1

next-address 150.1.12.2

next-address 150.1.24.4

next-address 150.1.4.4

!

ip explicit-path name THRU_R5 enable

next-address 150.1.13.1

next-address 150.1.12.2

next-address 150.1.25.5

next-address 10.1.45.4

next-address 150.1.4.4

INE Vol 1 - Lab 23 - MPLS TE Explicit PE to PE tunnels

Notes:

*** Rule of thumb to simplify this configuration. After the MPLS VPN network is setup, think of it as overlaying TE on top. Go from General to Specific, meaning General = enabling MPLS TE on a global level, router wide. Then go to more Specific, like enabling MPLS TE in the link state IGP routing protocol, and then even more specific on the interfaces enabling RSVP and TE and then last step create the tunnel interfaces.

This lab is identical to the previous except for the TE tunnels using an explicit path list, hop by hop list, instead of a dynamic path like the last lab.

REMEMBER, the next-address is the next hop's inbound interface (looking from a downstream perspective).

Config:

R3 - PE and Tunnel head end

R3#sh run | b ipv6

no ipv6 cef

!

multilink bundle-name authenticated

mpls traffic-eng tunnels

!

interface Loopback0

ip address 150.1.3.3 255.255.255.255

!

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 4 4

tunnel mpls traffic-eng bandwidth 10000

tunnel mpls traffic-eng path-option 1 explicit name PATH

no routing dynamic

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface Serial1/0

bandwidth 155000

ip address 150.1.13.3 255.255.255.0

mpls traffic-eng tunnels

mpls ip

fair-queue 64 256 313

serial restart-delay 0

ip rsvp bandwidth 10000

!

interface FastEthernet2/0

ip vrf forwarding SW1-SW2

ip address 10.1.37.3 255.255.255.0

duplex auto

speed auto

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

log-adjacency-changes

network 150.1.0.0 0.0.255.255 area 0

!

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

neighbor 150.1.4.4 next-hop-self

exit-address-family

!

address-family ipv4 vrf SW1-SW2

neighbor 10.1.37.7 remote-as 2

neighbor 10.1.37.7 activate

no synchronization

exit-address-family

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

!

!

ip explicit-path name PATH enable

next-address 150.1.13.1

next-address 150.1.12.2

next-address 150.1.25.5

next-address 10.1.45.4

next-address 150.1.4.4

!

logging alarm informational

!

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

Notes:

Remember to configure the bandwidth statement on serial interfaces, this is especially important if you plan on using RSVP and reserving a large amount of BW because you won't be able to reserve say 10 Megs if the serial link is only 1.5 Meg.

Summary of configuration steps:

1. Enable MPLS Traffic Engineering tunnels globally

2. Ensure the Link State protocol is configured to support Traffic Engineering Tunnels and remember to use a /32 router-id loopback for MPLS TE

3. Ensure the links are configured for RSVP and MPLS TE

4. Create Tunnel Interfaces; use ip unnumbered for address, set a tunnel destination IP (the other loopback), autoroute announce so the tunnel is in the IGP, set bandwith, priority, and path-options.

Don't forget that the destination IPs need to be in IGP as well as do the MPLS TE router-ids. And that TE is unidirectional.

Configs:

R3 - PE and Tunnel Head End

R3#sh run | b no ipv6

no ipv6 cef

!

multilink bundle-name authenticated

mpls traffic-eng tunnels

!

archive

log config

hidekeys

!

interface Loopback0

ip address 150.1.3.3 255.255.255.255

!

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 150.1.4.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 6 6

tunnel mpls traffic-eng bandwidth 10000

tunnel mpls traffic-eng path-option 1 dynamic

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface Serial1/0

bandwidth 155000

ip address 150.1.13.3 255.255.255.0

mpls traffic-eng tunnels

mpls ip

serial restart-delay 0

ip rsvp bandwidth 155000 155000

interface FastEthernet2/0

ip vrf forwarding SW1-SW2

ip address 10.1.37.3 255.255.255.0

duplex auto

speed auto

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

log-adjacency-changes

network 150.1.0.0 0.0.255.255 area 0

!

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

neighbor 150.1.4.4 next-hop-self

exit-address-family

!

address-family ipv4 vrf SW1-SW2

neighbor 10.1.37.7 remote-as 2

neighbor 10.1.37.7 activate

no synchronization

exit-address-family

!

ip forward-protocol nd

Verify:

R3#sh mpls traffic-eng tunnels brief

Signalling Summary:

LSP Tunnels Process: running

Passive LSP Listener: running

RSVP Process: running

Forwarding: enabled

Periodic reoptimization: every 3600 seconds, next in 1716 seconds

Periodic FRR Promotion: Not Running

Periodic auto-bw collection: every 300 seconds, next in 216 seconds

TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT

R3_t0 150.1.4.4 - Se1/0 up/up

R4_t0 150.1.3.3 Se1/0 - up/up

Displayed 1 (of 1) heads, 0 (of 0) midpoints, 1 (of 1) tails

R3#

Good Reference

INE Vol 1 - Lab 21 - Controlling MPLS Label Distribution

Notes:

This lab asks you to limit the traffic that should be label switched. It states that only traffic between R3 and R6's (the PEs) Loopbacks should be label switched. In order to do so, on the PE and P nodes, use 'mpls ldp advertise-labels for #' and an ACL to limit what prefixes are allowed to be labeled and what prefixes are not.

Config:

R1 - P node

R1#sh run | i 99

mpls ldp advertise-labels for 99

access-list 99 permit 150.1.3.3

access-list 99 permit 150.1.6.6

access-list 99 deny any log

R1#

INE Vol 1 - Lab 20 - VRF Lite

Notes:

It IS pretty straight forward, except for the fact that in GNS3, I used a single serial interface with 2 sub interfaces to another router. HDLC, nothing fancy, but wasn't able to ping on the sub-interfaces. I ended up making a separate physical connection for R3 to R1 and my configuration worked.

On point, this lab demonstrated the use of VRF lite to use a Managed CE with sub interfaces to the PE and segment traffic.

INE Vol 1 - Lab 19 - CSC Hierarchical MPLS VPNs

Notes:

Fairly similar to the previous lab, same concepts with supporting more then 1 Enterprise end customer.

I would recommend review Lab 17 as it's not as intuitive as 18 or 19.

INE Vol 1 - Lab 18 - CSC MPLS enabled Customer Carrier

Notes:

This Lab was much more intuitive, probably from struggling and figuring out the previous lab, and I was able to configure the topology without viewing the instructions. From the Objective and from the diagram, I understood that the Customer Carrier was supporting MPLS and MPLS VPNs, the Provider Carrier didn't change much as they too support MPLS VPNs. Providing IGP transport for R3 and R6, the Customer Carrier's PE routers, was straight forward. Since R3 and R6 participate in OSPF and R2 and R4's link into OSPF was through a VRF, redistribution for Carrier Providers PE's was necessary. Once R3 had reachability to R6, vpnv4 iBGP was established spanning the Provider Carrier's network. Finally, putting the Customer PE interfaces into a vrf for PE-CE connectivity and establishing eBGP with the Enterprise client routers, full reachability was established.

Remember to ensure MPLS is enabled through out the network up until the Enterprise connectivity links.

Configs:

R2 - Provider Carrier's PE

R2#srb

router ospf 100 vrf AS1

log-adjacency-changes

redistribute bgp 2 subnets

network 150.1.12.2 0.0.0.0 area 0

!

router ospf 1

log-adjacency-changes

network 150.1.24.2 0.0.0.0 area 0

!

router bgp 2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.24.4 remote-as 2

!

address-family vpnv4

neighbor 150.1.24.4 activate

neighbor 150.1.24.4 send-community extended

exit-address-family

!

address-family ipv4 vrf AS1

redistribute ospf 100 vrf AS1

no synchronization

exit-address-family

R3 - Customer Carrier's PE

R3#srb

router ospf 1

log-adjacency-changes

network 150.1.3.3 0.0.0.0 area 0

network 150.1.13.3 0.0.0.0 area 0

!

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.6.6 remote-as 1

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 CUST

neighbor 10.1.37.7 remote-as 65001

neighbor 10.1.37.7 activate

no synchronization

exit-address-family

!

INE Vol 1 - Lab 17 - CSC IP only Customer Carrier

Notes:

The purpose of this lab was to utilize another carrier as transport for a customer carrier to provide IP services to their end customers, presumably enterprise clients. The SP carrier uses R2 and R4 and BGP between them as well as MPLS and MPLS VPNs down to R1 and R5 (the customer carrier's upstream routers). Being how this is an "IP Only" Customer Carrier BGP was only ipv4, however, R2 and R4 were VPNv4 for label transport/MPLS VPN.

I attempted to configure this lab and all the previous labs just from the Objective and the diagram without reading the specific tasks, this one was a difficult in doing that because the peering between BGP ASes was evident from the diagram. I ended up trying to peer AS1 and AS2 but instead should have redistributed OSPF vrf into ipv4 bgp vrf... etc.

This is a great lab to review again.

Configs:

R2 - SP Carrier Router

R2#sri s1/0.21

Building configuration...

Current configuration : 172 bytes

!

interface Serial1/0.21 point-to-point

ip vrf forwarding AS1

ip address 150.1.12.2 255.255.255.0

snmp trap link-status

mpls ip

frame-relay interface-dlci 201

end

R2#sri f2/0

Building configuration...

Current configuration : 104 bytes

!

interface FastEthernet2/0

ip address 150.1.24.2 255.255.255.0

duplex auto

speed auto

mpls ip

end

R2#srb

router ospf 1 vrf AS1

log-adjacency-changes

redistribute bgp 2 subnets

network 150.1.12.2 0.0.0.0 area 0

!

router ospf 100

log-adjacency-changes

network 150.1.24.2 0.0.0.0 area 0

!

router bgp 2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.12.1 remote-as 1

neighbor 150.1.24.4 remote-as 2

!

address-family vpnv4

neighbor 150.1.24.4 activate

neighbor 150.1.24.4 send-community extended

exit-address-family

!

address-family ipv4 vrf AS1

redistribute ospf 1 vrf AS1

no synchronization

exit-address-family

R1 - Customer Carrier Router

R1#sri s1/0.12

Building configuration...

Current configuration : 149 bytes

!

interface Serial1/0.12 point-to-point

ip address 150.1.12.1 255.255.255.0

snmp trap link-status

mpls ip

frame-relay interface-dlci 102

end

R1#sri s1/1

Building configuration...

Current configuration : 88 bytes

!

interface Serial1/1

ip address 150.1.13.1 255.255.255.0

serial restart-delay 0

end

R1#srb

router ospf 1

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

!

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.2.2 remote-as 2

neighbor 150.1.2.2 update-source Loopback0

neighbor 150.1.5.5 remote-as 1

neighbor 150.1.5.5 update-source Loopback0

neighbor 150.1.13.3 remote-as 1

!

address-family ipv4

neighbor 150.1.5.5 activate

neighbor 150.1.5.5 route-reflector-client

neighbor 150.1.13.3 activate

neighbor 150.1.13.3 route-reflector-client

no auto-summary

no synchronization

exit-address-family

R3 - Customer Provider Edge Router

R3#srb

router ospf 1

log-adjacency-changes

network 150.1.3.3 0.0.0.0 area 0

network 150.1.13.3 0.0.0.0 area 0

!

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 10.1.37.7 remote-as 65001

neighbor 150.1.13.1 remote-as 1

!

address-family ipv4

neighbor 10.1.37.7 activate

neighbor 150.1.13.1 activate

neighbor 150.1.13.1 next-hop-self

no auto-summary

no synchronization

exit-address-family

!

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

Notes:

The last 3 labs have been a similar problem with 3 different solutions. This one uses MP-eBGP to peer across different ASes for PEs (that are in different ASes). In order to accomplish this, the ipv4 bgp peering between R2 and R4 need to advertise the loopbacks of R3 and R6 (PE in AS1 and PE in AS2, respectively), they also need to advertise or redistribute into the IGP so the R3 and R6 can know of each other's loopback for MP-eBGP multihop peering. Don't forget to send-label for ipv4 peering. Finally, VPNv4 peer between R3 and R6.

Configs:

R2 - AS1 ipv4 peering point to AS2

R2#sh run | b router

router ospf 1

log-adjacency-changes

redistribute bgp 1 subnets route-map LOOP6

network 150.1.2.2 0.0.0.0 area 0

network 150.1.12.2 0.0.0.0 area 0

!

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.24.4 remote-as 2

!

address-family ipv4

neighbor 150.1.24.4 activate

neighbor 150.1.24.4 send-label

no auto-summary

no synchronization

network 150.1.3.3 mask 255.255.255.255

exit-address-family

!

R4 - AS2 ipv4 peering point to R2

router isis

net 00.0000.0000.0004.00

is-type level-2-only

redistribute bgp 2 route-map LOOP3

!

router bgp 2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.24.2 remote-as 1

!

address-family ipv4

neighbor 150.1.24.2 activate

neighbor 150.1.24.2 send-label

no auto-summary

no synchronization

network 150.1.6.6 mask 255.255.255.255

exit-address-family

!

R3 - AS1 PE - ebgp vpnv4 multihop peering to R6

!

router bgp 1

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.6.6 remote-as 2

neighbor 150.1.6.6 ebgp-multihop 255

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

exit-address-family

R6 - AS2 PE - ebgp vpnv4 multihop peering to R3

router bgp 2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.1.3.3 remote-as 1

neighbor 150.1.3.3 ebgp-multihop 255

neighbor 150.1.3.3 update-source Loopback0

!

address-family vpnv4

neighbor 150.1.3.3 activate

neighbor 150.1.3.3 send-community extended

exit-address-family

!

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.

INE Vol 1 - Lab 8 - Extranet

Another fairly easy review. Extranets using their own import/export of route-targets.

So far no notes or configs to put down seeing as I'm flying through the last (or first) 8 labs.

INE Vol 1 - Lab 7 - Central Services

Also, pretty straight forward, a manipulation of route-targets, importing only the route target of the CS vrf and exporting your own route-target.