close

keyboard_arrow_left

Table of Contents Expand all

play_arrow Overview
- play_arrow Understanding Multicast
play_arrow Managing Group Membership
play_arrow Configuring Protocol Independent Multicast
- play_arrow Understanding PIM
  - PIM Overview
  - PIM on Aggregated Interfaces
- play_arrow Configuring PIM Basics
- play_arrow Routing Content to Densely Clustered Receivers with PIM Dense Mode
- play_arrow Routing Content to Larger, Sparser Groups with PIM Sparse Mode
- play_arrow Configuring Designated Routers
  - Understanding Designated Routers
  - Configuring a Designated Router for PIM
- play_arrow Receiving Content Directly from the Source with SSM
- play_arrow Minimizing Routing State Information with Bidirectional PIM
  - Example: Configuring Bidirectional PIM
- play_arrow Rapidly Detecting Communication Failures with PIM and the BFD Protocol
  - Configuring PIM and the Bidirectional Forwarding Detection (BFD) Protocol
- play_arrow Configuring PIM Options
  - Example: Configuring Nonstop Active Routing for PIM
  - Configuring PIM-to-IGMP and PIM-to-MLD Message Translation
- play_arrow Verifying PIM Configurations
play_arrow Configuring Multicast Routing Protocols
- play_arrow Connecting Routing Domains Using MSDP
  - Examples: Configuring MSDP
  - Configuring Multiple Instances of MSDP
- play_arrow Handling Session Announcements with SAP and SDP
  - Configuring the Session Announcement Protocol
  - Verifying SAP and SDP Addresses and Ports
- play_arrow Facilitating Multicast Delivery Across Unicast-Only Networks with AMT
  - Example: Configuring Automatic IP Multicast Without Explicit Tunnels
- play_arrow Routing Content to Densely Clustered Receivers with DVMRP
  - Examples: Configuring DVMRP
play_arrow Configuring Multicast VPNs
play_arrow General Multicast Options
- play_arrow Bit Index Explicit Replication (BIER)
- play_arrow Prevent Routing Loops with Reverse Path Forwarding
  - Examples: Configuring Reverse Path Forwarding
- play_arrow Use Multicast-Only Fast Reroute (MoFRR) to Minimize Packet Loss During Link Failures
- play_arrow Enable Multicast Between Layer 2 and Layer 3 Devices Using Snooping
- play_arrow Configure Multicast Routing Options
- play_arrow Controller-Based BGP Multicast Signaling
  - Controller-Based BGP Multicast Signaling
play_arrow Troubleshooting
- play_arrow Knowledge Base
  - Knowledge Search
  - JTAC Certified Step-by-Step Troubleshooting: Junos OS Multicast
play_arrow Configuration Statements and Operational Commands
- Junos CLI Reference Overview

list Table of Contents

English

Exchanging C-Multicast Routes

date_range 23-Nov-23

arrow_backward

arrow_forward

This section describes PE-PE distribution of Type 7 routes discussed in Signaling Provider Tunnels and Data Plane Setup.

In source-tree-only mode, a receiver provider edge (PE) router generates and installs a Type 6 route in its <routing-instance-name>.mvpn.0 table in response to receiving a (C-*, C-G) message from a local receiver, but does not advertise this route to other PE routers via BGP. The receiver PE router waits for a Type 5 route corresponding to the C-join.

Type 5 routes carry information about active sources and can be advertised by any PE router. In Junos OS, a PE router originates a Type 5 route if one of the following conditions occurs:

PE router starts receiving multicast data directly from a VPN multicast source.
PE router is the candidate rendezvous point (router) (candidate RP) and starts receiving C-PIM register messages.
PE router has a Multicast Source Discovery Protocol (MSDP) session with the candidate RP and starts receiving MSDP Source Active routes.

Once both Type 6 and Type 5 routes are installed in the <routing-instance-name>.mvpn.0 table, the receiver PE router is ready to originate a Type 7 route

Advertising C-Multicast Routes Using BGP

