MPLS

Jun 27 2011

Multicast VPN

PIM-SM, PIM-SSM, and PIM-BIDIR are all supported inside the provider core for MVPN.

PIM-SM or PIM-SSM is the recommended PIM option in the provider core, because PIM-BIDIR is not yet supported by all platforms, PIM-SM, PIM-SSM, PIM-BIDIR and PIM-DENSE-MODE are supported inside the MVPN.

MVPN has the concepts of Multicast Distribution Trees (MDT). An MDT is sourced by a PE router and has a multicast destination address. PE routers that have sites for the same MVPN will all source to a Default-MDT and also join to receive traffic on it.

There is a distinction between Default-MDTs and Data-MDTs. A Default-MDT is a tree that is `always-on’ and will transport PIM control-traffic, dense-mode traffic and rp-tree (*,G) traffic. All PE routers configured with the same default-MDT will receive this traffic.

Data-MDTs are trees that are created on demand and will only be joined by the PE routers that have interested receivers for the traffic. They can be created either by a traffic rate threshold and/or source-group pair.

Default-MDTs must have the same group address for all VRFs that comprise a MVPN. Data-MDTs may have the same group address if PIM-SSM is used. If PIM-SM is used, they should have a different group address, as providing the same one could result in the PE router receiving unwanted traffic. This is a PIM-SM protocol issue, not an implementation issue.

show ip pim mdt bgp

show ip bgp vpnv4 all

show ip mroute

show ip pim neighbors

show ip pim vrf catalunya neighbors

show ip pim vrf catalunya rp mapping

PE_BARCELONA#show ip pim mdt bgp

Peer (Route Distinguisher + IPv4)	Next Hop

 MDT group 239.232.0.0

 2:1:1:10.0.0.2	10.0.0.2

 2:1:1:10.0.0.3	10.0.0.3

 2:1:1:10.0.0.4	10.0.0.4

2:1:1 indicates the RD-type (2) and RD (1:1) associated with this update.

The remaining part is the address used to source the BGP session.

Alternatively, `show ip bgp vpnv4 all’ can be used.

PE_BARCELONA#show ip bgp vpnv4 all

BGP table version is 24, local router ID is 10.0.0.1

Status codes:	s suppressed, d damped, h history, * valid, > best, i - internal,

	r RIB-failure, S Stale

Origin codes:	i - IGP, e - EGP, ? - incomplete

	Network	Next Hop	Metric	LocPrf	Weight Path

Route Distinguisher: 1:1 (default for vrf catalunya)

*> 20.0.1.0/24	0.0.0.0	0		32768 ?

*>i20.0.2.0/24	10.0.0.2	0	100	0 ?

*>i20.0.3.0/24	10.0.0.3	0	100	0 ?

*> 20.1.0.0/22	20.0.1.2	0		32768 ?

*> 20.1.0.0/16	20.0.1.2	0		32768 ?

*>i20.2.0.0/24	10.0.0.2	1	100	0 ?

*>i20.3.0.0/24	10.0.0.3	1	100	0 ?

*>i20.4.0.0/24	10.0.0.4	0	100	0 ?

*> 20.5.5.5/32	20.0.1.2	1		32768 ?

Route Distinguisher: 2:1:1

*> 10.0.0.1/32	0.0.0.0			0 ?

*>i10.0.0.2/32	10.0.0.2	0	100	0 ?

*>i10.0.0.3/32	10.0.0.3	0	100	0 ?

*>i10.0.0.4/32	10.0.0.4	0	100	0 ?

Step 2. Verify the global mroute table

