Juniper Multicast VPN User Manual

c s VPN User Guide for EX9200 Switches

Published

2021-04-18

ii

Juniper Networks, Inc. 1133 nn v n Way Sunnyvale, California 94089 USA

408-745-2000 www.juniper.net

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their r s c v owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this b c n without n c

Mc s VPN User Guide for EX9200 Switches

Copyright © 2021 Juniper Networks, Inc. All rights reserved.

The n rm n in this document is current as of the date on the page.

YEAR 2000 NOTICE

Juniper Networks hardware and s w r products are Year 2000 compliant. Junos OS has no known m r

m ns through the year 2038. However, the NTP c n is known to have some c y in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical						c m n	n consists of (or is intended for use
with) Juniper Networks s w r	Use of such s		w r	is subject to the terms and c n				ns of the End User License
Agreement ("EULA") posted at	s s	r	n r n	s	r	. By downloading, installing or using such
s w r you agree to the terms and c n		ns of that EULA.

iii

Table of Contents

1

2

About This Guide | viii

Overview

Understanding M c s VPNs | 2

MBGP M c s VPN Sites | 2

Mc s VPN Terminology | 3

Inclusive tree | 4

Sc v tree | 4

Understanding Layer 3 VPNs | 5

n r	c	n to	n	r n Layer 3 VPNs | 5
Layer 3 VPN			rm Support | 8
Supported Standards | 9
Supported M			c s VPN Standards | 9
n		r n	M	c s on Layer 3 VPNs
r	n	Next	n r	n MVPN VRF Import and Export Policies | 11
m	n	Routes to Be		v r s by an MVPN VRF Instance | 11

nr n VRF Route Targets for R n Instances for an MBGP MVPN | 12

Signaling Provider Tunnels in Next n r n MVPNs | 17

PIM Sparse Mode, PIM Dense Mode, Auto-RP, and BSR for MBGP MVPNs | 17

Example: n r n PIM Join Load Balancing on N x n r n M c s VPN | 18

Requirements | 18

Overview and Topology | 19

nr n | 22

r	c	n | 28
Example:	n	r n MBGP M c s VPNs | 30

Requirements | 30

Overview and Topology | 31

iv

nr n | 32

Understanding Redundant Virtual Tunnel Interfaces in MBGP MVPNs | 55

Example: n r n Redundant Virtual Tunnel Interfaces in MBGP MVPNs | 56

Requirements | 56

Overview | 56

nr n | 57

r c n | 68

s r b	n	Next	n r	n MVPN Routes | 71
n	r n	SPT-Only Mode for M			r c	BGP-Based M c s VPNs | 71
n	r n	Shared-Tree Data		s r b	n Across Provider Cores for Providers of MBGP MVPNs | 73
n	r n	Internet M	c s	Using Ingress R		c n Provider Tunnels | 75

Example:		n	r n	PIM State Limits | 79
Controlling PIM Resources for M					c s	VPNs Overview | 80
Example:			n	r n PIM State Limits | 83
	Requirements | 83
	Overview | 83
	n		r	n | 84
	r	c	n | 95
Understanding Wildcards to n r					S c	v	n	M	n LSPs for an MBGP MVPN | 97

nr n a S c v Provider Tunnel Using Wildcards | 103

Example:		n	r n S c v Provider Tunnels Using Wildcards | 104
n	r n	NLRI Parameters for an MBGP MVPN | 106
n	r n	R	n Instances for an MBGP MVPN | 107
n	r n	n	M	n LSPs for an MBGP MVPN | 108
n	r n	PIM Provider Tunnels for an MBGP MVPN | 115
n	r n	PIM-SSM GRE S		c v Provider Tunnels | 116
n	r n	r	Rosen VPNs | 118

Example: n r n PIM Join Load Balancing on r R s n M c s VPN | 118

Requirements | 118

3

4

v

Overview and Topology | 119

nr n | 123

r c n | 127

n	r n	GRE Tunnel Interfaces for Layer 3 VPNs | 130
n	r n	GRE Tunnels for Layer 3 VPNs | 130
r	b s	n
Tracing		r ns | 136
Tracing MBGP MVPN r c and r			ns | 136
Knowledge Base | 139
n	r	n Statements and	r	n Commands

nr n Statements | 141