If the C-join received over a VPN interface is a source tree join (C-S, C-G), then the receiver PE router simply originates a Type 7 route (Step 7 in the following procedure). If the C-join is a shared tree join (C-*, C-G), then the receiver PE router needs to go through a few steps (Steps 1-7) before originating a Type 7 route.

Note that Router PE1 is the candidate RP that is conveniently located in the same router as the sender PE router. If the sender PE router and the PE router acting as (or MSDP peering with) the candidate RP are different, then the VPN multicast register messages first need to be delivered to the PE router acting as the candidate RP that is responsible for originating the Type 5 route. Routers referenced in this topic are shown in Understanding Next-Generation MVPN Network Topology.

A PE router that receives a (C-*, C-G) join message processes the message using normal C-PIM procedures and updates its C-PIM database accordingly.

Enter the show pim join extensive instance vpna 224.1.1.1 command on Router PE3 to verify that Router PE3 creates the C-PIM database after receiving the (*, 224.1.1.1) C-join message from Router CE3:

content_copy zoom_out_map
user@PE3> show pim join extensive instance vpna
224.1.1.1
Instance: PIM.vpna Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 224.1.1.1
    Source: *
    RP: 10.12.53.1
    Flags: sparse,rptree,wildcard
    Upstream protocol: BGP
	 Upstream interface: Through BGP
	 Upstream neighbor: Through MVPN
	 Upstream state: Join to RP
	 Downstream neighbors:
	     Interface: so-0/2/0.0
            10.12.87.1 State: Join Flags: SRW Timeout: Infinity

The (C-*, C-G) entry in the C-PIM database triggers the generation of a Type 6 route that is then installed in the <routing-instance-name>.mvpn.0 table by C-PIM. The Type 6 route uses the candidate RP IP address as the source.

Enter the show route table vpna.mvpn.0 detail | find 6:10.1.1.1 command on Router PE3 to verify that Router PE3 installs the following Type 6 route in the vpna.mvpn.0 table:

content_copy zoom_out_map
user@PE3> show route table vpna.mvpn.0 detail
| find 6:10.1.1.1
6:10.1.1.1:1:65000:32:10.12.53.1:32:224.1.1.1/240 (1 entry, 1 announced)
               *PIM     Preference: 105
								 Next hop type: Multicast (IPv4), Next hop index: 262144
								 Next-hop reference count: 11
								 State: <Active Int>
								 Age: 1d 1:32:58
								 Task: PIM.vpna
								 Announcement bits (2): 0-PIM.vpna 1-mvpn global task
							    AS path: I
								 Communities: no-advertise target:10.1.1.1:64

The route distinguisher and route target attached to the Type 6 route are learned from a route lookup in the <routing-instance-name>.inet.0 table for the IP address of the candidate RP.

Enter the show route table vpna.inet.0 10.12.53.1 detail command on Router PE3 to verify that Router PE3 has the following entry for C-RP 10.12.53.1 in the vpna.inet.0 table:

content_copy zoom_out_map
user@PE3> show route table vpna.inet.0 10.12.53.1
detail
vpna.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
10.12.53.1/32 (1 entry, 1 announced)
        *BGP     Preference: 170/-101
					   Route Distinguisher: 10.1.1.1:1
					   Next hop type: Indirect
					   Next-hop reference count: 6
					   Source: 10.1.1.1
					   Next hop type: Router, Next hop index: 588
					   Next hop: via so-0/0/3.0, selected
					   Label operation: Push 16, Push 299808(top)
					   Protocol next hop: 10.1.1.1
					   Push 16
                 Indirect next hop: 8da91f8 262143
                 State: <Secondary Active Int Ext>
                 Local AS: 65000 Peer AS: 65000
                 Age: 4:49:25 Metric2: 1
                 Task: BGP_65000.10.1.1.1+179
                 Announcement bits (1): 0-KRT
                 AS path: I
                 Communities: target:10:1 src-as:65000:0 rt-import:10.1.1.1:64
                 Import Accepted
                 VPN Label: 16
                 Localpref: 100
                 Router ID: 10.1.1.1
      			   Primary Routing Table bgp.l3vpn.0