Use `show ip mroute <mdt-group-address>’ to verify that there is a (Source,Group) entry for each PE router. As PIM-SSM is used, the source is the loopback address used to source the BGP session and the Group is the MDT address configured. Without traffic, only default-MDT entries will be visible.

PE_BARCELONA#show ip mroute 239.232.0.0

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

 L - Local, P - Pruned, R - RP-bit set, F - Register flag,

 T - SPT-bit set, J - Join SPT, M - MSDP created entry,

 X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

 U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel,

 Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.0.0.1, 239.232.0.0), 00:18:40/00:03:14, flags: sTZ

 Incoming interface: Loopback0, RPF nbr 0.0.0.0

 Outgoing interface list:

 Serial 1/0, Forward/Sparse, 00:17:53/00:02:31

(10.0.0.2, 239.232.0.0), 00:17:52/00:02:44, flags: sTIZ

 Incoming interface: Ethernet0/0, RPF nbr 10.1.0.2

 Outgoing interface list:

 MVRF catalunya, Forward/Sparse, 00:17:52/00:00:00

(10.0.0.3, 239.232.0.0), 00:17:47/00:02:44, flags: sTIZ

 Incoming interface: Ethernet0/0, RPF nbr 10.1.0.2

 Outgoing interface list:

 MVRF catalunya, Forward/Sparse, 00:17:47/00:00:00

(10.0.0.4, 239.232.0.0), 00:17:46/00:02:44, flags: sTIZ

 Incoming interface: Ethernet0/0, RPF nbr 10.1.0.2

 Outgoing interface list:

 MVRF catalunya, Forward/Sparse, 00:17:46/00:00:00

Verify that the `s’ flag is set on each (S,G) entry, which indicates that this group is used in ssm mode. Verify that the `Z’ flag is set indicating that this PE router is a leaf of the multicast tunnel. When the router is a `leaf’ of a multicast tunnel, it has to do additional lookups to determine which MVRF to forward this traffic to, as it is basically a receiver for this traffic.

Verify the I flag is set for the remote PE(S,G) entry. This flag indicates that the router understands it is joining an SSM group. It is as though an IGMPv3 host had requested to join that particular channel.

Step 3. Verify PIM neighbors in the global table

Use the `show ip pim neighbors’ command on all PE and P routers to verify that the pim neighbors are setup properly in the global table.

PE_BARCELONA#show ip pim neighbor

PIM Neighbor Table

Neighbor	Interface	Uptime/Expires	Ver	DR

Address				Priority/Mode

10.1.0.2	Serial 1/0	00:18:36/00:01:21	v2	1 / S

The example above shows that PE_BARCELONA has correctly setup a PIM neighborship in the global table with the P router.

Step 4. Verify PIM neighbors inside the VPN

Use `show ip pim vrf catalunya neighbors’ on all PE routers to verify that the CE router is seen as a PIM neighbor and the remote-PE routers are seen as a pim neighbor over the tunnel.

PE_BARCELONA#show ip pim vrf catalunya neighbor

PIM Neighbor Table

Neighbor	Interface	Uptime/Expires	Ver	DR

Address				Priority/Mode

20.0.1.2	Ethernet0/0	00:18:30/00:01:27	v2	1 / DR

10.0.0.3	Tunnel0	00:17:40/00:01:18	v2	1 /

10.0.0.4	Tunnel0	00:17:40/00:01:19	v2	1 / DR

10.0.0.2	Tunnel0	00:17:40/00:01:19	v2	1 /

There is correctly a PIM neighbor with the CE router on interface Ethernet 1/0, and all remote PE routers are also seen as PIM neighbors over the tunnel.

Step 5. Verify the VPN Group to RP mapping