v r s	r m m			n v n b	s | 142
create-new-ucast-tunnel | 144
export-target | 145
family (VRF			v r	s m n ) | 147
group (R		n	Instances) | 148
group-range (MBGP MVPN Tunnel) | 150
group-rp-mapping | 152
import-target | 154
inet-mvpn (BGP) | 155
inet-mvpn (VRF				v r s m n ) | 157
inet6-mvpn (BGP) | 158
inet6-mvpn (VRF				v r s m n ) | 159
n r ss r		c	n | 160
interface (Virtual Tunnel in R					n	Instances) | 162
label-switched-path-template (M						c s ) | 164
m s n	rn		m	c s | 166

vi

m c s (Virtual Tunnel in R		n	Instances) | 167
mvpn | 169
mvpn-mode | 172
pim-asm | 173
pim-ssm (S	c v Tunnel) | 174
primary (Virtual Tunnel in R		n	Instances) | 176
provider-tunnel | 178
register-limit | 184
route-target (Protocols MVPN) | 186
rpt-spt | 188
rsvp-te (R	n Instances Provider Tunnel S c v ) | 189

sc v | 191

sglimit | 194

source (R n Instances Provider Tunnel S c v ) | 196 spt-only | 197

sc s | 198

target (R		n	Instances MVPN) | 201
threshold-rate | 202
r c		ns (Protocols MVPN) | 204
tunnel-limit (R			n Instances Provider Tunnel S c v ) | 207
unicast (Route Target Community) | 209
unicast (Virtual Tunnel in R n Instances) | 210
vr	v r	s s	c v | 212

wildcard-group-inet | 213 wildcard-group-inet6 | 215

wildcard-source (S c v Provider Tunnels) | 217

vii

r n Commands | 219

rn M Commands | 219

Overview of Junos OS CLI

r n Mode Commands | 219

viii

About This Guide

The Junos r n	system (Junos OS) supports m c s VPN on the EX9200 switches. Use the topics
on this page to c n	r MBGP MVPN.

1

PART

Overview

Understanding M c s VPNs | 2

Understanding Layer 3 VPNs | 5

Supported Standards | 9

2

CHAPTER 1

Understanding M c s VPNs

IN THIS CHAPTER

MBGP M c s VPN Sites | 2

M c s VPN Terminology | 3

MBGP M

c s VPN Sites

The main c r c

r s

cs of MBGP MVPNs are:

•

They extend Layer 3 VPN service (RFC 4364) to support IP m

c s

for Layer 3 VPN service

providers.

•

They follow the same architecture as s c

by RFC 4364 for unicast VPNs. S

c c

y BGP is

used as the provider edge (PE) router-to-PE router control plane for m

c s

VPN.

•

They eliminate the requirement for the virtual router (VR) model (as s c

in Internet r

r

r s n v n mc s

M

c s in MPLS/BGP VPNs) for m

c s

VPNs and the RFC 4364 model for

unicast VPNs.

•

They rely on RFC 4364-based unicast with extensions for intra-AS and inter-AS c

mm

n c

n

An MBGP MVPN

n s two types of site sets, a sender site set and a receiver site set. These sites

have the following r

r

s

•

Hosts within the sender site set can originate m

c s

r c for receivers in the receiver site set.

•

Receivers outside the receiver site set should not be able to receive this

r

c

•

Hosts within the receiver site set can receive m

c s

r c originated by any host in the sender

site set.

•

Hosts within the receiver site set should not be able to receive m

c s

r

c originated by any

host that is not in the sender site set.

3

A site can be in both the sender site set and the receiver site set, so hosts within such a site can both originate and receive m c s r c For example, the sender site set could be the same as the receiver

site set, in which case all sites could both originate and receive m	c s r c from one another.
Sites within a given MBGP MVPN might be within the same r n z	n or in	r n r n z	ns

which means that an MBGP MVPN can be either an intranet or an extranet. A given site can be in more than one MBGP MVPN, so MBGP MVPNs might overlap. Not all sites of a given MBGP MVPN have to

be connected to the same service provider, meaning that an MBGP MVPN can span m	service
providers.

Feature parity for the MVPN extranet nc n y or overlapping MVPNs on the Junos Trio chipset is supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4.

Another way to look at an MBGP MVPN is to say that an MBGP MVPN is n by a set of

m n s r v policies. These policies determine both the sender site set and the receiver site set. These policies are established by MBGP MVPN customers, but implemented by service providers using the

x s n BGP and MPLS VPN infrastructure.