After the VPN source starts transmitting data, the first PE router that becomes aware of the active source (either by receiving register messages or the MSDP source-active routes) installs a Type 5 route in its VRF mvpn table.

Enter the show route table vpna.mvpn.0 detail | find 5:10.1.1.1 command on Router PE1 to verify that Router PE1 has installed the following entry in the vpna.mvpn.0 table and starts receiving C-PIM register messages from Router CE1:

content_copy zoom_out_map
user@PE1> show route table vpna.mvpn.0 detail
| find 5:10.1.1.1
5:10.1.1.1:1:32:192.168.1.2:32:224.1.1.1/240 (1 entry, 1 announced)
         *PIM    Preference: 105
                 Next hop type: Multicast (IPv4)
                 Next-hop reference count: 30
                 State: <Active Int>
                 Age: 1d 1:36:33
                 Task: PIM.vpna
                 Announcement bits (3): 0-PIM.vpna 1-mvpn global task 2-BGP RT Background
                 AS path: I

Type 5 routes that are installed in the <routing-instance-name>.mvpn.0 table are picked up by BGP and advertised to remote PE routers.

Enter the show route advertising-protocol bgp 10.1.1.3 detail table vpna.mvpn.0 | find 5: command on Router PE1 to verify that Router PE1 advertises the following Type 5 route to remote PE routers:

content_copy zoom_out_map
user@PE1> show route advertising-protocol bgp
10.1.1.3 detail table vpna.mvpn.0 | find 5:
* 5:10.1.1.1:1:32:192.168.1.2:32:224.1.1.1/240 (1 entry, 1 announced)
         BGP group int type Internal
             Route Distinguisher: 10.1.1.1:1
             Nexthop: Self
             Flags: Nexthop Change
             Localpref: 100
             AS path: [65000] I
             Communities: target:10:1

The receiver PE router that has both a Type 5 and Type 6 route for (C-*, C-G) is now ready to originate a Type 7 route.

Enter the show route table vpna.mvpn.0 detail command on Router PE3 to verify that Router PE3 has the following Type 5, 6, and 7 routes in the vpna.mvpn.0 table.

The Type 6 route is installed by C-PIM in Step 2. The Type 5 route is learned via BGP in Step 5. The Type 7 route is originated by the MVPN module in response to having both Type 5 and Type 6 routes for the same (C-*, C-G). The route target of the Type 7 route is the same as the route target of the Type 6 route because both routes (IP address of the candidate RP [10.12.53.1] and the address of the VPN multicast source [192.168.1.2]) are reachable via the same router [PE1]). Therefore, 10.12.53.1 and 192.168.1.2 carry the same route target import (10.1.1.1:64) community

content_copy zoom_out_map
user@PE3> show route table vpna.mvpn.0 detail
5:10.1.1.1:1:32:192.168.1.2:32:224.1.1.1/240 (1 entry, 1 announced)
         *BGP     Preference: 170/-101
                  Next hop type: Indirect
                  Next-hop reference count: 4
                  Source: 10.1.1.1
                  Protocol next hop: 10.1.1.1
                  Indirect next hop: 2 no-forward
                  State: <Secondary Active Int Ext>
                  Local AS: 65000 Peer AS: 65000
                  Age: 1d 1:43:13 Metric2: 1
                  Task: BGP_65000.10.1.1.1+55384
                  Announcement bits (2): 0-PIM.vpna 1-mvpn global task
                  AS path: I
                  Communities: target:10:1
                  Import Accepted
                  Localpref: 100
                  Router ID: 10.1.1.1
                  Primary Routing Table bgp.mvpn.0

6:10.1.1.1:1:65000:32:10.12.53.1:32:224.1.1.1/240 (1 entry, 1 announced)
       *PIM      Preference: 105
                 Next hop type: Multicast (IPv4), Next hop index: 262144
                 Next-hop reference count: 11
                 State: <Active Int>
                 Age: 1d 1:44:09
                 Task: PIM.vpna
                 Announcement bits (2): 0-PIM.vpna 1-mvpn global task
                 AS path: I
                 Communities: no-advertise target:10.1.1.1:64

