Aug 22 2009
Inter-AS Option B – Revisited
Consider the topology below.
Watch the video below or download and watch it on your iphone.
Inter-AS
Aug 21 2009
Option C – Revisited
Its been a while since I looked at this so here is a refresher.
Consider the topology below.
LDP is configured between RR3 and R1 and also between R2 and RR4.
EBGP with label advertisement is configured between R1 and R2.
The interesting this to notice here is that the label advertised between the EBGP peers is actually taken from LDP. ie R1 advertises the LDP label of 18 for 3.3.3.3 as you can see below. You can see it actually states that in the brackets ie (from LDP).
R1#sh ip bgp labels
Network Next Hop In label/Out label
1.1.1.1/32 0.0.0.0 imp-null(from LDP)/nolabel
2.2.2.2/32 11.0.0.1 17/imp-null
3.3.3.3/32 10.0.0.2 18(from LDP)/nolabel
4.4.4.4/32 11.0.0.1 20/102
R1#
If you check the LFIB you will see the same label assigned by LDP.
R1#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
17 Pop Label 2.2.2.2/32 0 Fa1/0 11.0.0.1
18 Pop Label 3.3.3.3/32 6352 Fa1/1 10.0.0.2
19 Pop Label 11.0.0.1/32 1703 Fa1/0 11.0.0.1
20 102 4.4.4.4/32 1715 Fa1/0 11.0.0.1
R2 receives the prefix 3.3.3.3/32 via eBGP from its neighbor R1 with the label of 18 as you can see below.
R2#sh ip bgp labels
Network Next Hop In label/Out label
1.1.1.1/32 11.0.0.2 103/imp-null
2.2.2.2/32 0.0.0.0 imp-null(from LDP)/nolabel
3.3.3.3/32 11.0.0.2 104/18
4.4.4.4/32 10.0.0.6 102(from LDP)/nolabel
R2#
Once R2 has this prefix we need to redistribute these prefixes into the IGP, in our case OSPF.
Once again you will notice that the label is LFIB is that of the one in BGP.
Once you have redistributed BGP into OSPF on both R1 and R2, you can then configure a MP-eBGP multihop session between the two route-reflectors ie RR3 and RR4. This should be configured with next-hop-unchanged to ensure the VPN label does not change at any point in the network.
Once the VPNv4 session comes up you will see the route 192.168.3.0/24 drop into VPNA(VRF ZARAR) on RR4.
check and make sure you have full connectivity.
RR4#show ip cef vrf ZARAR 192.168.3.0
192.168.3.0/24
nexthop 10.0.0.5 FastEthernet1/0 label 104 18
RR4#ping vrf ZARAR 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 104/251/360 ms
RR4#
Now lets make it a little more complicated ie lets configure VPNA ie VRF ZARAR on R1. R1 will peer vpnv4 with the route-reflector RR3.
Now lets examinte the control plane and the forwading plane.
Control Plane
R1 Generates an incoming VPN label of 16 for prefix 192.168.1.0/24.
R1#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (ZARAR)
192.168.1.0 0.0.0.0 16/nolabel
192.168.3.0 3.3.3.3 nolabel/18
192.168.4.0 4.4.4.4 nolabel/301
R1 advertises the network 192.168.1.0 and its label and nexthop to RR3.
RR3#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (ZARAR)
192.168.1.0 1.1.1.1 nolabel/16
192.168.3.0 0.0.0.0 18/nolabel
192.168.4.0 4.4.4.4 nolabel/301
RR3 then advertises the prefix along with the VPN label and next-hop to RR4.
RR4#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (ZARAR)
192.168.1.0 1.1.1.1 nolabel/16
192.168.3.0 3.3.3.3 nolabel/18
192.168.4.0 0.0.0.0 301/nolabel
As you can see on RR4, prefix 1921.68.1.0 has the original VPN label and next-hop values.
The CEF table within VRF ZARAR on RR4 shows the VPN label next to the transport label.
RR4#sh ip cef VRF ZARAR 192.168.1.0
192.168.1.0/24
nexthop 10.0.0.5 FastEthernet1/0 label 103 16
RR4#
Now lets examine the transport label, in this case the label 103 as seen above.
R1 advertises the network 1.1.1.1 which is the next hop for the prefix 192.168.1.0/24 into BGP and advertised the IPv4 route to R2 with an implicit-null label, which is taken as mentioned below from LDP.
R1#sh ip bgp labels
Network Next Hop In label/Out label
1.1.1.1/32 0.0.0.0 imp-null(from LDP)/nolabel
2.2.2.2/32 11.0.0.1 17/imp-null
3.3.3.3/32 10.0.0.2 18(from LDP)/nolabel
4.4.4.4/32 11.0.0.1 21/102
R1#
R2 receives the prefix 1.1.1.1/32 prefix along with the implicit null label. R2 then redistributes this prefix and label into LDP.
R2#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
100 Pop Label 11.0.0.2/32 13488 Fa1/0 11.0.0.2
102 Pop Label 4.4.4.4/32 708 Fa1/1 10.0.0.6
103 Pop Label 1.1.1.1/32 0 Fa1/0 11.0.0.2
104 18 3.3.3.3/32 6207 Fa1/0 11.0.0.2
R2#
R2 then advertise the prefix and label 103 to RR4 to complete the label switched path.
RR4 now has the transport label required for the VPN prefix 192.168.1.0/24.
RR4#sh ip cef VRF ZARAR 192.168.1.0
192.168.1.0/24
nexthop 10.0.0.5 FastEthernet1/0 label 103 16
RR4#
now lets try and ping 192.168.1.1 from RR4.
RR4#ping vrf ZARAR 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/162/208 ms
RR4#
The configurtion for option C can be found below.
RR3
!
hostname RR3
!
ip vrf ZARAR
rd 1:1
route-target export 1:1
route-target import 1:1
!
mpls ldp router-id Loopback0
mpls label protocol ldp
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
no clns route-cache
!
interface Loopback10
ip vrf forwarding ZARAR
ip address 192.168.3.1 255.255.255.0
no clns route-cache
!
interface FastEthernet1/0
ip address 10.0.0.2 255.255.255.252
duplex auto
speed auto
mpls ip
no clns route-cache
!
router ospf 1
router-id 3.3.3.3
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 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 ebgp-multihop 10
neighbor 4.4.4.4 update-source Loopback0
!
address-family ipv4
no auto-summary
no synchronization
network 3.3.3.3 mask 255.255.255.255
exit-address-family
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 next-hop-unchanged
neighbor 4.4.4.4 send-community extended
exit-address-family
!
address-family ipv4 vrf ZARAR
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
!
R1
!
hostname R1
!
ip vrf ZARAR
rd 1:1
route-target export 1:1
route-target import 1:1
!
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback10
ip vrf forwarding ZARAR
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet1/0
ip address 11.0.0.2 255.255.255.252
mpls bgp forwarding
!
interface FastEthernet1/1
ip address 10.0.0.1 255.255.255.252
mpls ip
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
redistribute bgp 1 subnets route-map LOOPBACK0
network 1.1.1.1 0.0.0.0 area 0
network 10.0.0.0 0.255.255.255 area 0
!
router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0
neighbor 11.0.0.1 remote-as 2
!
address-family ipv4
neighbor 11.0.0.1 activate
neighbor 11.0.0.1 send-label
no auto-summary
no synchronization
network 1.1.1.1 mask 255.255.255.255
network 3.3.3.3 mask 255.255.255.255
exit-address-family
!
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
!
address-family ipv4 vrf ZARAR
redistribute connected
exit-address-family
!
ip prefix-list LOOPBACK0 seq 5 permit 4.4.4.4/32
!
route-map LOOPBACK0 permit 10
match ip address prefix-list LOOPBACK0
!
R2
!
hostname R2
!
mpls ldp router-id Loopback0 force
mpls label range 100 150
mpls label protocol ldp
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
no clns route-cache
!
interface FastEthernet1/0
ip address 11.0.0.1 255.255.255.252
duplex auto
speed auto
mpls bgp forwarding
no clns route-cache
!
interface FastEthernet1/1
ip address 10.0.0.5 255.255.255.252
duplex auto
speed auto
mpls ip
no clns route-cache
!
router ospf 1
log-adjacency-changes
redistribute bgp 2 subnets route-map LOOPBACK0
network 2.2.2.2 0.0.0.0 area 0
network 10.0.0.0 0.0.0.255 area 0
!
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
neighbor 11.0.0.2 remote-as 1
!
address-family ipv4
neighbor 11.0.0.2 activate
neighbor 11.0.0.2 send-label
no auto-summary
no synchronization
network 2.2.2.2 mask 255.255.255.255
network 4.4.4.4 mask 255.255.255.255
exit-address-family
!
ip prefix-list LOOPBACK0 seq 5 permit 3.3.3.3/32
ip prefix-list LOOPBACK0 seq 10 permit 1.1.1.1/32
!
ip access-list standard ZARAR
permit 11.0.0.2
!
!
route-map LOOPBACK0 permit 10
match ip address prefix-list LOOPBACK0
!
route-map CONNECTED permit 10
match ip address ZARAR
!
RR4
!
hostname RR4
!
ip vrf ZARAR
rd 1:1
route-target export 1:1
route-target import 1:1
!
mpls ldp router-id Loopback0
mpls label range 300 400
mpls label protocol ldp
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
no clns route-cache
!
interface Loopback10
ip vrf forwarding ZARAR
ip address 192.168.4.1 255.255.255.0
no clns route-cache
!
interface FastEthernet1/0
ip address 10.0.0.6 255.255.255.252
duplex auto
speed auto
mpls ip
no clns route-cache
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 2
bgp router-id 4.4.4.4
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 ebgp-multihop 10
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
no auto-summary
no synchronization
network 4.4.4.4 mask 255.255.255.255
exit-address-family
!
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 next-hop-unchanged
neighbor 3.3.3.3 send-community extended
exit-address-family
!
address-family ipv4 vrf ZARAR
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
Jan 3 2009
ISIS level-1, level-2 areas, ISIS redistribution and ISIS default route origination.
I’m going to cover following three things in this post.
- Level-1, Level-1-2 and Level-2-only routers. How to configure and what is the att bit
- Investigate the default behavior of the various levels with respect to routing updates. ie are level-2 prefixes by default advertised to level-1 routers.
- Finally we will cover how to originate a default route within a level-2 area.
Consider the topology below.
Some important points worth noting:
- level-1-2 router HAVE to be in the same area as level-1 routers otherwise level-1 routers will not be able to form an adjacency with them.
- the level-1-2 router must have a level-2 adjacency with a router in another area for the att bit to be set in outgoing level-1 updates.
- By default level-1 routes are advertised to level-2 routers.
- By default level-2 routes are NOT advertised to level-1 routers.
Watch the video below or alternatively download the video and watch it on your iPod .
The command used for the above configuration are:
R1
frame-relay switching
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Serial1/0
ip address 10.0.0.1 255.255.255.252
ip router isis
encapsulation frame-relay
clockrate 128000
no arp frame-relay
frame-relay map clns 200 broadcast
frame-relay map ip 10.0.0.2 200
no frame-relay inverse-arp
frame-relay intf-type dce
!
router isis
net 49.0001.0000.0000.0001.00
is-type level-1
passive-interface Loopback0
!
R2
!
frame-relay switching
!
interface Serial1/0
ip address 10.0.0.5 255.255.255.252
ip router isis
encapsulation frame-relay
no fair-queue
serial restart-delay 0
clockrate 128000
no arp frame-relay
frame-relay map ip 10.0.0.6 200
frame-relay map clns 200 broadcast
no frame-relay inverse-arp
frame-relay intf-type dce
isis circuit-type level-2-only
!
interface Serial1/1
ip address 10.0.0.2 255.255.255.252
ip router isis
encapsulation frame-relay
no arp frame-relay
frame-relay map clns 200 broadcast
frame-relay map ip 10.0.0.1 200
no frame-relay inverse-arp
isis circuit-type level-1
!
router isis
net 49.0001.0000.0000.0002.00
redistribute isis ip level-2 into level-1 distribute-list 100
!
access-list 100 permit ip any any
R3
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Serial1/0
ip address 10.0.0.6 255.255.255.252
ip router isis
encapsulation frame-relay
serial restart-delay 0
no arp frame-relay
frame-relay map clns 200 broadcast
frame-relay map ip 10.0.0.5 200
no frame-relay inverse-arp
!
router isis
net 49.0002.0000.0000.0003.00
is-type level-2-only
passive-interface Loopback0
default-information originate
Nov 21 2008
Inter AS MPLS VPN Option B, 2a – Packet Capture
I’ve setup the topology below.
I configured a loopback address with ip address 10.10.10.10 on PE1 and put it inside the VRF for VPN A. One PE1 I could see the VPN label being generated by BGP as below.
sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 65300:1 (CUST)
10.10.10.10/32 0.0.0.0 19/nolabel
As you can see the “In label” is 19. To confirm the label is changed at different points in the LSP path I checked the label for 10.10.10.10 on ASBR1, ASBR2 and PE2, see below for output.
ASBR1
ASBR1#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 65300:1
10.10.10.10/32 1.1.1.1 17/19
As you can see ASBR1 has generated an “In label” of 17 which it advertises to ASBR2.
ASBR2
ASBR2#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 65300:1
10.10.10.10/32 192.168.1.1 23/17
ASBR2 generates its own “In label” of 23 and advertises it to PE2, please see below.
PE2
PE2#sh ip cef vrf CUST 10.10.10.10
10.10.10.10/32
nexthop 11.0.0.5 FastEthernet1/0 label 16 23
PE2#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 65300:1
10.10.10.10/32 4.4.4.4 nolabel/23
I also ran a packet capture on the ASBR2 interface which peers with ASBR1 and sure enough when I ran a ping to 10.10.10.10 I saw a single stacked MPLS frame, with a VPN label of 17.
The reason there is only a single label on the frame between ASBR2 and ASBR1, can be explained due to the next hop changing.
Therefore ASBR2 is the penultimate hop in the LSP and pops the top label and hence you see the VPN label alone on the wire.
Nov 21 2008
Inter AS MPLS VPN Option C – Packet Capture
I setup the following topology.
I configured a loopback address with ip address 10.10.10.10 on PE1 and put it inside the VRF for VPN A. One PE1 I could see the VPN label being generated by BGP as below.
sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 65300:1 (CUST)
10.10.10.10/32 0.0.0.0 19/nolabel
As you can see the “In label” is 19. To confirm the label is not changed anywhere in the path I also checked the label for 10.10.10.10 on ASBR2 and PE2, see below for output.
ASBR2
ASBR2#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 65300:1
10.10.10.10/32 1.1.1.1 nolabel/19
PE2
PE2#sh ip cef vrf CUST 10.10.10.10
10.10.10.10/32
nexthop 11.0.0.5 FastEthernet1/0 label 19 19
PE2#sh ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 65300:1
10.10.10.10/32 1.1.1.1 nolabel/19
I also ran a packet capture on the ASBR2 interface which peers with ASBR1 and sure enough when I ran a ping to 10.10.10.10 I saw a dual stacked MPLS frame, with a VPN label of 19.
Nov 20 2008
Non VPN transit providers – Option 4?
There can be cases where two MPLS VPN service providers would like to deliver an MPLS VPN service to a customer using a non-VPN transit provider ie this non-VPN transit provider has an MPLS infrastructure, but does not deliver MPLS VPN services.
This architecture is sometimes referred to as Option 4(This is not mentioned in section 10 RFC 4364).
Topology as below.
There are two variations in the implementation, the variations in implementation are with respect to how the label information is advertised across the MPLS VPN service provider networks.
1-In variation 1 the ASBR redistributes the learned IPv4 prefixes into the local IGP. A label is then generated and advertised through the network.
2-In variation 2 the ASBR advertised the learned IPv4 prefixes and IPv4 labels using iBGP directly to either the PE or Route reflector.
An LSP is constructed from a PE in one AS to another PE in the destination AS via the non-VPN transit provider.
The route reflectors in the MPLS VPN Service Providers establish an MP-eBGP session to transport VPNv4 prefixes. The route reflectors advertise the prefixes with the next hop unchanged using the command below.
neighbor rr-ip-address next-hop-unchanged
The original VPN label generated by the source PE does not change anywhere in the path.
The link between the ASBRs in the different ASs is a non LDP link, the MPLS signalling carried out over the link is done via BGP (read about BGP MPLS signalling).
Nov 20 2008
Forwarding MPLS traffic over a non LDP interface
mpls bgp forwarding
*To enable an interface to receive Multiprotocol Label Switching (MPLS) packets when the signaling of MPLS labels is through the use of the Border Gateway Protocol (BGP), use the mpls bgp forwarding command in interface configuration mode. To disable an interface from receiving MPLS packets when the signaling of MPLS labels is through the use of the BGP, use the no form of this command.
This command is automatically generated by BGP for directly connected non loopback neighbors.
* Taken from CCO
Nov 20 2008
Inter-AS MPLS VPN Option C
Option C is the most complex of the three inter-AS MPLS VPN options, however its complexity has significant benefits in that it scales well.
However there are some trust issues which need to be overcome. Usually this Option is not implemented unless you have a merger for example and two ASs need to provide an MPLS VPN.
A Sample topology is given below.
Option C requires two bordering ASBRs to share an eBGP session to transport both IPv4 prefixes as well as IPv4 labels.
The IPv4 prefixes are usually the PE and Route Reflector loopback addresses.
BGP is then redistributed into the IGP on the ASBR.
Once the neighboring ASs loopback addresses are in the IGP database, LDP can assign a label for them and an LSP can be built from a source PE in one AS to a destination PE in another AS.
There is also an MP-eBGP peering between the route reflectors in each AS. The MP-eBGP session is configured such that the next hop is unchanged using the command below.
neighbor rr-ip-address next-hop-unchanged
The link between the ASBRs is an IP link, however when you configure Option C you will notice the command below appears on the ASBR interface.
mpls bgp forwarding
The VPN label is originated at the source PE and does not change at any point in the LSP.
Nov 19 2008
Inter-AS MPLS VPN Option b – Type 2a
Inter AS MPLS VPN Option b has three options as described below.
In the first option ie 2a an MP-eBGP session is configured between ASBRs to exchange VPNv4 prefixes.
The Link between the ASBRs does NOT run LDP/TDP and does not require an IGP.
The link is a straight forward point to point IP link.
A sample topology can be seen below.
In the first option for prefixes advertised from CE1 a VPN label will be generated at 3 points.
1-At PE1 a Label will be allocated for the customer prefix.
2-At PE2 the VPN label will be changed as PE2 will advertise the customer prefix with a new next hop.
3-At PE3 the VPN label will be changed as PE3 will have “next-hop-self” configured on its session with PE4.
To can see the VPN label generated as an “in” label using the commands
sh ip bgp vpnv4 all label
On PE1, ASBR1 and ASBR2 you will see the locally generated “in” label.
Nov 19 2008
Inter-AS MPLS VPN Option b – Type 2b
Inter AS MPLS VPN Option b has three options as described below.
In the second option ie 2b an MP-eBGP session is configured between ASBRs to exchange VPNv4 prefixes.
The Link between the ASBRs does NOT run LDP/TDP and does not require an IGP.
The link is a straight forward point to point IP link.
A sample topology can be seen below.
In this option, the ASBRs do not change the next hop of the destination prefix when advertising the prefixes using MP-iBGP.
When an ASBR receives a VPNv4 prefix from another ASBR, a /32 host route is created for the sending ASBR.
This host route needs to be redistributed into your IGP to ensure the LSP can be built.
The VPN label for the prefix changes only twice compared to three times of option b, 2a.
For a prefix Generated by CE1, PE1 will generate the first VPN label. ASBR1 will then change the VPN label when it sends the VPNv4 prefix using MP-eBGP to ASBR2. ASBR2 will then send the VPNv4 prefix to PE2 with the VPN label unchanged.
To can see the VPN label generated as an “in” label using the commands
sh ip bgp vpnv4 all label
On PE1 and ASBR1 you will see the locally generated “in” label.
If you run the above command on ASBR2 you will notice their is no “in” label, this shows the difference between the two sub options 2a and 2b.
1 2