Release History Table

Release scr n

11.1R2 Feature parity for the MVPN extranet nc n y or overlapping MVPNs on the Junos Trio chipset is supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4.

RELATED DOCUMENTATION

Example: Allowing MBGP MVPN Remote Sources

Example: n r n a PIM-SSM Provider Tunnel for an MBGP MVPN

Mc s VPN Terminology

IN THIS SECTION

Inclusive tree | 4

S c v tree | 4

4

Inclusive tree

A single m c s s r b	n tree in the backbone that carries all the m	c s r c from a s	c
set of one or more m c s	VPNs. An inclusive tree that carries the r	c of more than one m	c s

VPN is an aggregate inclusive tree. An inclusive tree contains as its members all the PE routers that c to the receiver sites of any of the m c s VPNs using the tree.

Sc v tree

A single m		c s	s r b	n tree in the backbone that carries r				c belonging only to a s		c	set
of one or more m			c s	groups, from one or more m		c s	VPNs. An aggregate s		c v	tree carries
r	c for m	c s	groups that belong to		r n m	c s	VPNs. By default, r		c from most
m	c s groups could be carried by an inclusive tree, whereas r							c from high-bandwidth groups
should be carried by a s				c v tree.

5

CHAPTER 2

Understanding Layer 3 VPNs

IN THIS CHAPTER
	n r c n to	n r n Layer 3 VPNs | 5
	Layer 3 VPN	rm Support | 8

n r		c	n to	n	r n Layer 3 VPNs
To c	n	r	Layer 3 virtual private network (VPN)			nc n y you must enable VPN support on the
provider edge (PE) router. You must also c n r						any provider (P) routers that service the VPN, and
you must c			n r the customer edge (CE) routers so that their routes are distributed into the VPN.
To c	n	r	Layer 3 VPNs, you include the following statements:

description text; instance-type vrf; interface interface-name; protocols {

bgp {

group group-name { peer-as as-number; neighbor ip-address;

}

multihop ttl-value;

}

(ospf | ospf3) { area area {

interface interface-name;

}

domain-id domain-id; domain-vpn-tag number; sham-link {

local address;

6

}

sham-link-remote address <metric number>;

}

rip { rip-configuration;

}

}

route-distinguisher (as-number:id | ip-address:id); router-id address;

routing-options {

autonomous-system autonomous-system { independent-domain;

loops number;

}

forwarding-table {

export [ policy-names ];

}

interface-routes { rib-group group-name;

}

martians {

destination-prefix match-type <allow>;

}

maximum-paths { path-limit; log-interval interval; log-only;

threshold percentage;

}

maximum-prefixes { prefix-limit; log-interval interval; log-only;

threshold percentage;

}

multipath { vpn-unequal-cost;

}

options {

syslog (level level | upto level);

}

rib routing-table-name { martians {

7

destination-prefix match-type <allow>;

}

multipath { vpn-unequal-cost;

}

static { defaults {

static-options;

}

route destination-prefix { next-hop [next-hops]; static-options;

}

}

}

}

static { defaults {

static-options;

}

route destination-prefix { policy [ policy-names ]; static-options;

}

}

vrf-advertise-selective { family {

inet-mvpn; inet6-mvpn;

}

}

vrf-export [ policy-names ]; vrf-import [ policy-names ];

vrf-target (community | export community-name | import community-name); vrf-table-label;

You can include these statements at the following hierarchy levels:

•	[edit r	n ns nc s r	n ns nc n m ]
•	[edit logical-systems logical-system-name r			n ns nc s r	n ns nc n m ]

8

NOTE: The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

	The sham-link, sham-link-remote, and vr		v r s s c	v statements are not applicable in
	ACX Series routers.