7:10.1.1.1:1:65000:32:192.168.1.2:32:224.1.1.1/240 (1 entry, 1 announced)
       *MVPN         Preference: 70
                Next hop type: Multicast (IPv4), Next hop index: 262144
                Next-hop reference count: 11
                State: <Active Int Ext>
                Age: 1d 1:44:09 Metric2: 1
                Task: mvpn global task
                Announcement bits (3): 0-PIM.vpna 1-mvpn global task 2-BGP RT Background
                AS path: I
                Communities: target:10.1.1.1:64

The Type 7 route installed in the VRF MVPN table is picked up by BGP and advertised to remote PE routers.

Enter the show route advertising-protocol bgp 10.1.1.1 detail table vpna.mvpn.0 | find 7:10.1.1.1 command on Router PE3 to verify that Router PE3 advertises the following Type 7 route:

content_copy zoom_out_map
user@PE3> show route advertising-protocol bgp
10.1.1.1 detail table vpna.mvpn.0 | find 7:10.1.1.1
* 7:10.1.1.1:1:65000:32:192.168.1.2:32:224.1.1.1/240 (1 entry, 1 announced)
         BGP group int type Internal
             Route Distinguisher: 10.1.1.3:1
             Nexthop: Self
             Flags: Nexthop Change
             Localpref: 100
             AS path: [65000] I
             Communities: target:10.1.1.1:64

If the C-join is a source tree join, then the Type 7 route is originated immediately (without waiting for a Type 5 route).

Enter the show route table vpna.mvpn.0 detail | find 7:10.1.1.1 command on Router PE2 to verify that Router PE2 originates the following Type 7 route in response to receiving a (192.168.1.2, 232.1.1.1) C-join:

content_copy zoom_out_map
user@PE2> show route table vpna.mvpn.0 detail
| find 7:10.1.1.1
7:10.1.1.1:1:65000:32:192.168.1.2:32:232.1.1.1/240 (1 entry, 1 announced)
          *PIM    Preference: 105
                  Next hop type: Multicast (IPv4), Next hop index: 262146
                  Next-hop reference count: 4
                  State: <Active Int>
                  Age: 2d 18:59:56
                  Task: PIM.vpna
                  Announcement bits (3): 0-PIM.vpna 1-mvpn global task 2-BGP RT Background
                  AS path: I
                  Communities: target:10.1.1.1:64

Receiving C-Multicast Routes

A sender PE router imports a Type 7 route if the route is carrying a route target that matches the locally originated route target import community. All Type 7 routes must pass the __vrf-mvpn-import-cmcast-<routing-instance-name>-internal__ policy in order to be installed in the <routing-instance-name>.mvpn.0 table.

When a sender PE router receives a Type 7 route via BGP, this route is installed in the <routing-instance-name>.mvpn.0 table. The BGP route is then translated back into a normal C-join inside the VRF table, and the C-join is installed in the local C-PIM database of the receiver PE router. A new C-join added to the C-PIM database triggers C-PIM to originate a Type 6 or Type 7 route. The C-PIM on the sender PE router creates its own version of the same Type 7 route received via BGP.

Use the show route table vpna.mvpn.0 detail | find 7:10.1.1.1 command to verify that Router PE1 contains the following entries for a Type 7 route in the vpna.mvpn.0 table corresponding to a (192.168.1.2, 224.1.1.1) join message. There are two entries; one entry is installed by PIM and the other entry is installed by BGP. This example also shows the Type 7 route corresponding to the (192.168.1.2, 232.1.1.1) join.