Use `show ip pim vrf catalunya rp mapping’ to verify that the PE router correctly learned the Group to RP mapping information from the VPN.

PE_BARCELONA#show ip pim vrf catalunya rp map

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

	RP 20.5.5.5 (?), v2v1

	Info source: 20.5.5.5 (?), elected via Auto-RP

	Uptime: 00:10:34, expires: 00:02:24

The PE router has correctly learned the Group to RP mapping, which is used inside the VPN. Auto-RP is used here inside the VPN.

When all the above has been successfully verified, Figure 2 presents a conceptual overview showing the default-MDT reaching all PE routers with the multicast replication being done in the core of the provider network.

With only a default-MDT configured, traffic will go to all PE routers, regardless of whether they want to receive the traffic.

By Zarar • CCIE SP, MPLS VPN, Multicast, MVPN, PIM-SM • 0

Aug 22 2009

Inter-AS Option B – Revisited

Consider the topology below.

Watch the video below or download and watch it on your iphone.

By Zarar • CCIE SP, Inter-AS, iPhone, MPLS VPN • 1 • Tags: CCIE SP, Inter-AS, MPLS VPN

Aug 3 2009

Frame-Relay to VLAN Interworking – AToM

Consider the topology below.

Watch the video below or download and watch it on your ipod or iphone.

The commands used in the above video can be found below.
PE1
! hostname PE1 ! frame-relay switching ! mpls ldp router-id Loopback0 force mpls label protocol ldp ! pseudowire-class ZARAR encapsulation mpls interworking ip ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet1/0 ip address 10.0.0.1 255.255.255.252 mpls ip ! interface Serial2/0 no ip address encapsulation frame-relay clockrate 128000 frame-relay interface-dlci 110 switched frame-relay intf-type dce ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 ! connect ISMAIL Serial2/0 110 l2transport xconnect 3.3.3.3 101 pw-class ZARAR !
PE2
! hostname PE2 ! frame-relay switching ! mpls ldp router-id Loopback0 force mpls label range 500 600 mpls label protocol ldp ! pseudowire-class ZARAR encapsulation mpls interworking ip ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface FastEthernet1/0 ip address 10.0.0.6 255.255.255.252 mpls ip ! interface FastEthernet1/1 xconnect 1.1.1.1 101 pw-class ZARAR ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 !
CE1
! hostname CE1 ! interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface Serial0 ip address 11.0.0.1 255.255.255.252 encapsulation frame-relay ip ospf network point-to-point frame-relay map ip 11.0.0.2 110 broadcast ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 !
CE2
! hostname CE2 ! interface Loopback0 ip address 5.5.5.5 255.255.255.255 ! ! hostname CE2 ! interface Loopback0 ip address 5.5.5.5 255.255.255.255 ! interface FastEthernet0 ip address 11.0.0.2 255.255.255.252 ip ospf network point-to-point ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 !

By Zarar • AToM, CCIE SP, iPhone, iPod, MPLS • 1 • Tags: AToM, CCIE SP, MPLS

Feb 28 2009

6PE – IPv6 over MPLS

6PE is a really cool feature which allows IPv6 islands to communicate with each other over an MPLS/IPv4 core network. IPv4 addresses space is fast running out so familiarising yourself with IPv6 is probably a good idea.

Consider the toplogy below.

Service providers can leverage their MPLS networks to deliver IPv6 solutions without having to rearchitect their networks. The PE devices are configured with IPv6 routing capability, however the P nodes have no IPv6 routing functionality enabled.

Data packets are encapsualted into MPLS frames on the ingress PE with two labels, the bottom of the stack label being the label assigned to the IPv6 prefix and the top label which is used to forward the packet has a label binding of the PE3s loopback 0 address.

From 6PE2 if we do a cef lookup for the IPv6 prefix connected to 6PE1 we see the following.

6PE2#sh ipv6 cef 2001:2:: 2001:2::/64 nexthop 10.0.0.5 FastEthernet1/0 label 16 19

The bottom of stack label ie 19 is the ipv6 label and can be verified on 6PE2 as below.

6PE2#sh ip bgp ipv6 unicast labels Network Next Hop In label/Out label 2001:2::/64 ::FFFF:1.1.1.1 nolabel/19

The top label ie 16 is generated from a recursive lookup which points to the remote 6PE device ie 6PE1s loopback address.

6PE2#sh ip cef 1.1.1.1 1.1.1.1/32 nexthop 10.0.0.5 FastEthernet1/0 label 16 6PE2#

the 6CEs can use an IPv6 IGP for 6PE-to-6CE connectivity or they can rely on static routing. In this case static routing has been configured as below.

ipv6 route ::/0 FastEthernet1/0 2001:2::2

Watch the video below or download it and watch it on your iPod or iPhone.

By Zarar • BGP, CCIE SP, iPhone, iPod, IPv6, MPLS, PE-CE Routing • 2 • Tags: CCIE SP, IPv6, MPLS

Feb 7 2009

OSPF down bit and domain tag

Both the OSPF down bit and domain tag are modifications in OSPF which are used as loop prevention mechanisms. Why are there two mechanisms you ask. This is because type 5 LSAs do not contain the options field in the header. The options field is where the down bit is set. In LSA type 5 an external route tag is used to identify routes which have been redistributed from BGP into OSPF.

The external route tag value is a 32-bit value. The four highest bits are set to 1101 according to RFC 1745. The lowest 16 bits map to the BGP autonomous system (AS) number of the MPLS VPN backbone. you can set the VPN tag value manually within ospf using the command domain-tag <tag>.

To demonstrate both the down-bit and external route-tag consider the topology below. We will as part of the excersise change the external tag and see if we can induce a routing loop.

You can watch the video below, or alternativly you can download it and watch it on you iPod or iPhone.

I made this one in a bit of a hurry, so would appreciate some feedback.

By Zarar • CCIE SP, iPhone, iPod, MPLS • 13 • Tags: CCIE SP, MPLS, OSPF

Feb 1 2009

Controlling MPLS Label Distribution – Video

I was looking through my archives to remember how to configure “controlling label distribution” and realised that I had not not made a video for this subject, so here goes.

Consider the topology below.

As we all know, LDP assigns a Label for each IGP prefix and connected route in the RIB. Therefore when we use the “Control label distribution” feature we need to ensure the ACL we use, contains an access control entry(ACE) for the neighboring loopbacks. Each Label Switch Router(LSR) then advertises a label binding for each loopback.

Lets take R3s loopback for example. R3 advertises a label for its loopback to R2. R2 has an ACE for R3s loopback and therefore sends a label to R1. R1 now has an end to end LSP to R3. If on R2 you did not have an ACE for R3s loopback, you are effectivly breaking the LSP.

Watch how to configure it below, or download it and watch in on your iPod or iPhone.

The commands used in the above video can be seen below.

R1
! no mpls ldp advertise-labels mpls ldp advertise-labels for LOOPBACK0 mpls label protocol ldp ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet1/1 ip address 10.0.0.1 255.255.255.252 ip ospf network point-to-point mpls ip ! router ospf 1 router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 area 0 network 10.0.0.0 0.0.0.3 area 0 ! ip access-list standard LOOPBACK0 permit 1.1.1.1 permit 2.2.2.2 permit 3.3.3.3 ! mpls ldp router-id Loopback0 !
R2
! no mpls ldp advertise-labels mpls ldp advertise-labels for LOOPBACK0 mpls label protocol ldp ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet1/0 ip address 10.0.0.2 255.255.255.252 ip ospf network point-to-point mpls ip ! interface FastEthernet1/1 ip address 10.0.0.5 255.255.255.252 ip ospf network point-to-point mpls ip ! ip access-list standard LOOPBACK0 permit 2.2.2.2 permit 3.3.3.3 permit 1.1.1.1 ! mpls ldp router-id Loopback0 !
R3
! no mpls ldp advertise-labels mpls ldp advertise-labels for LOOPBACK0 mpls label protocol ldp ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface FastEthernet1/0 ip address 10.0.0.6 255.255.255.252 ip ospf network point-to-point mpls ip ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 10.0.0.4 0.0.0.3 area 0 ! ip access-list standard LOOPBACK0 permit 3.3.3.3 permit 1.1.1.1 permit 2.2.2.2 ! mpls ldp router-id Loopback0

By Zarar • CCIE SP, iPhone, iPod, MPLS • 2 • Tags: CCIE SP, MPLS

Jan 28 2009

Reserved MPLS labels

A table showing some of the more important reserved MPLS labels. I’ll add more on these labels in a later post.

Label Value	LDP	TDP
0	IPv4 Explicit Null	IPv4 Implicit Null
1	Router Alert	IPv4 Implicit Null
2	IPv6 Explicit Null	Router Alert
3	IPv4 Implicit Null	IPv6 Explicit Null

By zismail • CCIE SP, MPLS • 0 • Tags: CCIE SP, MPLS

Jan 14 2009

Virtual Private LAN service – VPLS

VPLS is a layer 2 VPN architecture which was designed for multipoint connectivity and broadcast capability.

Enterprisees who wish to appear connected on the same LAN segment can use this service.

Enterprise CE switches connect to PE routers who are enabled for VPLS. When you configure VPLS on a PE you are effectivley creating a virtual switch inside the router. CEs connect to the virtual switch via attachment circuits. In a single VPLS domain you may have multiple PEs ie multiple virtual switches connected together using pseudowires.

I’ve tried to explain the concept of VPLS using the diagram below.

By Zarar • CCIE SP, MPLS • 6 • Tags: CCIE SP, VPLS

Dec 28 2008

ARF – Automatic Route Filtering

When designing an MPLS network you will have to decide whether to configure a full mesh of MP-iBGP sessions between your PEs as in diagram 1 below or whether to use a hub and spoke topology as in diagram 2 below.

Diagram 1 – BGP full mesh

Diagram 2 – BGP partial mesh

The most obvious benefit of using a hub and spoke topology is that is scales a lot better than a full mesh topology. As you can see there are a lot less BGP sessions when using partial mesh design.

Automatic Route Filtering

iBGP sessions behave slightly differently with VPNv4 prefix than they do with IPv4 prefixes. Using diagram 2 as an example, In IPv4 world, R1 would send IPv4 prefixes to R3. These prefixes would be accepted by R3 and installed into the BGP table.

In VPNv4 world however this is not the case. In VPNv4 world when prefixes are learned from R1, R3 will reject(filter) the prefixes as R3 is not part of the VPN. ie R3 does not contain a vrf for those particular VPNv4 prefixes. This is known as Automatic Route Filtering, and guess what, its turned on by default. There are two ways to overcome this behavior. The first is to turn off ARF, the second is to configure R3 as a route-reflector. When you configure R3 as a route-reflector it turns ARF off by default.

Consider the toplogy below.

We will configure a VPNv4 session between R1 and R3. We will create a VPN on R1 called VPNA, which contains the prefix 192.168.1.0/24. We will redistribute this prefix into MP-BGP which will create a VPNv4 prefix and advertise it to R3. You will see by default that R3 rejects the route by default. To accept the route we will have to turn off ARF using the command below.

no bgp default route-target filter

Anyway, take a look at the video below and see ARF filtering the VPNv4 prefix or alternatively download it here and watch it on your iPod.

By zismail • BGP, CCIE SP, MPLS VPN • 3 • Tags: BGP, CCIE SP, MPLS VPN

Nov 26 2008

Controlling Label distribution

Unlike label filtering, controlling label distribution actually stops label bindings being advertised.

Consider the toplogy below.

Without controlling label distribution, PE2 will generate a label for all IGP and connected prefixes. PE2s LIB can be seen below.

PE2#show mpls ldp bindings lib entry: 1.1.1.1/32, rev 19 local binding: label: 17 remote binding: lsr: 2.2.2.2:0, label: 17 lib entry: 2.2.2.2/32, rev 20 local binding: label: 16 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 3.3.3.3/32, rev 21 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: 16 lib entry: 10.0.0.0/30, rev 22 local binding: label: 18 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 10.0.0.4/30, rev 23 local binding: label: imp-null remote binding: lsr: 2.2.2.2:0, label: imp-null PE2#

These labels are also propogated to P1 as you can see below.

P1#show mpls ldp bindings neighbor 3.3.3.3 lib entry: 1.1.1.1/32, rev 12 remote binding: lsr: 3.3.3.3:0, label: 17 lib entry: 2.2.2.2/32, rev 5 remote binding: lsr: 3.3.3.3:0, label: 16 lib entry: 3.3.3.3/32, rev 10 remote binding: lsr: 3.3.3.3:0, label: imp-null lib entry: 10.0.0.0/30, rev 7 remote binding: lsr: 3.3.3.3:0, label: 18 lib entry: 10.0.0.4/30, rev 8 remote binding: lsr: 3.3.3.3:0, label: imp-null

If we now add the following command to PE2 you will so no label binding being advertised to P1.

no mpls ldp advertise-labels

Lets take another looks at P1s LIB.

P1#show mpls ldp bindings neighbor 3.3.3.3

P1#

As you can see there are no labels learnt from PE2

In most cases however you will want to advertise at least the loopback address of PE2. This can be done in 3 steps.

Step 1 – on PE2 configure the following ACL.

ip access-list standard LOOPBACK0 permit 3.3.3.3 0.0.0.0

Step 2 – next attach the ACL to the MPLS label distribution configuration as below.

mpls ldp advertise-labels for LOOPBACK0

Step 3 – the third and final step is to stop advertising all the remaining labels using the command below.

no mpls ldp advertise-labels

Verify that you configuration has worked on P1. We should only see a binding for the loopback.

P1#show mpls ldp bindings neighbor 3.3.3.3 lib entry: 3.3.3.3/32, rev 10 remote binding: lsr: 3.3.3.3:0, label: imp-null

By zismail • CCIE SP, MPLS • 0 • Tags: CCIE SP, LDP, MPLS

1 2 3

MPLS

Categories

Tags