For Layer 3 VPNs, only some of the statements in the [edit r				n ns nc s hierarchy are valid. For
the full hierarchy, see Junos OS R		n Protocols Library.
In	n to these statements, you must enable a signaling protocol, IBGP sessions between the PE

routers, and an interior gateway protocol (IGP) on the PE and P routers. By default, Layer 3 VPNs are disabled.

Many of the c n r n procedures for Layer 3 VPNs are common to all types of VPNs.

Layer 3 VPN	rm Support
Layer 3 VPNs are supported on most c mb n ns of Juniper Networks r		n	and switching	rms
and PICs capable of running the JUNOS S w r
MX Series routers c n	r to be in Ethernet services mode can support some of the Junos OS
Layer 3 VPN features. For Layer 3 VPNs, Ethernet services mode supports c		n	r n a loopback
interface for a VPN r	n and forwarding (VRF) instance. You can c n r	up to two VRF instances in
Ethernet services mode. Each VRF instance can handle up to 10,000 routes. The ping mpls l3vpn

rn mode command is also supported.

9

CHAPTER 3

Supported Standards

IN THIS CHAPTER

Supported M c s VPN Standards | 9

Supported M	c s VPN Standards
Junos OS s bs n	y supports the following RFCs and Internet r which n standards for

mc s virtual private networks (VPNs).

• RFC 6513, M c s in MPLS/BGP IP VPNs

•	RFC 6514, BGP Encodings and Procedures for M c s								in MPLS/BGP IP VPNs
•	RFC 6515, IPv4 and IPv6 Infrastructure Addresses in BGP Updates for M c s VPN
•	RFC 6625, Wildcards in M					c s VPN Auto-Discovery Routes
•	Internet	r	r	m	r n 3v	n mv n	s	v r 0	x	M	c s VPN Fast Upstream Failover
•	Internet	r	r	r	rw	3v n b	mv n	x r n	0	x	Extranet in BGP M c s VPN
	(MVPN)

RELATED DOCUMENTATION

Supported Carrier-of-Carriers and Interprovider VPN Standards

Supported VPWS Standards

Supported Layer 2 VPN Standards

Supported Layer 3 VPN Standards

Supported VPLS Standards

Supported MPLS Standards

Supported Standards for BGP

Accessing Standards Documents on the Internet

2

PART

r c s on Layer 3

VPNs

r n	Next		n r	n MVPN VRF Import and Export Policies | 11
Signaling Provider Tunnels in Next n r n MVPNs | 17
s r b	n	Next	n r	n MVPN Routes | 71
n	r n	r	Rosen VPNs | 118
n	r n	GRE Tunnel Interfaces for Layer 3 VPNs | 130

11

CHAPTER 4

r n Next n r n MVPN VRF Import and Export Policies

IN THIS CHAPTER

m	n Routes to Be v r s by an MVPN VRF Instance | 11
n	r n VRF Route Targets for R n Instances for an MBGP MVPN | 12

m

n

Routes to Be

v r

s

by an MVPN VRF Instance

If a hub-and-spoke deployment uses one VPN r

n

and forwarding (VRF) r n instance for unicast

r

n

and a separate VRF for MVPN r

n you need to limit the PE routers at the hub site to

v r s

only IPv4 MVPN routes, only IPv6 MVPN routes, or both. This is necessary to prevent the

m

c s

VRF instance from

v r s n unicast VPN routes to other PE routers.

NOTE: This c n r

n does not prevent the x

r

n of VPN routes to other VRF

instances on the same router if the auto-export statement is included in the [edit r n

ns hierarchy.

To c n

r

a VRF r

n instance with the name green to

v r s MVPN routes from both the inet

and inet6 address families, perform the following steps:

1.

n

r

the VRF r

n

instance to

v r

s

IPv4 routes.

user@host# set r

n

ns

nc s green vr

v r

s s

c v family inet-mvpn

2.

n

r

the VRF r

n

instance to

v r

s

IPv6 routes.

user@host# set r n ns nc s green vr v r s s c v family inet6-mvpn

12

r the c

n

r

n is c

mm

only the MVPN routes for the s

c

address families are

v r

s

from the VRF instance to remote PE routers. To remove the r s r c

n on routes being

v r

s

delete the vr

v r s s

c

v

statement.

NOTE: You cannot include the vr

v r

s s c v statement and the n

vr

v r

s

statement in the same VRF c n

r

n However, if you c n r

the vr

v r

s

s

c v

statement without any of its

ns the router has the same behavior as if you c

n

r

the

n

vr

v r

s

statement. VPN routes are prevented from being

v r

s

from a VRF r

n

instance to the remote PE routers.

RELATED DOCUMENTATION

family

inet-mvpn

inet6-mvpn

n vr	v	r	s
vr	v r	s	s c v

n r n VRF Route Targets for R n Instances for an MBGP MVPN

IN THIS SECTION

n r n the Export Target for an MBGP MVPN | 14

n r n the Import Target for an MBGP MVPN | 14

By default, the VPN r	n and forwarding (VRF) import and export route targets (c n		r	either
using VRF import and export policies or using the vrf-target statement) are used for m			r n	and
x r n routes with the MBGP MVPN network layer reachability n rm		n (NLRI).

You can use the export-target and import-target statements to override the default VRF import and export route targets. Export and import targets can also be s c s c c y for sender sites or

13

receiver sites, or can be borrowed from a c				n	r	unicast route target. Note that a sender site export
route target is always	v	r s	when security ss			c	n routes are exported.
NOTE: When you c n		r an MBGP MVPN r				n	instance, you should not c n r a target
value for an MBGP MVPN s			c c route target that is				n c to a target value for a unicast
route target c n	r	in another r		n	instance.

Specifying route targets in the MBGP MVPN NLRI for sender and receiver sites is useful when there is a mix of sender only, receiver only, and sender and receiver sites. A sender site route target is used for

x r n m c discovery routes by a sender site and for m r n m c discovery routes by a receiver site. A receiver site route target is used for x r n routes by a receiver site and m r n routes by a sender site. A sender and receiver site exports and imports routes with both route targets.

A provider edge (PE) router with sites in a s c c MBGP MVPN must determine whether a received

mc discovery route is from a sender site or receiver site based on the following:

•	If the PE router is c					n	r to be only in a sender site, route targets are imported only from
	receiver sites. Imported						m c discovery routes must be from a receiver site.
•	If the PE router is c					n	r to be only in a receiver site, route targets are imported only from
	sender sites. Imported						m c discovery routes must be from a sender site.
•	If a PE router is c				n	r	to be in both sender sites and receiver sites, these guidelines apply:
	• Along with an import route target, you can							n y c n	r whether the route target is from a
		receiver or a sender site.
	•	If a c n		r	n is not provided, an imported			m c discovery route is treated as belonging
		to both the sender site set and the receiver site set.
To c		n	r a route target for the MBGP MVPN r					n instance, include the route-target statement:

route-target { export-target {

target target-community; unicast;

}

import-target { target {

target-value;

receiver target-value; sender target-value;

}

14

unicast {

receiver;

sender;

}

You can include this statement at the following hierarchy levels:

•	[edit r	n ns	nc s r	n ns nc	n m	protocols mvpn]
•	[edit logical-systems logical-system-name r					n ns nc s r	n ns nc n m protocols mvpn]
The following s c			ns describes how to c		n r	the export target and the import target for an MBGP
MVPN:

nr n the Export Target for an MBGP MVPN

To c n

r an export target, include the export-target statement:

export-target {

target target-community;

unicast;

}
You can include this statement at the following hierarchy levels:
• [edit r	n ns	nc s r	n ns nc	n m	protocols mvpn route-target]
• [edit logical-systems logical-system-name r					n ns nc s r	n	ns	nc n m protocols mvpn
route target]
n r	the target	n to specify the export target community.				n	r	the unicast	n to use
the same target community that has been s				c	for unicast.

nr n the Import Target for an MBGP MVPN

To c n r an import target, include the import-target statement:

import-target {

target target-value { receiver;

sender;

}

unicast {

15

receiver;

sender;

}

}

You can include this statement at the following hierarchy levels:

•	[edit r	n	ns	nc s r	n ns nc	n m	protocols mvpn route-target]
•	[edit logical-systems logical-system-name r						n ns nc s r	n ns nc n m protocols mvpn
	route-target]
The following s			c	ns describe how to c n		r	the import target and unicast parameters:

nr n the Import Target Receiver and Sender for an MBGP MVPN

To c n r the import target community, include the target statement and specify the target community. The target community must by in the format target:x:y. The x value is either an IP address

or an AS number followed by an	n L to indicate a 4 byte AS number, and y is a number (for
example, target:123456L:100)

target target-value {

receiver;

sender;

}

You can include this statement at the following hierarchy levels:

•	[edit r	n ns nc s r	n ns nc n m	protocols mvpn route-target import-target]
•	[edit logical-systems logical-system-name r			n	ns	nc	s r	n ns nc n m protocols mvpn
	route-target import-target]
You can specify the target community used when m					r n	either receiver site sets or sender site sets
by including one of the following statements:
•	receiver—Specify the target community used when m					r	n	receiver site sets.
•	sender—Specify the target community used when m					r n	sender site sets.

16

nr n the Import Target Unicast Parameters for an MBGP MVPN

To c n

r a unicast target community as the import target, include the unicast statement:

unicast {

receiver;

sender;

	}
You can include this statement at the following hierarchy levels:
•	[edit r	n ns nc s r	n ns nc n m	protocols mvpn route-target import-target]
•	[edit logical-systems logical-system-name r			n ns nc	s r		n	ns nc n m protocols mvpn
	route-target import-target]
You can specify the unicast target community used when m					r n	either receiver site sets or sender
site sets by including one of the following statements:
•	receiver—Specify the unicast target community used when m					r	n	receiver site sets.
•	sender—Specify the unicast target community used when m					r	n	sender site sets.

17

CHAPTER 5

Signaling Provider Tunnels in Next n r n

MVPNs

IN THIS CHAPTER

PIM Sparse Mode, PIM Dense Mode, Auto-RP, and BSR for MBGP MVPNs | 17

Example:	n	r n	PIM Join Load Balancing on N x n r n M c s VPN | 18
Example:	n	r n	MBGP M c s VPNs | 30
Understanding Redundant Virtual Tunnel Interfaces in MBGP MVPNs | 55
Example:	n	r n	Redundant Virtual Tunnel Interfaces in MBGP MVPNs | 56

PIM Sparse Mode, PIM Dense Mode, Auto-RP, and BSR for MBGP MVPNs

You can c n r PIM sparse mode, PIM dense mode, auto-RP, and bootstrap router (BSR) for MBGP MVPN networks:

• PIM sparse mode—Allows a router to use any unicast r n protocol and performs reverse-path forwarding (RPF) checks using the unicast r n table. PIM sparse mode includes an explicit join message, so routers determine where the interested receivers are and send join messages upstream to their neighbors, building trees from the receivers to the rendezvous point (RP).

• PIM dense mode—Allows a router to use any unicast r		n protocol and performs reverse-path
forwarding (RPF) checks using the unicast r	n table. Packets are forwarded to all interfaces

except the incoming interface. Unlike PIM sparse mode, where explicit joins are required for packets

to be r nsm	downstream, packets are	to all routers in the r	n instance in PIM dense
mode.

• Auto-RP—Uses PIM dense mode to propagate control messages and establish RP mapping. You can c n r an auto-RP node in one of three r n modes: discovery mode, announce mode, and mapping mode.

18

• BSR—Establishes RPs. A selected router in a network acts as a BSR, which selects a unique RP for r n group ranges. BSR messages are using a data tunnel between PE routers.

RELATED DOCUMENTATION

Example: Allowing MBGP MVPN Remote Sources

Example: n r n a PIM-SSM Provider Tunnel for an MBGP MVPN

Example: n r n PIM Join Load Balancing on N x n r n

M c s VPN

IN THIS SECTION

Requirements | 18

Overview and Topology | 19

n r n | 22

r c n | 28

This example shows how to c n r m r n for external and internal virtual private network (VPN) routes with unequal interior gateway protocol (IGP) metrics and Protocol Independent M c s (PIM) join load balancing on provider edge (PE) routers running n x n r n m c s VPN (MVPN). This feature allows customer PIM (C-PIM) join messages to be load-balanced across available internal BGP (IBGP) upstream paths when there is no external BGP (EBGP) path present, and across available EBGP upstream paths when external and internal BGP (EIBGP) paths are present toward the source or rendezvous point (RP).

Requirements

This example uses the following hardware and s w r components:

•Three routers that can be a c mb n n of M Series, MX Series, or T Series routers.

•Junos OS Release 12.1 running on all the devices.

Before you begin:

1.

n

r the device interfaces.

19

2.

n r the following r

n protocols on all PE routers:

•OSPF

•MPLS

•LDP

•PIM

•BGP

3. n r a m c s VPN.

Overview and Topology

Junos OS Release 12.1 and later support m c n r n along with PIM join load balancing. This allows C-PIM join messages to be load-balanced across all available IBGP paths when there are only IBGP paths present, and across all available upstream EBGP paths when EIBGP paths are present toward

the source (or RP). Unlike	r R s n MVPN, n x n r n MVPN does not	z unequal EIBGP
paths to send C-PIM join messages. This feature is applicable to IPv4 C-PIM join messages.
By default, only one c v	IBGP path is used to send the C-PIM join messages for a PE router having

only IBGP paths toward the source (or RP). When there are EIBGP upstream paths present, only one

c v	EBGP path is used to send the join messages.
In a n x		n r	n MVPN, C-PIM join messages are translated into (or encoded as) BGP customer
m	c s (	m	c s ) MVPN routes and v r	s	with the BGP MCAST-VPN address family toward
the sender PE routers. A PE router originates a				m	c s MVPN route in response to receiving a C-

PIM join message through its PE router to customer edge (CE) router interface. The two types of

mc s MVPN routes are:

•Shared tree join route (C-*, C-G)

•Originated by receiver PE routers.

•Originated when a PE router receives a shared tree C-PIM join message through its PE-CE router interface.

•Source tree join route (C-S, C-G)

•Originated by receiver PE routers.

•Originated when a PE router receives a source tree C-PIM join message (C-S, C-G), or originated

by the PE router that already has a shared tree join route and receives a source c v autodiscovery route.

20

The upstream path in a n x		n r
s c	in Internet r	r

algorithm is performed as follows:

n MVPN is selected using the Bytewise-XOR hash algorithm as 3v n 254 b s mc s M c s in MPLS/BGP IP VPNs. The hash

1. The PE routers in the candidate set are numbered from lower to higher IP address, s r n from 0.

2.A bytewise exclusive-or of all the bytes is performed on the C-root (source) and the C-G (group) address.

3.The result is taken modulo n, where n is the number of PE routers in the candidate set. The result is N.

4.N represents the IP address of the upstream PE router as numbered in Step 1.

During load balancing, if a PE router with one or more upstream IBGP paths toward the source (or RP) discovers a new IBGP path toward the same source (or RP), the C-PIM join messages distributed among

previously	x s n IBGP paths get redistributed due to the change in the candidate PE router set.
In this example, PE1, PE2, and PE3 are the PE routers that have the m		PIM join load-balancing
feature c n	r Router PE1 has two EBGP paths and one IBGP upstream path, PE2 has one EBGP

path and one IBGP upstream path, and PE3 has two IBGP upstream paths toward the Source. Router CE4 is the customer edge (CE) router c to PE3. Source and Receiver are the Free BSD hosts.

On PE routers that have EIBGP paths toward the source (or RP), such as PE1 and PE2, PIM join load balancing is performed as follows:

1.The C-PIM join messages are sent using EBGP paths only. IBGP paths are not used to propagate the join messages.

In Figure 1 on page 22, the PE1 router distributes the join messages between the two EBGP paths to the CE1 router, and PE2 uses the EBGP path to CE1 to send the join messages.

2.If a PE router loses one or more EBGP paths toward the source (or RP), the RPF neighbor on the m c s tunnel interface is selected based on a hash mechanism.

On discovering the	rs	EBGP path, only new join messages get load-balanced across available EBGP
paths, whereas the	x s	n join messages on the m c s tunnel interface are not redistributed.

If the EBGP path from the PE2 router to the CE1 router goes down, PE2 sends the join messages to PE1 using the IBGP path. When the EBGP path to CE1 is restored, only new join messages that arrive on PE2 use the restored EBGP path, whereas join messages already sent on the IBGP path are not redistributed.

On PE routers that have only IBGP paths toward the source (or RP), such as the PE3 router, PIM join load balancing is performed as follows:

21

1. The C-PIM join messages from CE routers get load-balanced only as BGP			m	c s data messages
among IBGP paths.
In Figure 1 on page 22, assuming that the CE4 host is interested in receiving			r	c from the Source,
and CE4 n	s source join messages for	r n groups (Group 1 [C-S,C-G1] and Group 2 [C-S,C-

G2]), the source join messages arrive on the PE3 router.

Router PE3 then uses the Bytewise-XOR hash algorithm to select the upstream PE router to send the m c s data for each group. The algorithm rs numbers the upstream PE routers from lower to

higher IP address s r n from 0.

Assuming that Router PE1 router is numbered 0 and Router PE2 is 1, and the hash result for Group 1 and Group 2 join messages is 0 and 1, r s c v y the PE3 router selects PE1 as the upstream PE router to send Group 1 join messages, and PE2 as the upstream PE router to send the Group 2 join messages to the Source.

22

2. The shared join messages for	r n groups [C-*,C-G] are also treated in a similar way to reach the
s n n
Figure 1: PIM Join Load Balancing on N x		n r	n MVPN

n r n

IN THIS SECTION

CLI Quick n r n | 23