content_copy zoom_out_map
user@PE1> show route table vpna.mvpn.0 detail
| find 7:10.1.1.1
7:10.1.1.1:1:65000:32:192.168.1.2:32:224.1.1.1/240 (2 entries, 2 announced)
*PIM     Preference: 105
         Next hop type: Multicast (IPv4)
         Next-hop reference count: 30
         State: <Active Int>
         Age: 1d 2:19:04
         Task: PIM.vpna
         Announcement bits (2): 0-PIM.vpna 1-mvpn global task
         AS path: I
         Communities: no-advertise target:10.1.1.1:64
BGP      Preference: 170/-101
         Next hop type: Indirect
         Next-hop reference count: 4
         Source: 10.1.1.3
         Protocol next hop: 10.1.1.3
         Indirect next hop: 2 no-forward
         State: <Secondary Int Ext>
         Inactive reason: Route Preference
         Local AS: 65000 Peer AS: 65000
         Age: 53:27      Metric2: 1
         Task: BGP_65000.10.1.1.3+179
         Announcement bits (2): 0-PIM.vpna 1-mvpn global task
         AS path: I
         Communities: target:10.1.1.1:64
         Import Accepted
         Localpref: 100
         Router ID: 10.1.1.3
         Primary Routing Table bgp.mvpn.0
7:10.1.1.1:1:65000:32:192.168.1.2:32:232.1.1.1/240 (2 entries, 2 announced)
*PIM     Preference: 105
         Next hop type: Multicast (IPv4)
         Next-hop reference count: 30
         State: <Active Int>
         Age: 2d 19:21:17
         Task: PIM.vpna
         Announcement bits (2): 0-PIM.vpna 1-mvpn global task
         AS path: I
         Communities: no-advertise target:10.1.1.1:64
BGP      Preference: 170/-101
         Next hop type: Indirect
         Next-hop reference count: 4
         Source: 10.1.1.2
         Protocol next hop: 10.1.1.2
         Indirect next hop: 2 no-forward
         State: <Secondary Int Ext>
         Inactive reason: Route Preference
         Local AS: 65000 Peer AS: 65000
         Age: 53:27      Metric2: 1
         Task: BGP_65000.10.1.1.2+49165
         Announcement bits (2): 0-PIM.vpna 1-mvpn global task
         AS path: I
         Communities: target:10.1.1.1:64
         Import Accepted
         Localpref: 100
         Router ID: 10.1.1.2
         Primary Routing Table bgp.mvpn.0

Remote C-joins (Type 7 routes learned via BGP translated back to normal C-joins) are installed in the VRF C-PIM database on the sender PE router and are processed based on regular C-PIM procedures. This process completes the end-to-end C-multicast routing exchange.

Use the show pim join extensive instance vpna command to verify that Router PE1 has installed the following entries in the C-PIM database:

content_copy zoom_out_map
user@PE1> show pim join extensive instance vpna
Instance: PIM.vpna Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 224.1.1.1
    Source: 192.168.1.2
    Flags: sparse,spt
    Upstream interface: fe-0/2/0.0
    Upstream neighbor: 10.12.97.2
    Upstream state: Local RP, Join to Source
    Keepalive timeout: 201
    Downstream neighbors:
    Interface: Pseudo-MVPN

Group: 232.1.1.1
    Source: 192.168.1.2
    Flags: sparse,spt
    Upstream interface: fe-0/2/0.0
    Upstream neighbor: 10.12.97.2
    Upstream state: Local RP, Join to Source
    Keepalive timeout:
    Downstream neighbors:
    Interface: Pseudo-MVPN

Instance: PIM.vpna Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

arrow_backward PREVIOUS Distributing C-Multicast Routes Overview

NEXT arrow_forward Generating Source AS and Route Target Import Communities Overview

Multicast Protocols User Guide

ON THIS PAGE

Exchanging C-Multicast Routes

Advertising C-Multicast Routes Using BGP

Receiving C-Multicast Routes

Stay in touch

Helped me install or use the product
Accelerated my deployment

Discuss the product with a co-worker
Make a purchase inquiry

Multicast Protocols User Guide

ON THIS PAGE

Exchanging C-Multicast Routes

Advertising C-Multicast Routes Using BGP

Receiving C-Multicast Routes

Related Documentation

Stay in touch