Welcome back.
In the previous part, we had configured all service provider devices and got our first part of control plane information, populated by BGP.
This time, we are going to configure the rest: provider tunnel, PIM, start on a p-multicast source and request some groups by customers.
Type 1 Route
For the sake of the story continuation our last result is shown again:
show route table MVPN-NG
PE1PE3P2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
|
PE1> show route table MVPN-NG.mvpn.0 MVPN-NG.mvpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:1.1.1.1:51:1.1.1.1/240 *[MVPN/70] 1d 04:59:55, metric2 1 Indirect 1:2.2.2.2:51:2.2.2.2/240 *[BGP/170] 1d 04:59:53, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.120.20 via lt-0/0/0.120, label-switched-path PE1-PE2 1:20.20.20.20:51:20.20.20.20/240 *[BGP/170] 1d 04:59:55, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.120.20 via lt-0/0/0.120, Push 0 > |
|
PE3> show route table MVPN-NG.mvpn.0 MVPN-NG.mvpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:3.3.3.3:52:3.3.3.3/240 *[MVPN/70] 1d 05:01:15, metric2 1 Indirect 1:20.20.20.20:51:20.20.20.20/240 *[BGP/170] 1d 05:01:07, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.13.1 via lt-0/0/0.31, label-switched-path PE3-PE1 > |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
|
P2> show route table MVPN-NG.mvpn.0 MVPN-NG.mvpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:1.1.1.1:51:1.1.1.1/240 *[BGP/170] 1d 05:02:06, localpref 100, from 1.1.1.1 AS path: I, validation-state: unverified > to 198.66.120.1 via lt-0/0/0.201 1:2.2.2.2:51:2.2.2.2/240 *[BGP/170] 1d 05:02:04, localpref 100, from 2.2.2.2 AS path: I, validation-state: unverified > to 198.66.220.2 via lt-0/0/0.202 1:3.3.3.3:52:3.3.3.3/240 *[BGP/170] 1d 05:02:08, localpref 100, from 3.3.3.3 AS path: I, validation-state: unverified > to 198.66.120.1 via lt-0/0/0.201 1:20.20.20.20:51:20.20.20.20/240 *[MVPN/70] 1d 05:02:08, metric2 1 Indirect > |
As we knew already, Type 1 Route uses by some service provider device closely located to multicast source and a used to detemine with which PE shall inclusive PMSI (P-Multicast Service Interface) tunnels be established.
Provider tunnels for multicasts are unidirectional by nature of multicast and the most important pointĀ is to have Type 1 Routes from all NG-MVPN devices on our source – P2. Gladly, we see all of them: PE1, PE2 and PE3.
Provider tunnels
The type of tunnels will be RSVP-TE and we have to configure some statements on the source of tunnels only. Means those endpoints of tunnel support functionality of tunnel type – RSVP in our case.
An LSP template should be defined in support of dynamic nature of p2mp LSP – if new PE appears, then the source of LSP should be able toĀ include him dynamically on basis of Type 1 Routes information:
RSVP-TE Provider Tunnel Configuration
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
|
protocols { mpls { label-switched-path LSP_TEMPLATE_MVPN_1 { template; bandwidth 10m; class-of-service 7; p2mp; } } } routing-instances MVPN-NG { provider-tunnel { rsvp-te { label-switched-path-template { LSP_TEMPLATE_MVPN_1; } } } } |
The configuration is pretty straightforward: define the LSP template and order to use it forĀ any provider tunnels in that VRF.
As a result of such configuration LSP should be established immediately:
show mpls lsp p2mp [detail]
P2P2 detailPE1PE1 detail
|
P2> show mpls lsp p2mp Ingress LSP: 1 sessions P2MP name: 20.20.20.20:51:mvpn:MVPN-NG, P2MP branch count: 3 To From State Rt P ActivePath LSPname 1.1.1.1 20.20.20.20 Up 0 * 1.1.1.1:20.20.20.20:51:mvpn:MVPN-NG 2.2.2.2 20.20.20.20 Up 0 * 2.2.2.2:20.20.20.20:51:mvpn:MVPN-NG 3.3.3.3 20.20.20.20 Up 0 * 3.3.3.3:20.20.20.20:51:mvpn:MVPN-NG Total 3 displayed, Up 3, Down 0 P2> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
|
P2> show mpls lsp p2mp detail Ingress LSP: 1 sessions P2MP name: 20.20.20.20:51:mvpn:MVPN-NG, P2MP branch count: 3 1.1.1.1 From: 20.20.20.20, State: Up, ActiveRoute: 0, LSPname: 1.1.1.1:20.20.20.20:51:mvpn:MVPN-NG ActivePath: (primary) P2MP name: 20.20.20.20:51:mvpn:MVPN-NG LSPtype: Dynamic Configured, Penultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up, COS: 7 Priorities: 7 0 Bandwidth: 10Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 10) 198.66.120.1 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 198.66.120.1 2.2.2.2 From: 20.20.20.20, State: Up, ActiveRoute: 0, LSPname: 2.2.2.2:20.20.20.20:51:mvpn:MVPN-NG ActivePath: (primary) P2MP name: 20.20.20.20:51:mvpn:MVPN-NG LSPtype: Dynamic Configured, Penultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up, COS: 7 Priorities: 7 0 Bandwidth: 10Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 10) 198.66.220.2 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 198.66.220.2 3.3.3.3 From: 20.20.20.20, State: Up, ActiveRoute: 0, LSPname: 3.3.3.3:20.20.20.20:51:mvpn:MVPN-NG ActivePath: (primary) P2MP name: 20.20.20.20:51:mvpn:MVPN-NG LSPtype: Dynamic Configured, Penultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up, COS: 7 Priorities: 7 0 Bandwidth: 10Mbps SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 198.66.100.10 S 198.66.103.3 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 198.66.100.10 198.66.103.3 Total 3 displayed, Up 3, Down 0 P2> |
|
PE1> show mpls lsp p2mp egress Egress LSP: 3 sessions, 3 detours P2MP name: 20.20.20.20:51:mvpn:MVPN-NG, P2MP branch count: 1 To From State Rt Style Labelin Labelout LSPname 1.1.1.1 20.20.20.20 Up 0 1 SE 299936 3 1.1.1.1:20.20.20.20:51:mvpn:MVPN-NG Total 1 displayed, Up 1, Down 0 PE1> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
|
PE1> show mpls lsp p2mp detail egress Egress LSP: 3 sessions, 3 detours P2MP name: 20.20.20.20:51:mvpn:MVPN-NG, P2MP branch count: 1 1.1.1.1 From: 20.20.20.20, LSPstate: Up, ActiveRoute: 0 LSPname: 1.1.1.1:20.20.20.20:51:mvpn:MVPN-NG, LSPpath: Primary P2MP LSPname: 20.20.20.20:51:mvpn:MVPN-NG, Re-merge: Head Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: - Resv style: 1 SE, Label in: 299936, Label out: 3 Time left: 149, Since: Tue Mar 22 01:08:42 2016 Tspec: rate 10Mbps size 10Mbps peak Infbps m 20 M 1500 Port number: sender 1 receiver 58151 protocol 0 P2MP branch id: 1, Subgroup Originator: 20.20.20.20 PATH rcvfrom: 198.66.120.20 (lt-0/0/0.120) 18 pkts Adspec: received MTU 1500 PATH sentto: localclient RESV rcvfrom: localclient , Entropy label: Yes Record route: 198.66.120.20 <self> Total 1 displayed, Up 1, Down 0 PE1> |
Most interesting here, except a success, are paths chosen for LSPs – lines are highlighted above and paths are depicted below:

Because of our LSP template do not have any explicit constraints – RSV-based LSPs are presented with constrained-path type, in other words fully relies on IGP information.
Route Type 5
As I see, very useful from that point would be to configure a p-multicast source and receivers, so we could be sure that solid walls we will encounter (and we definitely will) exist not because there are no senders and receivers.
The Sender
On the station connected to the same network as ge-0/0/0.0 interface at P2 we are going to use the very small softwareĀ ideally applying to our environment and configure “NSend” in this manner:

Is the source registered?
|
P2> show pim source instance MVPN-NG detail Instance: PIM.MVPN-NG Family: INET Source 10.0.1.11 Prefix 10.0.1.0/24 Upstream interface ge-0/0/0.0 Upstream neighbor 10.0.1.3 Active groups: 231.0.0.1 Source 10.0.1.11 Prefix 10.0.1.0/24 Upstream interface ge-0/0/0.0 Upstream neighbor Direct P2> |
Receivers
In comparing with Cisco, where static IGMP should be configured on a separate node that represents a customer, on Juniper static IGMP group can be configured on PE itself, which is pretty useful and allows an administrator to test theĀ configuration without involving anyone.
IGMP static groups on PEs
PE1PE2PE3
|
PE1> show configuration protocols igmp interface all { disable; } interface ge-0/0/1.51 { version 2; static { group 231.0.0.1; } } PE1> |
|
PE2> show configuration protocols igmp interface all { disable; } interface ge-0/0/2.51 { version 2; static { group 231.0.0.1; group 231.0.0.3; } } PE2> |
|
PE3> show configuration protocols igmp interface all { disable; } interface ge-0/0/3.51 { version 2; static { group 231.0.0.3; } } PE3> |
Type 5
As a result of the source activation, the new MVPN NLRI has originated by P2 – Type 5.
Route Type 5
show routeextensive
|
PE1> show route table MVPN-NG.mvpn.0 MVPN-NG.mvpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ... ommited type 1 routes ... 5:20.20.20.20:51:32:10.0.1.11:32:231.0.0.1/240 *[BGP/170] 01:08:14, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.120.20 via lt-0/0/0.120, Push 0 PE1> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
|
PE1> show route table MVPN-NG.mvpn.0 match-prefix *231.0.0.1* extensive MVPN-NG.mvpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 5:20.20.20.20:51:32:10.0.1.11:32:231.0.0.1/240 (1 entry, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect Address: 0x97bffb8 Next-hop reference count: 6 Source: 20.20.20.20 Protocol next hop: 20.20.20.20 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 666 Peer AS: 666 Age: 1:17:56 Metric2: 1 Validation State: unverified Task: BGP_666.20.20.20.20+53662 Announcement bits (2): 0-PIM.MVPN-NG 1-mvpn global task AS path: I Communities: target:666:51 target:666:52 Import Accepted Localpref: 100 Router ID: 20.20.20.20 Primary Routing Table bgp.mvpn.0 Indirect next hops: 1 Protocol next hop: 20.20.20.20 Metric: 1 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 198.66.120.20 via lt-0/0/0.120 Session Id: 0x400002 20.20.20.20/32 Originating RIB: inet.3 Metric: 1 Node path count: 1 Forwarding nexthops: 1 Nexthop: 198.66.120.20 via lt-0/0/0.120 PE1> |
Route Type 5 originated by a PIM DR router after aĀ source has been registered successfully.
This options might be regulated by mvpn configuration – only the site marked as “sender-site” explicitly or without any explicit limitation allowed to originate Type 5.
|
P2> show routing-instances MVPN-NG protocols mvpn sender-site; P2> |
PIM
Seems like we have routes type 1 originating across and the provider point-to-multipoint tunnel has established as intended. The next step shall be done is to establish PIM neighborships between PE routers and P2.
The current PIM section under MVPN instance defines P2 loopback as static RP:
Basic PIM section at PE
|
PE1# show routing-instances MVPN-NG protocols pim rp { static { address 200.200.200.200 { version 2; group-ranges { 231.0.0.0/8; } } } } interface all { disable; } PE1# |
Obviously, anyone experienced with PIM would say: “It just can’t work without PIM interfaces enabled” and will be wrong.
Allow me to fixate that moment in outputs:
Basic PIM section at PE
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
|
PE1> show pim interfaces instance MVPN-NG PE1> show pim neighbors instance MVPN-NG B = Bidirectional Capable, G = Generation Identifier H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority, T = Tracking Bit Instance: PIM.MVPN-NG PE1> show pim rps instance MVPN-NG Instance: PIM.MVPN-NG address-family INET RP address Type Mode Holdtime Timeout Groups Group prefixes 200.200.200.200 static sparse 0 None 1 231.0.0.0/8 PE1> |
No interfaces are PIM enabled nor aĀ neighborship exists.
Moreover, some show commandsĀ tell us in a pretty straight way that configuration hasn’t ended yet:
|
PE1> show pim source instance MVPN-NG detail Source 200.200.200.200 Prefix unknown Upstream interface unknown Upstream neighbor unknown Active groups: 231.0.0.1 PE1> |
So, a high priority in PIM section is to ensure that PE routers are able toĀ exchange PIM requests with RP’s IP address – 200.200.200.200 (P2’s lo0.200 interface). But, as we decided at start “family inet-vpn unicast” is not enabled, so RP address is not originated by P2 and PE routers have no chance to recognize how to build RPT.
|
PE1> show route 200.200.200.200 PE1> |
What options do we have?
There is no LSP from PE to P2 – provider tunnels made by RSVP are unidirectional and may not be used to help us with the issue.
What if use resolution options, like in a case when lack some prefix in bgp.l3vpn.0 resolved by using inet.0? Nope, we don’t have “200.200.200.200” in any table, so a resolution is not a solution.
Well, feel free to share your ideas about how to cope with the issue in post comments, but here we are going to simply enable VPNv4 announces on P2 and PE routers.
|
set protocols bgp group RR family inet-vpn unicast |
Of course, now RP’s IP is available in the instance inet.0 table:
|
PE1> show route 200.200.200.200 MVPN-NG.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.200.200.200/32 *[BGP/170] 00:00:06, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.120.20 via lt-0/0/0.120, Push 16 PE1> |
Are PE routers able to recognise then how toĀ reach the RP?
Check information about source at PE
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
|
PE1> show pim source instance MVPN-NG detail Source 10.0.1.11 Prefix 10.0.1.0/24 Upstream protocol BGP Upstream interface Through BGP Upstream neighbor Through MVPN Active groups: 231.0.0.1 Source 200.200.200.200 Prefix 200.200.200.200/32 Upstream protocol BGP Upstream interface Through BGP Upstream neighbor Through MVPN Active groups: 231.0.0.1 PE1> |
The magic we watching here is about PIM – no PIM-enabled interfaces are presented, but links to MVPN information are in use instead: “Through BGP” and “Through MVPN“.
“10.0.1.11” above is the station with p-multicast source software running, but why 200.200.200.200 named as the source as well?
It is a classic PIM-SM behaviour: some moments at a start a path thru RP used to get multicast traffic. That called as shared tree and cause due the receiver don’t know yet an actual IP of a source, but RP address is known and that RP should know about all sources in the network. After a short delay, when multicast traffic successfully flows to receivers thru RP, a PE routerĀ takes source IP address from routed packets and might try to receive a flow without the RP in the middle. This behaviour manipulated by a configuration and in out situation it could be a reasonable option – RP located on the shortest path to the source, so SPT would never be better than RPT and no triggers shall switch from one to another:
|
PE1# set routing-instances MVPN-NG protocols mvpn mvpn-mode rpt-spt ? Possible completions: <[Enter]> Execute this command + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups spt-switch-timer Timeout before a PE router switches between RPT and SPT (0..60 seconds) | Pipe through a command [edit] PE# |
AlmostĀ done
All outputs above may be misconstrued as a happy end to the storyĀ because it seems the job is done: routers know all MVPN related information, the provider tunnel is up, PIM get used magic to figure out how to fill mandatory field without any PIM-enabled interfaces.
Furthermore, if check multicast route at P2 router, topology looks like totally converged:
|
P2> show multicast route instance MVPN-NG detail Group: 231.0.0.1 Source: 10.0.1.11/32 Upstream interface: ge-0/0/0.0 Downstream interface list: lt-0/0/0.202 lt-0/0/0.201 Session description: Unknown Statistics: 8 kBps, 63 pps, 873070 packets Next-hop ID: 1048623 Upstream protocol: MVPN P2> |
At line 7 – directly connected interfaces to PE2 (.202) and to PE1 (.201) are in downstream interface list, which is correct to initial scheme. PE3 is a receiver for 231.0.0.3 which is not streaming yet.
At line 9 and 11 – a lot of packets have been transmitted already!
So what is wrong?
After all, except the sending is important, a receiver side should be able to decapsulate labeled packet and decide somehow where a pack of multicast data should be send.
But PE routers aren’t capable of decapsulating and deciding which action should be done, because we don’t have any interface, except CE-faced.
|
PE1> show multicast route instance MVPN-NG Instance: MVPN-NG Family: INET PE1> |
Another way to prove that the multicast stream is notĀ sended to CE-faced interface is toĀ monitor interface dashboard:
monitor interface ge-0/0/1.51 @ PE1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
|
PE1> monitor interface ge-0/0/1.51 Next='n', Quit='q' or ESC, Freeze='f', Thaw='t', Clear='c', Interface='i' P1 Seconds: 26 Time: 16:52:03 Delay: 2/1/3 Interface: ge-0/0/1.51, Enabled, Link is Up Flags: SNMP-Traps 0x4000 Encapsulation: ENET2 VLAN-Tag [ 0x8100.51 ] Local statistics: Current delta Input bytes: 12900 [0] Output bytes: 17240 [0] Input packets: 215 [0] Output packets: 362 [0] Remote statistics: Input bytes: 2275712 (0 bps) [0] Output bytes: 10248192 (0 bps) [0] Input packets: 17779 (0 pps) [0] Output packets: 80064 (0 pps) [0] Traffic statistics: Input bytes: 2288612 [0] Output bytes: 10265432 [0] Input packets: 17994 [0] Output packets: 80426 [0] Protocol: inet, MTU: 1500, Flags: Is-Primary PE1> |
The column “Current delta” tells there is not transmitted data.
So, labeled multicast data arriving and simply dropped because a systemĀ has no point to inspect the data.
As far as I know, the problem with point of presense could be resolved in only one way – a special virtual interface called “VT” (virtual tunnel) should be added to a receiver’s service instance.
VT tunnel configuration
PE1PE2PE3
|
interfaces { vt-0/0/0 { unit 151 description "# MCAST_VIRTUAL_TUNNEL #"; family inet; } } routing-instances { MVPN-NG { interface vt-0/0/0.151 { multicast; } } } |
|
interfaces { vt-0/0/0 { unit 251 description "# MCAST_VIRTUAL_TUNNEL #"; family inet; } } routing-instances { MVPN-NG { interface vt-0/0/0.251 { multicast; } } } |
|
interfaces { vt-0/0/0 { unit 351 description "# MCAST_VIRTUAL_TUNNEL #"; family inet; } } routing-instances { MVPN-NG { interface vt-0/0/0.351 { multicast; } } } |
What if check PE1 multicast route again?
|
PE1> show multicast route instance MVPN-NG detail Instance: MVPN-NG Family: INET Group: 231.0.0.1 Source: 10.0.1.11/32 Upstream interface: vt-0/0/0.151 Downstream interface list: ge-0/0/1.51 Session description: Unknown Statistics: 8 kBps, 64 pps, 18760 packets Next-hop ID: 1048650 Upstream protocol: MVPN PE1> |
Seems like data is transmitted and VT-interface counts as an upstream.
monitor interface ge-0/0/1.51
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
|
Delay: 2/1/5 Interface: ge-0/0/1.51, Enabled, Link is Up Flags: SNMP-Traps 0x4000 Encapsulation: ENET2 VLAN-Tag [ 0x8100.51 ] Local statistics: Current delta Input bytes: 12960 [0] Output bytes: 17536 [0] Input packets: 216 [0] Output packets: 368 [0] Remote statistics: Input bytes: 3117056 (14392 bps) [0] Output bytes: 13948544 (65560 bps) [83072] Input packets: 25094 (15 pps) [390] Output packets: 108973 (64 pps) [649] Traffic statistics: Input bytes: 3130016 [0] Output bytes: 13966080 [83072] Input packets: 25310 [390] Output packets: 109341 [649] |
Henry Frankenstein: Look! It’s moving. It’s alive. It’s alive… It’s alive, it’s moving, it’s alive, it’s alive, it’s alive, it’s alive, IT’S ALIVE!
Route Type 6 and 7
Of course, multicast data shall be sentĀ only to explicit requests and that part Ā is provided by separate MVPN NLRI Types – 6 and 7.
types 6 and 7 in the MVPN table
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
|
PE1> show route table MVPN-NG.mvpn.0 MVPN-NG.mvpn.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ... ommited type 1 and 5 ... 6:20.20.20.20:51:666:32:200.200.200.200:32:231.0.0.1/240 *[PIM/105] 00:13:42 Multicast (IPv4) Composite 7:20.20.20.20:51:666:32:10.0.1.11:32:231.0.0.1/240 *[MVPN/70] 00:21:38, metric2 1 Multicast (IPv4) Composite [PIM/105] 00:16:41 Multicast (IPv4) Composite PE1> |
Route Type 6 is originated by receiver site as a request to get multicast stream via shared tree (*,G) = thru RP. BGP NLRI with Type 6 will not be sent to sender site until Type 5 for that source is presented. Route prefix “200.200.200.200:32:231.0.0.1” shall be written from right to left as “requesting group 231.0.0.1 from 200.200.200.200”. Type 6 route exists in receiver’s site routing table only.
As mentioned before, after shared tree getting work, receiver PE will try to get a multicast stream from the source directly via source tree (S,G), because now an IP of the source is known. In that last moment, receiver site will send Route Type 7 – “10.0.1.11:32:231.0.0.1“.
If MVPN infrastructure works in RPT-SPT mode, thenĀ type 6 must beĀ announced before type 7. If SPT-only is in use, then type 7 might be announced independently.
DoubleĀ group at PE2
As a desert lets assume how the delivery of two multicast streams could be presented for PE2.
- Source streams two groups: 231.0.0.1 and 231.0.0.3;
- P2 and PE2 exchanged Type 1 routes;
- P2 established a provider tunnel with PE2 as one of the ends;
- P2 originated both groups as Type 5 routes;
- PE2 have a customer requesting some groups;
- PE2 examined the IGMP group report and saw a request to participate in groups 231.0.0.1 and 231.0.0.3;
- PE2 examined service instance MVPN table and saw Type 5 route for both groups;
- PE2 originated Type 6 route as a request to build shared tree upon RP, which knows where is the source to requested groups;
- P2Ā started to forward multicast stream up toĀ PE2 router;
- PE2 performing some actions with data:
- receivingĀ labeled data;
- transferring to VT-interface
- pop all labels,
- sending again to VT-interface
- examine headers
- sending to a receiver
- other steps for a source tree.
What show command will tell us?
SHOWs
IGMP groupsMVPN routesMulticast route table
|
PE2> show igmp group terse Interface: ge-0/0/2.51, Groups: 2 Group: 231.0.0.1 Group: 231.0.0.3 PE2> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
|
PE2> show route table MVPN-NG.mvpn.0 MVPN-NG.mvpn.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:1.1.1.1:51:1.1.1.1/240 *[BGP/170] 01:02:35, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.102.10 via lt-0/0/0.210, label-switched-path PE2-PE1 to 198.66.220.20 via lt-0/0/0.220, label-switched-path PE2-PE1 1:2.2.2.2:51:2.2.2.2/240 *[MVPN/70] 2d 16:41:35, metric2 1 Indirect 1:20.20.20.20:51:20.20.20.20/240 *[BGP/170] 02:03:14, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.220.20 via lt-0/0/0.220, Push 0 5:20.20.20.20:51:32:10.0.1.11:32:231.0.0.1/240 *[BGP/170] 02:03:14, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.220.20 via lt-0/0/0.220, Push 0 5:20.20.20.20:51:32:10.0.1.11:32:231.0.0.3/240 *[BGP/170] 00:00:50, localpref 100, from 20.20.20.20 AS path: I, validation-state: unverified > to 198.66.220.20 via lt-0/0/0.220, Push 0 6:20.20.20.20:51:666:32:200.200.200.200:32:231.0.0.1/240 *[PIM/105] 00:06:54 Multicast (IPv4) Composite 6:20.20.20.20:51:666:32:200.200.200.200:32:231.0.0.3/240 *[PIM/105] 00:06:54 Multicast (IPv4) Composite 7:20.20.20.20:51:666:32:10.0.1.11:32:231.0.0.1/240 *[MVPN/70] 00:06:54, metric2 1 Multicast (IPv4) Composite [PIM/105] 00:06:54 Multicast (IPv4) Composite 7:20.20.20.20:51:666:32:10.0.1.11:32:231.0.0.3/240 *[MVPN/70] 00:00:50, metric2 1 Multicast (IPv4) Composite [PIM/105] 00:00:50 Multicast (IPv4) Composite PE2> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
|
PE2> show multicast route instance MVPN-NG detail Instance: MVPN-NG Family: INET Group: 231.0.0.1 Source: 10.0.1.11/32 Upstream interface: vt-0/0/0.251 Downstream interface list: ge-0/0/2.51 Session description: Unknown Statistics: 8 kBps, 64 pps, 24594 packets Next-hop ID: 1048652 Upstream protocol: MVPN Group: 231.0.0.3 Source: 10.0.1.11/32 Upstream interface: vt-0/0/0.251 Downstream interface list: ge-0/0/2.51 Session description: Unknown Statistics: 8 kBps, 64 pps, 1261 packets Next-hop ID: 1048652 Upstream protocol: MVPN Instance: MVPN-NG Family: INET6 PE2> |
Seems legit, isn’t it?
The end
That is actually all I have to show.
I really hope these 2 articles brought some interesting information to you and from that moment you get more familiar with the best known way to deliver multicast nowadays.
Sources
Configuration
PE2 full configuration
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144
|
interfaces { lt-0/0/0 { unit 210 { description "# PE2_P1 #"; encapsulation ethernet; peer-unit 102; family inet { address 198.66.102.2/24; } family mpls; } unit 220 { description "# PE2_P2 #"; encapsulation ethernet; peer-unit 202; family inet { address 198.66.220.2/24; } family mpls; } } vt-0/0/0 { unit 251 { description "# MCAST_VIRTUAL_TUNNEL #"; family inet; } } ge-0/0/2 { unit 51 { description "# MVPN-NG #"; vlan-id 51; family inet { address 10.2.51.2/24; } } } lo0 { unit 2 { description "# RID #"; family inet { address 2.2.2.2/32; } } } } protocols { igmp { interface all { disable; } interface ge-0/0/2.51 { version 2; static { group 231.0.0.1; group 231.0.0.3; } } } rsvp { interface lt-0/0/0.210; interface lt-0/0/0.220; interface all { disable; } } mpls { interface lt-0/0/0.210; interface lt-0/0/0.220; interface all { disable; } } bgp { keep none; mtu-discovery; group RR { type internal; local-address 2.2.2.2; mtu-discovery; family inet-vpn { unicast; } family inet-mvpn { signaling; } neighbor 20.20.20.20; } } ospf { traffic-engineering; area 0.0.0.2 { nssa; interface lt-0/0/0.210; interface lo0.2 { passive; } interface lt-0/0/0.220; } } } routing-instances { MVPN-NG { instance-type vrf; vrf-propagate-ttl; interface vt-0/0/0.251 { multicast; } interface ge-0/0/2.51; route-distinguisher 2.2.2.2:51; vrf-target target:666:51; protocols { pim { family inet6 { disable; } rp { static { address 200.200.200.200 { version 2; group-ranges { 231.0.0.0/8; } } } } interface all { disable; } } mvpn { family { inet6 { disable; } } receiver-site; } } } } routing-options { router-id 2.2.2.2; autonomous-system 666; } |