MPLS VPN

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

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 23 2008

Carrier Supporting Carrier – CSC

Carrier Supporting Carrier architecture is about connecting a single SPs POP sites using another Service Providers network.

In Carrier Supporting Carrier terminology, the service provider who connects another service providers POP sites is known as the backbone carrier.

The service provider whos POPs are connected via the backbone carrier is known as the customer carrier.

You might be thinking, whats the difference between inter-AS MPLS VPN and CSC.

Differences include

CSC connectes another ISPs POPs and not end customer sites. One might argue that the customer carrier whose POPs require connecting is the backbone carries customer and hence Inter is the same as CSC. Even if we made that statement, CSC still differs from Inter-AS in that CSC involves using one backbone carrier. Inter-AS however used 2 distinct “backbones” and the focus is how to connect these backbones. However looking at option 4 of Inter AS where you have a non VPN MPLS transit provider this is very similar to CSC.

Inter-AS MPLS VPN is only about MPLS VPN end customers, where as CSC is used for ISPs as well as VPN service providers.

Inter-AS MPLS VPN does not usually involve running MPLS between either the end customer and SPs or even between SPs themselves. Whereas CSC usually means running MPLS between the customer carrier and backbone carrier.

CSC also involves running an IGP between the backbone carrier and customer carrier. The IGP between the customer carrier and the backbone carrier is within a VRF on the backbone carrier side.

The backbone carrier can support multiple customer carriers.

There are two scenarios which require investigation.

Customer Carrier is VPN service provider
Customer Carrier is an Internet service provider and is not MPLS enabled

In all CSC scenarioes the backbone carrier is MPLS enabled.

By zismail • BGP, CCIE SP, MPLS VPN • 1 • Tags: BGP, CCIE SP, CSC, MPLS, MPLS VPN

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.

By zismail • CCIE SP, Inter-AS, MPLS VPN • 0 • Tags: BGP, CCIE SP, Inter-AS, MPLS VPN

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.

By zismail • CCIE SP, Inter-AS, MPLS VPN • 0 • Tags: BGP, CCIE SP, Inter-AS, MPLS VPN

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).

By zismail • BGP, CCIE SP, Inter-AS, MPLS VPN • 0 • Tags: BGP, CCIE SP, Inter-AS, MPLS VPN

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

By zismail • BGP, CCIE SP, Inter-AS, MPLS VPN • 0 • Tags: BGP, CCIE SP, Inter-AS, MPLS VPN

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.

By zismail • BGP, CCIE SP, Inter-AS, MPLS VPN • 0 • Tags: BGP, CCIE SP, Inter-AS, MPLS VPN

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.

By zismail • BGP, CCIE SP, Inter-AS, MPLS VPN • 0 • Tags: BGP, CCIE SP, Inter-AS, MPLS VPN

1 2

MPLS VPN

Categories

Tags