- play_arrow Overview
- play_arrow Managing Group Membership
- play_arrow Configuring IGMP and MLD
- play_arrow Configuring IGMP Snooping
- IGMP Snooping Overview
- Overview of Multicast Forwarding with IGMP Snooping or MLD Snooping in an EVPN-VXLAN Environment
- Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on EX Series Switches
- Verifying IGMP Snooping on EX Series Switches
- Changing the IGMP Snooping Group Timeout Value on Switches
- Monitoring IGMP Snooping
- Example: Configuring IGMP Snooping
- Example: Configuring IGMP Snooping on SRX Series Devices
- Configuring Point-to-Multipoint LSP with IGMP Snooping
- play_arrow Configuring MLD Snooping
- Understanding MLD Snooping
- Configuring MLD Snooping on an EX Series Switch VLAN (CLI Procedure)
- Configuring MLD Snooping on a Switch VLAN with ELS Support (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on SRX Series Devices
- Configuring MLD Snooping Tracing Operations on EX Series Switches (CLI Procedure)
- Configuring MLD Snooping Tracing Operations on EX Series Switch VLANs (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on Switches with ELS Support
- Verifying MLD Snooping on EX Series Switches (CLI Procedure)
- Verifying MLD Snooping on Switches
- play_arrow Configuring Multicast VLAN Registration
-
- play_arrow Configuring Protocol Independent Multicast
- play_arrow Understanding PIM
- play_arrow Configuring PIM Basics
- Configuring Different PIM Modes
- Configuring Multiple Instances of PIM
- Changing the PIM Version
- Optimizing the Number of Multicast Flows on QFabric Systems
- Modifying the PIM Hello Interval
- Preserving Multicast Performance by Disabling Response to the ping Utility
- Configuring PIM Trace Options
- Configuring BFD for PIM
- Configuring BFD Authentication for PIM
- play_arrow Routing Content to Densely Clustered Receivers with PIM Dense Mode
- play_arrow Routing Content to Larger, Sparser Groups with PIM Sparse Mode
- Understanding PIM Sparse Mode
- Examples: Configuring PIM Sparse Mode
- Configuring Static RP
- Example: Configuring Anycast RP
- Configuring PIM Bootstrap Router
- Understanding PIM Auto-RP
- Configuring All PIM Anycast Non-RP Routers
- Configuring a PIM Anycast RP Router with MSDP
- Configuring Embedded RP
- Configuring PIM Filtering
- Examples: Configuring PIM RPT and SPT Cutover
- Disabling PIM
- play_arrow Configuring Designated Routers
- play_arrow Receiving Content Directly from the Source with SSM
- Understanding PIM Source-Specific Mode
- Example: Configuring Source-Specific Multicast
- Example: Configuring PIM SSM on a Network
- Example: Configuring an SSM-Only Domain
- Example: Configuring SSM Mapping
- Example: Configuring Source-Specific Multicast Groups with Any-Source Override
- Example: Configuring SSM Maps for Different Groups to Different Sources
- play_arrow Minimizing Routing State Information with Bidirectional PIM
- play_arrow Rapidly Detecting Communication Failures with PIM and the BFD Protocol
- play_arrow Configuring PIM Options
- play_arrow Verifying PIM Configurations
-
- play_arrow Configuring Multicast Routing Protocols
- play_arrow Connecting Routing Domains Using MSDP
- play_arrow Handling Session Announcements with SAP and SDP
- play_arrow Facilitating Multicast Delivery Across Unicast-Only Networks with AMT
- play_arrow Routing Content to Densely Clustered Receivers with DVMRP
-
- play_arrow Configuring Multicast VPNs
- play_arrow Configuring Draft-Rosen Multicast VPNs
- Draft-Rosen Multicast VPNs Overview
- Example: Configuring Any-Source Draft-Rosen 6 Multicast VPNs
- Example: Configuring a Specific Tunnel for IPv4 Multicast VPN Traffic (Using Draft-Rosen MVPNs)
- Example: Configuring Source-Specific Draft-Rosen 7 Multicast VPNs
- Understanding Data MDTs
- Example: Configuring Data MDTs and Provider Tunnels Operating in Any-Source Multicast Mode
- Example: Configuring Data MDTs and Provider Tunnels Operating in Source-Specific Multicast Mode
- Examples: Configuring Data MDTs
- play_arrow Configuring Next-Generation Multicast VPNs
- Understanding Next-Generation MVPN Network Topology
- Understanding Next-Generation MVPN Concepts and Terminology
- Understanding Next-Generation MVPN Control Plane
- Next-Generation MVPN Data Plane Overview
- Enabling Next-Generation MVPN Services
- Generating Next-Generation MVPN VRF Import and Export Policies Overview
- Multiprotocol BGP MVPNs Overview
- Configuring Multiprotocol BGP Multicast VPNs
- BGP-MVPN Inter-AS Option B Overview
- ACX Support for BGP MVPN
- Example: Configuring MBGP MVPN Extranets
- Understanding Redundant Virtual Tunnel Interfaces in MBGP MVPNs
- Example: Configuring Redundant Virtual Tunnel Interfaces in MBGP MVPNs
- Understanding Sender-Based RPF in a BGP MVPN with RSVP-TE Point-to-Multipoint Provider Tunnels
- Example: Configuring Sender-Based RPF in a BGP MVPN with RSVP-TE Point-to-Multipoint Provider Tunnels
- Example: Configuring Sender-Based RPF in a BGP MVPN with MLDP Point-to-Multipoint Provider Tunnels
- Configuring MBGP MVPN Wildcards
- Distributing C-Multicast Routes Overview
- Exchanging C-Multicast Routes
- Generating Source AS and Route Target Import Communities Overview
- Originating Type 1 Intra-AS Autodiscovery Routes Overview
- Signaling Provider Tunnels and Data Plane Setup
- Anti-spoofing support for MPLS labels in BGP/MPLS IP VPNs (Inter-AS Option B)
- BGP-MVPN SD-WAN Overlay
- play_arrow Configuring PIM Join Load Balancing
- Use Case for PIM Join Load Balancing
- Configuring PIM Join Load Balancing
- PIM Join Load Balancing on Multipath MVPN Routes Overview
- Example: Configuring PIM Join Load Balancing on Draft-Rosen Multicast VPN
- Example: Configuring PIM Join Load Balancing on Next-Generation Multicast VPN
- Example: Configuring PIM Make-Before-Break Join Load Balancing
- Example: Configuring PIM State Limits
-
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
- play_arrow Configuration Statements and Operational Commands
ON THIS PAGE
BIER Forwarding
Overview
BIER forwarding is based on a bit string in the BIER header. Each bit set in the bit string represents a BFER (BIER Forwarding Egress Router) that should receive the multicast packet. The bit is mapped from a unique BFR-ID assigned to each BFER or BFIR. Note that a transit BIER Forwarding Router (BFR) that is neither a BFIR nor a BFER is not assigned a BFR-ID.
A BFR looks up the BIER Forwarding Table (BIFT) using the index of a set bit in the bit string of an incoming BIER packet. Since each bit set in the bit string corresponds to a specific BFR, the forwarding BFR is able to determine the neighbor the packet should be forwarded to.
The BIFT is created by calculating how each BFER is reached in the IGP routing underlay, e.g., a topology. A topology may have multiple BIER sub-domains, though a sub-domain is associated with only one topology. A BFR may belong to multiple sub-domains, and have different BFR-IDs for different sub-domains.
When the number of BFERs is greater than the BSL, multiple copies are sent, one for each set of BFERs. Each copy (for a different set of BFERs) uses a different BIFT for forwarding because the same bit in different copies is for different BFERs (e.g. bit-1 in copy-1 is for BFER 1 but in copy-2 it's for BFER 257, considering the BitStringLength is 256 bits).
An MPLS label is inserted at the start of the BIER header within an MPLS data plane to indicate that a BIER header is about to follow.
This BIER label also indicates which BIFT is to be used to forward the packets.
Routing protocol extensions are used to signal encapsulation information like BIER labels and calculate the BIFTs for all <sub-domain, BitStringLength, set> tuples that a BFR supports. The BIER information is attached to route advertisements of BFR prefixes i.e., loopback addresses.
When the route to a BFER prefix is calculated for a <sub-domain, BitStringLength> tuple, an entry is added to a corresponding BIFT with the key being (BFR-ID % BitStringLength) and the next hop information being <next hop neighbor, neighbor’s BIER label for the <sub-domain, BitStringLength, set>, neighbor’s F-BM>. The neighbor’s F-BM is the logical OR of bits of all BFERs in this set reached by this neighbor.
Let's take an example of a simple network topology that consists of six BFRs - A, B, C, D, E, and F to illustrate this concept.
Out of these, routers A, D, E, and F act as edge routers i.e. either BFER or BFIR. Each has a unique BFR-ID assigned: 1 for D, 2 for F, 3 for E, and 4 for A. The BSL (bitstringlength) is set to 4 bits, and the SI (Set-ID) is currently 0. All BFRS belong to sub-domain 32.
Each of these BFR-IDs are mapped to a bit in a 4 bit bit string. This translates to the following assignments:
Router D: 0:0001
Router F: 0:0010
Router E: 0:0100
Router A: 0:1000
The remaining BFRs (B and C) are transit BFRs and are not assigned BFR-IDs.
When BFR A sends a BIER packet to BFR B with bit string 0111, BFR B determines that the packet is meant for BFRs E, F, and D. BFR B then sends two copies of the same packet, one to BFR E and another to BFR C. The copy to BFR C is sent with an updated bit string 0011, which corresponds to BFRs D and F. When the packet reaches BFR C, it decides to send one copy of the packet to BFR D and another to BFR F.
This forwarding decision is based on the BIFT of BFR B.
Observe that the BIFT lists the BFR neighbors through which BFRs A, D, E, and F can be reached. The F-BM is the property of the BFR neighbor, which represents all the BFERs that are reachable through that neighbor. For instance, BFR neighbor C's F-BM is 0011 which means that BFR C can cover for BFER D and F. Router D has a F-BM of 0001 and BFR F has a F-BM of 0010. The F-BM of BFR C is the logical 'OR' of bits of all BFERs in this set reached by this neighbor which is 0011.
BIFT Route Lookup
Using the same example from above, when BFR A sends a BIER packet to BFR B with bit string 0111, BFR B uses the index of the lowest bit that is set in the incoming bit string (the right-most bit) to lookup the BIFT. The first entry (index one) in the routing table matches the lookup which implies that the BIER packet should be forwarded to BFR Neighbor C that has an F-BM of 0011. BFR B sends the copy to BFR C with the updated bit string 0011, which is the logical 'AND' of the incoming bit string and BFR C's F-BM.
Next, BFR B clears some bits in the incoming bit string using BFR C's F-BM, and uses the index of lowest set bit in the resulting bit string to lookup the BIFT.. The table lookup results in BFR-neighbor E with F-BM 0100. BFR B sends a copy to BFR E with the updated bit string 0100 which is a logical 'AND' operation of the incoming bit string and BFR-neighbor E's F-BM.
This process continues until the incoming bit string becomes all zero.
BIER forwarding in MVPN
Lets take an example to illustrate the flow of packets through MVPN tunnels.
On PE1 (ingress):
Issue the show mvpn instance vrf1 command to display
provider tunnel vrf1
information.
user@routerPE1> show mvpn instance vrf1
MVPN instance:
Instance : vrf1
MVPN Mode : SPT-ONLY
Sender-Based RPF: Disabled. Reason: Not enabled by configuration.
Hot Root Standby: Disabled. Reason: Not enabled by configuration.
Provider tunnel: I-P-tnl:BIER: subdomain-id 10 bfr-id 1 label 990001
Neighbor Inclusive Provider Tunnel Label-In St Segment
10.2.2.2 BIER: subdomain-id 10 bfr-id 2 bier-prefix 10.2.2.2 990001
10.3.3.3 BIER: subdomain-id 10 bfr-id 3 bier-prefix 10.3.3.3 990001
10.4.4.4
C-mcast IPv4 (S:G) Provider Tunnel Label-In St FwdNh Segment
172.11.21.21/32:232.252.1.1/32 BIER: subdomain-id 10 bfr-id 1 label 990001 RM M-8169
172.11.21.21/32:232.252.1.2/32 BIER: subdomain-id 10 bfr-id 1 label 990001 RM M-8169
172.11.21.21/32:232.252.2.1/32 BIER: subdomain-id 10 bfr-id 1 label 990001 RM M-8169
172.11.21.21/32:232.252.2.2/32 BIER: subdomain-id 10 bfr-id 1 label 990001 RM M-8169
Issue the show multicast route extensive instance vrf1
display-tunnel-name and show mvpn instance vrf1
display-tunnel-name to view the BIER tunnel's name.
The inclusive tunnel has two MVPN neighbors, 10.2.2.2 with BFR-ID 2 and 10.3.3.3 with BFR-ID 3. Therefore bits 2 and 3 are set. Neighbor 10.4.4.4 did not advertise any tunnels so it is not considered.
The label 990001 is configured
statically by issuing the set routing-instances
routing-instance-name vrf-table-label static
label statement.
In the FBM, 8 values are present for a bitstringlength of 256 bytes, separated by “:”, with each value representing 32 BFIR/BFERs.
Issue the show multicast route instance vrf1
extensive command to view multicast route
information.
user@routerPE1> show multicast route instance vrf1 extensive Instance: vrf1 Family: INET Group: 232.252.1.1 Source: 172.11.21.21/32 Upstream interface: et-0/0/10.1 Downstream interface list: Push 990001, BS:0:0:0:0:0:0:0:00000006, label 16 Number of outgoing interfaces: 1 Session description: Source specific multicast Statistics: 0 kBps, 1 pps, 44 packets Next-hop ID: 8169 Upstream protocol: MVPN Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: forever Wrong incoming interface notifications: 0 Uptime: 01:26:43 ......trimmed
A (172.11.21.21, 232.252.1.1) packet arriving in the VRF matches the above route. Label 990001 is imposed first, so that the egress PEs can find the corresponding VRF when they remove the BIER header. Then a BIER header is imposed with bit string 0:0:0:0:0:0:0:00000006 and BIER label 16, which is advertised by this BFIR for the sub-domain of the provider tunnel. The result is then treated as if it were a BIER packet received from another BFR.
Label 16 is looked up in the local mpls.0 table. Issue the
show route table mpls.0 protocol bier label 16 extensive command to view
the BIFT that is looked
up.
user@routerPE1> show route table mpls.0 protocol bier label 16 extensive mpls.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden) 16 (1 entry, 1 announced) TSI: KRT in-kernel 16 /52 -> {[6025]} Opaque data client: BIER Opaque data: TLV type:32820 APP flag:0x80 Address: 0x56026719ae20 Opaque-data reference count: 24 Stats ID Group: Kernel ID = 4097, Stats IDs = { 4026531842 } *BIER Preference: 70 Next hop type: Multicast (IPv4) Composite, Next hop index: 6025 Address: 0x560263988dc4 Next-hop reference count: 2, key opaque handle: 0x560269c537a0 Nexthop key opaque app data dump: TLV Type:32776, :bier-10-0.bier.0, Num of entries:256, 1-3, 2-8091, 3-8103, 4-8092 Kernel Table Id: 0 State: <Active OpaqueData> Local AS: 200 Age: 1:49:17 Validation State: unverified Task: bier global task Announcement bits (1): 1-KRT AS path: I Statistics - Packets: 0, pps: 0, Bytes: 0 Stats ID Group: Kernel ID = 4097, Stats IDs = { 4026531842 } Thread: junos-main
BFR-ID 2 and BFR-ID 3 are looked up in the BIFT
:bier-10-0.bier.0 and their corresponding push labels, and next hops are
determined. Issue the show route table :bier-10-0.bier.0 command to view
this next hop
information.
user@routerPE1> show route table :bier-10-0.bier.0
:bier-10-0.bier.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1/16
*[BIER/70] 01:56:21
to table mpls.0
2/16
*[BIER/70] 01:51:14
> to 10.1.2.2 via et-0/0/11.0, Push 16
to 10.1.2.2 via et-0/0/25.0, Push 16
3/16
*[BIER/70] 01:51:06
> to 10.1.2.2 via et-0/0/11.0, Push 16
to 10.1.5.5 via et-0/0/9.0, Push 16
to 10.1.2.2 via et-0/0/25.0, Push 16
4/16
*[BIER/70] 01:50:36
> to 10.1.5.5 via et-0/0/9.0, Push 16
To view the F-BM and it's BIER neighbors, issue the show route table
:bier-10-0.bier.0 extensive
command.
user@routerPE1> show route table :bier-10-0.bier.0 extensive :bier-10-0.bier.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 2/16 (1 entry, 0 announced) *BIER Preference: 70 Next hop type: List, Next hop index: 8091 Address: 0x560263986adc Next-hop reference count: 2, non-key opaque handle: 0x56026719b540 Nexthop nonkey opaque app data dump: TLV type:32829, Flag:0x4 Kernel Table Id: 0 Next hop: ELNH Address 0x56026337c87c, selected Next hop type: Router, Next hop index: 8083 Address: 0x56026337c87c Next-hop reference count: 2, key opaque handle: 0x560269c4eb80, non-key opaque handle: 0x560269c50ce0 Nexthop key opaque app data dump: TLV type:32794 APP data:Bier nbr 0x5602661cd418, label:16, Addr:10.2.2.2 Nexthop nonkey opaque app data dump: TLV type:32829, Flag:0x4, FBM:0:0:0:0:0:0:0:00000006 , Next-hop session id: 5 Kernel Table Id: 0 Next hop: 10.1.2.2 via et-0/0/11.0 Label operation: Push 16 Label TTL action: prop-ttl Load balance label: Label 16: None; Label element ptr: 0x560266949df0 Label parent element ptr: (nil) Label element references: 3 Label element child references: 0 Label element lsp id: 0 Statistics ID Group: Kernel ID = 4110, Stats IDs = { 4026531855 } ...trimmed
The F-BM can also be viewed by issuing the show bier
neighbor command.
The output also displays Packets(pps). In the example
output below, the packet counter for BIER neighbor 10.2.2.2 with next hop 10.1.2.2 shows
141753 while the other neighbors show null. This indicates the current
forwarding path for multicast traffic. After masking the bit string with it's F-BM, it is
forwarded to its neighbors with push label
16.
user@routerPE1> show bier neighbor BIER info: Subdomain ID: 10 BSL: 256 BIER Neighbor Label Nexthop Packets(pps) Bytes 10.2.2.2 16 10.1.2.2 141753( 1) 18711396 FBM:0:0:0:0:0:0:0:00000006 10.2.2.2 16 10.1.2.2 0( 0) 0 FBM:0:0:0:0:0:0:0:00000006 10.5.5.5 16 10.1.5.5 0( 0) 0 FBM:0:0:0:0:0:0:0:0000000c
On PE2:
The incoming label is looked up in the local mpls.0
table and the corresponding BIFT is determined. Issue the show route table mpls.0
protocol bier label 16 extensive command to view label 16's table
information.
user@routerPE2> show route table mpls.0 protocol bier label 16 extensive
mpls.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
16 (1 entry, 1 announced)
TSI:
KRT in-kernel 16 /52 -> {[6021]}
Opaque data client: BIER
Opaque data: TLV type:32820 APP flag:0x80
Address: 0x560719d9aac0
Opaque-data reference count: 24
Stats ID Group: Kernel ID = 4097, Stats IDs = { 4026531842 }
*BIER Preference: 70
Next hop type: Multicast (IPv4) Composite, Next hop index: 6021
Address: 0x56071658a084
Next-hop reference count: 2, key opaque handle: 0x56071c81ffe0
Nexthop key opaque app data dump: TLV Type:32776, :bier-10-0.bier.0, Num of entries:256, 1-9093, 2-3, 3-9082, 4-9140
Kernel Table Id: 0
State: <Active OpaqueData>
Local AS: 200
Age: 1:55:50
Validation State: unverified
Task: bier global task
Announcement bits (1): 1-KRT
AS path: I
Statistics - Packets: 0, pps: 0, Bytes: 0
Stats ID Group: Kernel ID = 4097, Stats IDs = { 4026531842 }
Thread: junos-main
Bits 2 and 3 are looked up in the BIFT :bier-10-0.bier.0.
For bit 2, the next hop is the local mpls.0 table and for bit 3, the next hop is PE3 with
push label 16. Issue the show route table :bier-10-0.bier.0 command to
verify this
information.
user@routerPE2> show route table :bier-10-0.bier.0
:bier-10-0.bier.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1/16
*[BIER/70] 02:00:43
> to 10.1.2.1 via et-0/0/11.0, Push 16
to 10.1.2.1 via et-0/0/24.0, Push 16
2/16
*[BIER/70] 02:05:35
to table mpls.0
3/16
*[BIER/70] 02:00:48
> to 10.2.3.3 via et-0/0/12.0, Push 16
4/16
*[BIER/70] 02:00:04
> to 10.2.3.3 via et-0/0/12.0, Push 16
to 10.2.5.5 via et-0/0/9.0, Push 16
For bit 2, the vrf label 990001 is looked up in the mpls.0
table to find its corresponding
vrf.
root@user@routerPE2> show route table mpls.0 label 990001
mpls.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
990001 *[VPN/0] 02:08:30
> via lsi.0 (vrf1), Pop
Issue the show multicast route instance vrf1 extensive
command to view the
route.
user@routerPE2> show multicast route instance vrf1 extensive
Instance: vrf1 Family: INET
Group: 232.252.1.1
Source: 172.11.21.21/32
Upstream interface: lsi.0
Downstream interface list:
et-0/0/10.1
Number of outgoing interfaces: 1
Session description: Unknown
Statistics: 0 kBps, 0 pps, 0 packets
Next-hop ID: 6017
Upstream protocol: MVPN
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 0
Uptime: 00:18:11
Sensor ID: 0xf0000017
ON PE3:
Similar to PE2, the incoming label is looked up in the
local mpls.0 table and the corresponding BIFT is determined. Issue the show route
table mpls.0 protocol bier label 16 extensive command to view label 16's table
information.
user@routerPE3> show route table mpls.0 label 16 extensive mpls.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) 16 (1 entry, 1 announced) TSI: KRT in-kernel 16 /52 -> {[6013]} Opaque data client: BIER Opaque data: TLV type:32820 APP flag:0x80 Address: 0x55c74399b1e0 Opaque-data reference count: 24 Stats ID Group: Kernel ID = 4097, Stats IDs = { 4026531842 } *BIER Preference: 70 Next hop type: Multicast (IPv4) Composite, Next hop index: 6013 Address: 0x55c740189184 Next-hop reference count: 2, key opaque handle: 0x55c74642ea20 Nexthop key opaque app data dump: TLV Type:32776, :bier-10-0.bier.0, Num of entries:256, 1-9088, 2-9085, 3-3, 4-9116 Kernel Table Id: 0 State: <Active OpaqueData> Local AS: 200 Age: 2:04:31 Validation State: unverified Task: bier global task Announcement bits (1): 1-KRT AS path: I Statistics - Packets: 0, pps: 0, Bytes: 0 Stats ID Group: Kernel ID = 4097, Stats IDs = { 4026531842 } Thread: junos-main
Issue the show route table
:bier-10-0.bier.0 command to view next hop information. Bit 3
is looked up in the BIFT and the next hop is the local mpls.0
table.
user@routerPE3> show route table :bier-10-0.bier.0
:bier-10-0.bier.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1/16
*[BIER/70] 02:06:09
> to 10.3.5.5 via ae0.0, Push 16
to 10.2.3.2 via et-0/0/11.0, Push 16
2/16
*[BIER/70] 02:06:15
> to 10.2.3.2 via et-0/0/11.0, Push 16
3/16
*[BIER/70] 02:10:46
to table mpls.0
4/16
*[BIER/70] 02:05:52
> to 10.3.4.4 via et-0/0/13.0, Push 16
The vrf label 990001 is looked up in the mpls.0 table, to
find the vrf for bit
3.
user@routerPE3> show route table mpls.0 label 990001
mpls.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
990001 *[VPN/0] 02:11:39
> via lsi.0 (vrf1), Pop
Issue the show multicast route instance vrf1 extensive
command to view the route in the
vrf.
user@routerPE3> show multicast route instance vrf1 extensive
Instance: vrf1 Family: INET
Group: 232.252.1.1
Source: 172.11.21.21/32
Upstream interface: lsi.0
Downstream interface list:
et-0/0/10.1
Number of outgoing interfaces: 1
Session description: Unknown
Statistics: 0 kBps, 0 pps, 0 packets
Next-hop ID: 6017
Upstream protocol: MVPN
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 0
Uptime: 00:21:33
Sensor ID: 0xf0000015