Example: NG-VPLS Using Point-to-Multipoint LSPs
This example provides a step-by-step procedure to configure next-generation VPLS using point-to-multipoint LSPs. The topology is shown in Figure 1 and Figure 2. This example is organized in the following sections:
Requirements
Table 1 lists the hardware that is used and the software that is required for this example:
Table 1: Hardware and Software Used
| Equipment | Components | Software |
|---|---|---|
Six MX Series routers | DPC-4 10GE-X, DPC-40 1GE-X | Junos OS Release 9.3R4 or later |
One T Series router | FPC3, 10GE-Xenpak | Junos OS Release 9.3R4 or later |
Eight EX4200 switches | EX4200 virtual switches | Junos OS Release 9.3R4 or later |
One M7i router | Gigabit Ethernet interfaces | Junos OS Release 9.3R4 or later |
Overview and Topology
The logical topology of the NG-VPLS example is shown in Figure 1.
Figure 1: Logical Topology of NG-VPLS Using Point-to-Multipoint LSPs
The routers in this example are preconfigured with the following:
- OSPF area 0 is configured on all the PE routers and P routers with traffic engineering enabled.
- All of the core-facing interfaces are configured with the mpls protocol address family.
- The RSVP and MPLS protocols are enabled for all the core-facing interfaces.
- All the MX Series routers have their network services mode set to Ethernet. The network services mode is configured by including the network-services statement and specifying the ethernet option.
- All the PE routers are configured for autonomous system 65000.
The physical topology of the NG-VPLS example is shown in Figure 2. The topology consists of six MX Series routers connected with redundant links in the core. Four MX Series routers are acting as PE routers and two are core routers.
Figure 2: Physical Topology of NG-VPLS Using Point-to-Multipoint LSPs
Note the following topology details:
- A route reflector is configured in the topology to reflect the family l2-vpn routes to all the PE routers for BPG-VPLS.
- The GOLD VPLS routing instance is configured with two sites in each of the PE routers.
- One GOLD site is connected to the CE router and the other one is directly connected to the test equipment on each PE router.
- The no-tunnel-services statement is included in the GOLD VPLS instance to enable the use of LSI interfaces for VPLS tunnel services.
- Router CE1 and Router CE2 are EX Series Virtual Chassis switches acting as CE routers.
- Router CE3 is an M7i router acting as a CE router.
- Two multicast sources are configured. One is connected to Router CE1 (Site 1) and the other to Router PE2 (Site 4) to simulate different scenarios.
- Router CE1 is configured as the rendezvous point (RP).
- Unicast traffic is enabled on all the test equipment ports and is sent to all the sites in the GOLD VPLS instance.
Configuration
This example provides a step-by-step procedure to configure next-generation VPLS using point-to-multipoint LSPs. It is organized in the following sections:
- Configuring the PE Router Interfaces
- Configuring a Route Reflector for all PE Routers for BGP-Based VPLS
- Establishing BGP-Based VPLS with a Route Reflector
- Configuring Point-to-Point LSPs Between PE Routers
- Configuring Dynamic and Static Point-to-Multipoint LSPs Between PE Routers
- Configuring Point-to-Multipoint Link Protection
- Configuring a BGP-Based VPLS Routing Instance for NG-VPLS
- Configuring Tunnel Services for VPLS
- Verifying the Control Plane
- Verifying the Data Plane
Configuring the PE Router Interfaces
Step-by-Step Procedure
On the customer-facing PE interfaces, enable VLAN tagging, configure the encapsulation type, and enable the VPLS address family. There are four possible interface encapsulations for VPLS routing instances that you can choose depending on your needs.
- If your network requires that each logical interface
on the PE router-to-CE router link be configured to only accept packets
with VLAN ID 1000, include the vlan-tagging statement,
include the encapsulation statement, and specify vlan-vpls as the encapsulation type. Also include the vlan-id statement
and specify 1000 as the VLAN ID.ge-1/1/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}
With this configuration, you can configure multiple logical interfaces with different VLAN IDs and associate each logical interface with a different routing instance.
- If your network requires each physical interface
on the PE router to CE router link to be configured to use the entire
Ethernet port as part of a single VPLS instance, include the encapsulation statement, and specify ethernet-vpls as the encapsulation
type. ge-1/2/0 {encapsulation ethernet-vpls;unit 0 {family vpls;}}
With this encapsulation mode, you cannot create multiple logical units (VLANs).
- If your network requires that each logical interface
of the single physical interface on the PE router to CE router link
be configured to use a mix of different encapsulations, include the encapsulation statement, and specify flexible-ethernet-services as the encapsulation type at the [edit interfaces interface-name] hierarchy level. Also include the encapsulation statement, and specify vlan-vpls or vlan-ccc as the encapsulation type at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.ge-1/2/0 {vlan-tagging;encapsulation flexible-ethernet-services;unit 1 {encapsulation vlan-vpls;}unit 2 {encapsulation vlan-ccc;}}
- If your network requires support for using a mix of single and dual tagged VLANs configured in different logical interfaces on a single physical interface, include the encapsulation statement, and specify flexible-vlan-tagging as the encapsulation type
- Configure the core-facing CE router interfaces.
The CE router and PE router logical interface configuration must match
encapsulation types and VLAN IDs. Typically the IP address is configured
on the core-facing CE router interfaces if the CE device is a router
and terminates the Layer 2 domain into the Layer 3 network. In this
example, the interface is configured for single tagging with a VLAN
ID of 1000.ge-1/1/0 {vlan-tagging;unit 1 {vlan-id 1000;family inet {address 40.40.40.1/24;}}}
Configuring a Route Reflector for all PE Routers for BGP-Based VPLS
Step-by-Step Procedure
Configuring a route reflector is the preferred method to enable any BGP-based service offerings. Configuring a route reflector avoids the requirement for a full mesh of BGP peer sessions, and it scales well. BGP redundancy can be achieved using multiple route reflectors in a single cluster.
- To enable BGP to carry Layer 2 VPN and VPLS NLRI
messages, create a peer group, include the family statement,
specify the l2vpn option, and include the signaling statement. To configure the route reflector cluster and complete
the BGP peer sessions, include the cluster statement and
specify the IP address for the cluster ID. Then include the neighbor statement and specify the IP address of the PE routers that are
BGP client peers in the cluster.bgp {group RR {type internal;local-address 7.7.7.7;family l2vpn {signaling;}cluster 7.7.7.7;neighbor 1.1.1.1; # To PE1neighbor 2.2.2.2; # To PE2neighbor 3.3.3.3; # To PE3neighbor 4.4.4.4; # To PE4}}
- Configure OSPF and enable traffic engineering
on the route reflector to create the Constrained Shortest Path First
(CSPF) database for the egress LSPs terminating from the PE routers.ospf {traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}}
- Enable the MPLS and RSVP protocols on
all interfaces connected to the MPLS core. This terminates the RSVP
egress LSPs from the PE routers.rsvp {interface all;interface fxp0.0 {disable;}}mpls {interface all;interface fxp0.0 {disable;}}
Establishing BGP-Based VPLS with a Route Reflector
Step-by-Step Procedure
For BGP-based VPLS, all PE routers need to have a full mesh of BGP peer sessions with each other or have a single peer with the route reflector. The route reflector reflects the routes received from the other PE routers. In this example, the PE router is configured to establish a peer relationship with the route reflector.
- To have the all the PE routers establish a BGP
client peer session with the route reflector, create an internal peer
group, include the local-address statement, and specify the
IP address of the PE router. Also include the neighbor statement,
and specify the IP address of the route reflector. To enable BGP to
carry Layer 2 VPN and VPLS NLRI messages, include the family statement, specify the l2vpn option, and include the signaling statement.bgp {group to-RR {type internal;local-address 1.1.1.1;family l2vpn {signaling;}neighbor 7.7.7.7; # To the route reflector}}
- Configure a point-to-point RSVP LSP from
the PE routers to the route reflector. To create the LSP, include
the label-switched-path statement, give the LSP a meaningful
name, include the to statement and specify the IP address
of the route reflector as the LSP end point. This LSP is needed to
resolve the BGP next hops in the inet.3 routing table for
the routes received from the route-reflector.mpls {label-switched-path to-RR {to 7.7.7.7;}interface all;interface fxp0.0 {disable;}}
Configuring Point-to-Point LSPs Between PE Routers
Step-by-Step Procedure
In next-generation VPLS, point-to-multipoint LSPs are only used to transport broadcast, multicast, and unknown unicast frames. All other frames are still transported using point-to-point RSVP LSPs. This is a more efficient use of bandwidth, particularly near the source of the unknown, broadcast, and multicast frames. The trade-off is more state in the network, because each PE router is the ingress of one point-to-multipoint LSP that touches all other PE routers, and n point-to-point LSPs are needed, one going to each of the other PE routers.
- To create a point-to-point LSP, include the label-switched-path statement, give the LSP a meaningful name,
include the to statement, and specify the IP address of the
other PE router as the LSP endpoint. The example shows the configuration
of LSPs from Router PE1 to Routers PE2, PE3, and PE4.mpls {label-switched-path to-PE2 {to 2.2.2.2;}label-switched-path to-PE3 {to 3.3.3.3;}label-switched-path to-PE4 {to 4.4.4.4;}}
Configuring Dynamic and Static Point-to-Multipoint LSPs Between PE Routers
Step-by-Step Procedure
This procedure describes how to enable the creation of dynamic point-to-multipoint LSPs and how to configure static point-to-multipoint LSPs. On a router configured with static point-to-multipoint LSPs, the LSPs come up immediately. On a router configured with dynamic point-to-multipoint LSPs, the LSP come up only after receiving BGP neighbor information from the route reflector or from the other PE routers participating in the VPLS domain.
For each VPLS instance, a PE router with dynamic point-to-multipoint LSPs enabled creates a dedicated point-to-multipoint LSP based on the point-to-multipoint template. Whenever VPLS discovers a new neighbor through BGP, a sub-LSP for this neighbor is added to the point-to-multipoint LSP.
If there are n PE routers in the VPLS instance then the router creates n point-to-multipoint LSPs in the network where each PE router is the root of the tree and includes the rest of the n-1 PE routers as leaf nodes connected through a source-to-leaf sub-LSP.
- In this step, you configure Router PE1 and Router
PE2 to use a dynamic point-to-multipoint LSP template for LSP creation.
When these routers receive a new BGP route advertised from the route
reflector for a new neighbor, they create a point-to-multipoint sub-LSP
to that neighbor. To create the dynamic point-to-multipoint LSP template,
include the label-switched-path statement, give the LSP template
a meaningful name, include the template statement and include
the p2mp statement. Also enable link protection and configure
the optimize timer to periodically reoptimize the LSP path.mpls {label-switched-path vpls-GOLD-p2mp-template {template; # identify as a templateoptimize-timer 50;link-protection; # link protection is enabled on point-to-multipoint LSPsp2mp;}
- In this step, you configure static point-to-multipoint
LSPs. Creating static point-to-multipoint LSPs is similar to creating
point-to-point LSPs, except you can also configure other RSVP parameters
under each point-to-multipoint LSP.
To create static point-to-multipoint LSPs, include the label-switched-path statement, give the LSP a meaningful name, include the to statement, and specify the IP address of the PE router that is the endpoint of the LSP. Also include the p2mp statement and specify a pathname.
mpls {label-switched-path to-pe2 {to 2.2.2.2;p2mp vpls-GOLD;}label-switched-path to-pe3 {to 3.3.3.3;p2mp vpls-GOLD;}label-switched-path to-pe1 {to 1.1.1.1;p2mp vpls-GOLD;}
Configuring Point-to-Multipoint Link Protection
Step-by-Step Procedure
Point-to-multipoint LSPs only support RSVP link protection for traffic engineering. Node protection is not supported. Link protection is optional, but it is the recommended configuration for most networks.
- To enable link protection on the core-facing interfaces,
include the link-protection statement at the [edit protocols
rsvp interface interface-name] hierarchy level.rsvp {interface all;interface fxp0.0 {disable;}interface xe-0/3/0.0 {link-protection;}interface xe-0/2/0.0 {link-protection;}interface xe-0/1/0.0 {link-protection;}}
- Enable the point-to-multipoint LSP to
use the RSVP link protection feature. Link-protection can be configured
for both static point-to-multipoint and dynamic point-to-multipoint
LSPs that use a template.
For static point-to-multipoint LSPs, configure each branch sub-LSP. To enable link protection, include the link-protection statement at the [edit protocols mpls label-switched-path label-switched-path-name] hierarchy level.
label-switched-path to-pe2 {to 2.2.2.2;link-protection;p2mp vpls-GOLD;}label-switched-path to-pe3 {to 3.3.3.3;link-protection;p2mp vpls-GOLD;}label-switched-path to-pe1 {to 1.1.1.1;link-protection;p2mp vpls-GOLD;} - For dynamic point-to-multipoint LSPs
using a template, only the template needs to have link protection
configured. All the point-to-multipoint branch LSPs that use the template
inherit this configuration.
To enable link protection for dynamic point-to-multipoint LSPs, include the link-protection statement at the [edit protocols mpls label-switched-path label-switched-path-name] hierarchy level.
label-switched-path vpls-GOLD-p2mp-template {template;optimize-timer 50;link-protection;p2mp;}
Configuring a BGP-Based VPLS Routing Instance for NG-VPLS
Step-by-Step Procedure
For NG-VPLS, the routing-instance configuration is similar to that for a regular VPLS routing instance. The routing instance defines the VPLS site and creates the VPLS connection. The following parameters are configured.
- Instance Type – VPLS.
- Interface – The interface connecting to the CE router.
- Route Distinguisher – Each routing instance you configure on a PE router must have a unique route distinguisher. The route distinguisher is used by BGP to distinguish between potentially identical network reachability information (NLRI) messages received from different VPNs. If you use a unique route distinguisher for each routing instance on each PE, you can determine which PE originated the route.
- VRF Target – Configuring a VRF target community using the vrf-target statement causes default VRF import and export policies to be generated that accept imported routes and tag exported routes with the specified target community.
- Protocols – Configure the VPLS protocol as described in the following procedure.
- To configure the NG-VPLS routing instance,
include the routing-instances statement and specify the instance
name. Also include the instance-type statement and specify vpls as the type. Optionally, you can include the route-distinguisher statement and specify a route distinguisher that is unique throughout
all VPNs configured on the router. Configure a VRF route target by
including the vrf-target statement and specify the route
target. The route target exported by one router must match the route
target imported by another router for the same VPLS.routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;vrf-target target:65000:1;}}
- To use a point-to-multipoint LSP for
VPLS flooding, configure an LSP under the VPLS routing instance.
To configure the point-to-multipoint LSP for VPLS flooding, include the label-switched-path-template statement and specify the name of the LSP template at the [edit routing-instances routing-instances-name provider-tunnel rsvp-te] hierarchy level.
routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;}} - Configuring the VPLS protocol enables
the VPLS between different sites in the VPLS domain. Multiple sites
can be configured under a single VPLS routing instance, but note that
the lowest site ID is used to build the VPLS pseudowire to the other
PE routers, and the label block associated with the lowest site ID
is advertised. The following parameters are configured for the VPLS
protocol:
- Site – Name of the VPLS site.
- Site Range – Maximum site ID allowed in the VPLS. The site range specifies the highest-value site ID allowed within the VPLS, not the number of sites in the VPLS.
- Site Identifier – Any number between 1 and 65,534 that uniquely identifies the VPLS site. This is also referred as the VE-ID in the relevant RFC.
- PE-CE Interface – The interface participating in this site.
- Tunnel services for VPLS – If you do not configure any tunnel interface at the [edit protocol vpls tunnel-services] hierarchy, the router uses any tunnel interface available on the router for VPLS.
- No-tunnel-services – If you include the no-tunnel-services statement, the router uses a label-switched interface (LSI) for the tunnel services for that VPLS instance.
- Mac Table Size – The size of the VPLS media access control (MAC) address table. The default is 512 addresses and the maximum is 65,536. When the table is full, new MAC addresses are no longer added to the table.
To configure the VPLS protocol, include the vpls statement at the [edit routing-instances routing-instance-name protocols] hierarchy level. To configure the site range, include the site-range statement and specify the highest-value site ID allowed within the VPLS. To cause the router to use an LSI interface, include the no-tunnel-services statement. To create a VPLS site, include the site statement and specify a site name. Also include the site-identifier statement and specify the site ID. Then include the interface statement and specify the interface name for the interface connected to the CE device.
routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;protocols {vpls {site-range 8;no-tunnel-services;site CE1 {site-identifier 1;interface ge-1/0/0.1;}site Direct {site-identifier 2;interface ge-1/1/0.1;}}}}}
Configuring Tunnel Services for VPLS
Step-by-Step Procedure
A tunnel interface is needed for VPLS configuration to encapsulate the originating traffic, and to de-encapsulate the traffic coming from a remote site. If the tunnel interface is not configured, the router selects one of the available tunnel interfaces on the router by default. There are three methods available in Junos OS to configure this tunnel interface.
- To specify a virtual tunnel interface to be used as the
primary device for tunneling, include the primary statement,
and specify the virtual tunnel interface to be used at the [edit
routing-instances routing-instance-name protocols vpls tunnel-services] hierarchy level.protocols {vpls {site-range 8;tunnel-services {primary vt-1/2/10;}}}
- To configure the router to use an LSI interface for tunnel
services rather than a virtual tunnel interface, include the no-tunnel-services statement at the [edit routing-instances routing-instance-name
protocols vpls] hierarchy level.protocols {vpls {site-range 8;no-tunnel-services;}}
- In an MX Series router you must create the tunnel services
interface to be used for tunnel services. To create the tunnel service
interface, include the bandwidth statement and specify the
amount of bandwidth to reserve for tunnel services in gigabits per
second at the [edit chassis fpc slot-number pic number tunnel-services] hierarchy level.fpc 1 {pic 3 {tunnel-services {bandwidth 1g;}}}
Verifying the Control Plane
Step-by-Step Procedure
This section describes show command outputs you can use to validate the control plane. It also provides methodologies for troubleshooting. Note the following:
- In this example there are six sites. Router PE1 and Router PE2 have two sites each. Router PE3 and Router PE4 have one site each. All sites are in the GOLD VPLS instance.
- In VPLS if you have multiple sites configured under a
single VPLS routing instance, the label block from the site with the
lowest site ID is used to establish pseudowires between remote PEs.
Note that the data traffic is still sent to those PE router interfaces
connected to CE devices that are in one of the following states:
- LM – Local site ID not minimum designated. The local site ID is not the lowest. Therefore the local site ID is not being used to establish pseudowires or distribute VPLS label blocks.
- RM – Remote site ID not minimum designated. The remote site ID is not the lowest. Therefore, the remote site ID is not being used to establish pseudowires or distribute VPLS label blocks.
- For more information about how VPLS label blocks are allocated and used, see Understanding VPLS Label Blocks Operation.
- After the entire configuration is done,
you can verify the VPLS connections state.
In the following output, the VPLS connections show the Up state for certain sites, and the remaining sites show either the RM or LM state. This is the expected state in a VPLS implementation on multihoming sites.
In this example, Router PE1 has site CE1 configured with site ID 1 and site Direct configured with site ID 2. The label block for site CE1 is advertised to the remote PE routers and used for receiving the data packets from the remote PE routers. In the show command output, notice the following:
- Router PE1 uses its lowest site ID, which is site ID 1. Site ID 1 is used for Device CE1.
- Router PE2 uses its lowest site ID, which is site ID 3. Site ID 3 is used for Device CE2.
- Router PE3 and Router PE4 each have a single site configured.
For site CE1, connection site 3 is in the Up state and connection site 4 is in the RM state.
- For site Direct, all the connections are in the LM state.
- Site Direct has a higher site ID than site 1 on this router.
On Router PE1, use the show vpls connections command to verify the VPLS connections state .
user@PE1> show vpls connectionsLayer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned <- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label MM -- MTU mismatch MI -- Mesh-Group ID not availble BK -- Backup connection ST -- Standby connection Legend for interface status Up -- operational Dn -- down Instance: GOLD Local site: CE1 (1) connection-site Type St Time last up # Up trans 3 rmt Up Oct 6 16:27:23 2009 1 Remote PE: 2.2.2.2, Negotiated control-word: No Incoming label: 262171, Outgoing label: 262145 Local interface: lsi.1049353, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 1 remote site 3 4 rmt RM 5 rmt Up Oct 6 16:27:27 2009 1 Remote PE: 3.3.3.3, Negotiated control-word: No Incoming label: 262173, Outgoing label: 262145 Local interface: lsi.1049354, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 1 remote site 5 6 rmt Up Oct 6 16:27:31 2009 1 Remote PE: 4.4.4.4, Negotiated control-word: No Incoming label: 262174, Outgoing label: 800000 Local interface: lsi.1049355, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 1 remote site 6 Local site: Direct (2) connection-site Type St Time last up # Up trans 3 rmt LM 4 rmt LM 5 rmt LM 6 rmt LM - On Router PE4, use the show vpls connections command to verify the VPLS connections state.
Verify that site 2 and site 4 are in the RM state. This state tells you that the sites are configured with the highest site ID on Router PE1 and Router PE2. Because Router PE4 has only one site configured, it does not have any sites in the LM states.
user@PE4> show vpls connections... Instance: GOLD Local site: Direct (6) connection-site Type St Time last up # Up trans 1 rmt Up Oct 6 16:28:35 2009 1 Remote PE: 1.1.1.1, Negotiated control-word: No Incoming label: 800000, Outgoing label: 262174 Local interface: vt-1/2/10.1048576, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 6 remote site 1 2 rmt RM 3 rmt Up Oct 6 16:28:35 2009 1 Remote PE: 2.2.2.2, Negotiated control-word: No Incoming label: 800002, Outgoing label: 262150 Local interface: vt-1/2/10.1048577, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 6 remote site 3 4 rmt RM 5 rmt Up Oct 6 16:28:35 2009 1 Remote PE: 3.3.3.3, Negotiated control-word: No Incoming label: 800004, Outgoing label: 262150 Local interface: vt-1/2/10.1048578, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 6 remote site 5 - On each PE router, use the show bgp summary command to verify that the IBGP sessions between the PE routers
or between the PE router and the route reflector have been established.
The sessions must be operational before the PE routers can exchange
any Layer 2 VPN routes. In the example below, also notice that the
output from Router PE1 shows that the bgp.l2vpn.0 and GOLD.l2vpn.0 routing tables have been created.
user@PE1> show bgp summaryGroups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l2vpn.0 4 4 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State 7.7.7.7 65000 40 39 0 1 15:45 Establ bgp.l2vpn.0: 4/4/4/0 GOLD.l2vpn.0: 4/4/4/0 admin@PE2# run show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l2vpn.0 4 4 0 0 0 0 inet6.0 0 0 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State 7.7.7.7 65000 43 42 0 0 17:25 Establ bgp.l2vpn.0: 4/4/4/0 GOLD.l2vpn.0: 4/4/4/0
- On Router PE4, use the show route table command to verify that there is one Layer 2 VPN route to each of
the other PE routers. Router PE3 should have a similar show command output.
user@PE4> show route table bgp.l2vpn.0bgp.l2vpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.1:1:1:1/96 *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7 AS path: I > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE1 1.1.1.1:1:2:1/96 *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7 AS path: I > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE1 2.2.2.2:10:3:1/96 *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7 AS path: I > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE2 2.2.2.2:10:4:1/96 *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7 AS path: I > to 10.10.9.1 via xe-0/0/0.0, label-switched-path to-PE2 3.3.3.3:10:5:1/96 *[BGP/170] 00:23:18, localpref 100, from 7.7.7.7 AS path: I > to 10.10.8.1 via xe-0/1/0.0, label-switched-path to-PE3 - On the route reflector, use the show bgp summary command to verify that the router has an IBGP peer session with
each of the PE routers.
user@RR> show bgp summaryGroups: 2 Peers: 5 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l2vpn.0 6 6 0 0 0 0 inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State 1.1.1.1 65000 44 46 0 0 18:27 Establ bgp.l2vpn.0: 2/2/2/0 2.2.2.2 65000 43 45 0 0 18:22 Establ bgp.l2vpn.0: 2/2/2/0 3.3.3.3 65000 42 45 0 0 18:19 Establ bgp.l2vpn.0: 1/1/1/0 4.4.4.4 65000 43 45 0 0 18:15 Establ bgp.l2vpn.0: 1/1/1/0
- In NG-VPLS, point-to-multipoint LSPs carry only
unknown unicast, broadcast, and multicast packets. A full mesh of
point-to-point LSPs is needed between the PE routers for NG-VPLS.
The point-to-point LSPs create routes in the inet.3 routing
table. These entries are used to resolve the Layer 2 VPN routes received
from the BGP peers. All other data traffic is sent over point-to-point
LSPs.
A point-to-point LSP is also created for the route reflector. This LSP creates a route in the inet.3 routing table for BGP next-hop resolution.
On Router PE1, use the show mpls lsp command to verify that the to-PE2, to-PE3, to-PE4, and to-RR LSPs are in the Up state.
user@PE1> show mpls lsp ingress unidirectionalIngress LSP: 7 sessions To From State Rt P ActivePath LSPname 2.2.2.2 1.1.1.1 Up 0 * to-PE2 3.3.3.3 1.1.1.1 Up 0 * to-PE3 4.4.4.4 1.1.1.1 Up 0 * to-PE4 7.7.7.7 1.1.1.1 Up 0 * to-RR Total 4 displayed, Up 4, Down 0 admin@PE2# run show mpls lsp ingress unidirectional Ingress LSP: 7 sessions To From State Rt P ActivePath LSPname 1.1.1.1 2.2.2.2 Up 0 * to-PE1 3.3.3.3 2.2.2.2 Up 0 * to-PE3 4.4.4.4 2.2.2.2 Up 0 * to-PE4 7.7.7.7 2.2.2.2 Up 0 * to-RR Total 4 displayed, Up 4, Down 0 admin@PE3# run show mpls lsp ingress unidirectional Ingress LSP: 7 sessions To From State Rt P ActivePath LSPname 1.1.1.1 3.3.3.3 Up 0 * to-PE1 2.2.2.2 3.3.3.3 Up 0 * to-PE2 4.4.4.4 3.3.3.3 Up 0 * to-PE4 7.7.7.7 3.3.3.3 Up 0 * to-RR Total 4 displayed, Up 4, Down 0 admin@PE4# run show mpls lsp ingress unidirectional Ingress LSP: 7 sessions To From State Rt P ActivePath LSPname 1.1.1.1 4.4.4.4 Up 0 * to-PE1 2.2.2.2 4.4.4.4 Up 0 * to-PE2 3.3.3.3 4.4.4.4 Up 0 * to-PE3 7.7.7.7 4.4.4.4 Up 0 * to-RR Total 4 displayed, Up 4, Down 0
- For each VPLS instance, a PE router creates a dedicated
point-to-multipoint LSP. In this example, Router PE1 and Router PE2
are configured to use a point-to-multipoint dynamic template.
For dynamic point-to-multipoint LSPs, whenever VPLS discovers a new Layer 2 VPN neighbor through BGP, a source-to-leaf sub-LSP is added in the VPLS instance for this neighbor PE router.
On Router PE1, use the show mpls lsp command to verify that three source-to-leaf sub-LSPs are created.
user@PE1> show mpls lsp ingress p2mpIngress LSP: 1 sessions P2MP name: 1.1.1.1:1:vpls:GOLD, P2MP branch count: 3 To From State Rt P ActivePath LSPname 4.4.4.4 1.1.1.1 Up 0 * 4.4.4.4:1.1.1.1:1:vpls:GOLD 3.3.3.3 1.1.1.1 Up 0 * 3.3.3.3:1.1.1.1:1:vpls:GOLD 2.2.2.2 1.1.1.1 Up 0 * 2.2.2.2:1.1.1.1:1:vpls:GOLD Total 3 displayed, Up 3, Down 0
- On Router PE2, use the show mpls lsp command
to verify that three source-to-leaf sub-LSPs are created.
user@PE2> show mpls lsp p2mp ingressIngress LSP: 1 sessions P2MP name: 2.2.2.2:10:vpls:GOLD, P2MP branch count: 3 To From State Rt P ActivePath LSPname 4.4.4.4 2.2.2.2 Up 0 * 4.4.4.4:2.2.2.2:10:vpls:GOLD 3.3.3.3 2.2.2.2 Up 0 * 3.3.3.3:2.2.2.2:10:vpls:GOLD 1.1.1.1 2.2.2.2 Up 0 * 1.1.1.1:2.2.2.2:10:vpls:GOLD Total 3 displayed, Up 3, Down 0
- In this step, Router PE3 and Router PE4 are using
static point-to-multipoint LSPs. For static point-to-multipoint LSPs,
the source-to-leaf sub-LSPs to all the PE routers are manually configured.
On Router PE3, use the show mpls lsp command to verify that three source-to-leaf sub-LSPs have been configured.
user@PE3> show mpls lsp p2mp ingressIngress LSP: 1 sessions P2MP name: vpls-GOLD, P2MP branch count: 3 To From State Rt P ActivePath LSPname 1.1.1.1 3.3.3.3 Up 0 * to-pe1 4.4.4.4 3.3.3.3 Up 0 * to-pe4 2.2.2.2 3.3.3.3 Up 0 * to-pe2 Total 3 displayed, Up 3, Down 0
- On Router PE4, use the show mpls lsp command
to verify that three source-to-leaf sub-LSPs are configured.
user@PE4> show mpls lsp ingress p2mpIngress LSP: 1 sessions P2MP name: vpls-GOLD, P2MP branch count: 3 To From State Rt P ActivePath LSPname 1.1.1.1 4.4.4.4 Up 0 * to-pe1 3.3.3.3 4.4.4.4 Up 0 * to-pe3 2.2.2.2 4.4.4.4 Up 0 * to-pe2 Total 3 displayed, Up 3, Down 0
- Each point-to-multipoint LSP created by the PE
router can be identified using an RSVP-TE point-to-multipoint session
object. The session object is passed as a PMSI tunnel attribute by
BGP when it advertises VPLS routes. Using this tunnel attribute, an
incoming source-to-leaf sub LSP add request (RSVP-Path message) supports
label allocation in such a way that when traffic arrives on this source-to-leaf
sub-LSP the router terminates the message in the right VPLS instance
and also identifies the originating PE. This supports source MAC address
learning.
On Router PE1, use the show rsvp session command to verify that the RSVP session for the dynamic point-to-multipoint LSP is Up and that link protection is configured as desired. Notice that the point-to-multipoint session object to be sent in BGP is 54337.
user@PE1> show rsvp session detail p2mp ingressIngress RSVP: 7 sessions P2MP name: 1.1.1.1:1:vpls:GOLD, P2MP branch count: 3 2.2.2.2 From: 1.1.1.1, LSPstate: Up, ActiveRoute: 0 LSPname: 2.2.2.2:1.1.1.1:1:vpls:GOLD, LSPpath: Primary P2MP LSPname: 1.1.1.1:1:vpls:GOLD Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 262145 Resv style: 1 SE, Label in: -, Label out: 262145 Time left: -, Since: Tue Oct 6 16:27:23 2009 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 54337 protocol 0 Link protection desired Type: Protection down PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.10.2.2 (xe-0/1/0.0) 371 pkts RESV rcvfrom: 10.10.2.2 (xe-0/1/0.0) 370 pkts Explct route: 10.10.2.2 Record route: <self> 10.10.2.2
- Router PE4 is configured for static point-to-multipoint
LSPs. Link protection is not configured for these LSPs. Use the show rsvp session command to verify that the point-to-multipoint
session object to be sent in BGP is 42873.
user@PE4> show rsvp session detail p2mp ingressIngress RSVP: 7 sessions P2MP name: vpls-GOLD, P2MP branch count: 3 1.1.1.1 From: 4.4.4.4, LSPstate: Up, ActiveRoute: 0 LSPname: to-pe1, LSPpath: Primary P2MP LSPname: vpls-GOLD Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 390416 Resv style: 1 SE, Label in: -, Label out: 390416 Time left: -, Since: Tue Oct 6 15:28:33 2009 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 10 receiver 42873 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.10.9.1 (xe-0/0/0.0) 524 pkts RESV rcvfrom: 10.10.9.1 (xe-0/0/0.0) 447 pkts Explct route: 10.10.9.1 10.10.3.1 Record route: <self> 10.10.9.1 10.10.3.1
- On Router PE1, use the show route table command to verify that Router PE1 received a Layer 2 VPN route to
Router PE2 from the router reflector and the route includes a PMSI
object that contains the point-to-multipoint tunnel identifier of 20361.
user@PE1> show route table GOLD.l2vpn.0 detailGOLD.l2vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) ! ! 2.2.2.2:10:3:1/96 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 2.2.2.2:10 PMSI: Flags 0:RSVP-TE:label[0:0:0]:Session_13[2.2.2.2:0:20361:2.2.2.2] Next hop type: Indirect Next-hop reference count: 7 Source: 7.7.7.7 Protocol next hop: 2.2.2.2 Indirect next hop: 2 no-forward State: <Secondary Active Int Ext> Local AS: 65000 Peer AS: 65000 Age: 4:25:25 Metric2: 1 Task: BGP_65000.7.7.7.7+63544 Announcement bits (1): 0-GOLD-l2vpn AS path: I (Originator) Cluster list: 7.7.7.7 AS path: Originator ID: 2.2.2.2 Communities: target:65000:1 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100 Import Accepted Label-base: 262145, range: 8 Localpref: 100 Router ID: 7.7.7.7 Primary Routing Table bgp.l2vpn.0 PMSI: Flags 0:RSVP-TE:label[0:0:0]:Session_13[2.2.2.2:0:20361:2.2.2.2] - On Router PE2, use the show rsvp session command to verify that the PMSI tunnel identifier object of 20361 matches the PMSI tunnel identifier object displayed on
Router PE1.
user@PE2> show rsvp session p2mp detailIngress RSVP: 7 sessions P2MP name: 2.2.2.2:10:vpls:GOLD, P2MP branch count: 3 1.1.1.1 From: 2.2.2.2, LSPstate: Up, ActiveRoute: 0 LSPname: 1.1.1.1:2.2.2.2:10:vpls:GOLD, LSPpath: Primary P2MP LSPname: 2.2.2.2:10:vpls:GOLD Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 262171 Resv style: 1 SE, Label in: -, Label out: 262171 Time left: -, Since: Tue Oct 6 16:31:47 2009 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 20361 protocol 0 Link protection desired Type: Protection down PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.10.2.1 (xe-0/1/0.0) 379 pkts RESV rcvfrom: 10.10.2.1 (xe-0/1/0.0) 379 pkts Explct route: 10.10.2.1 Record route: <self> 10.10.2.1
Verifying the Data Plane
Step-by-Step Procedure
After the control plane is verified using the previous steps, you can verify the data plane. This section describes show command outputs you can use to validate the data plane.
- On Router PE1, use the show vpls connections
extensive | match Flood command to verify the point-to-multipoint
LSP name and status of all the sites. Notice the flood next-hop identifier
of 600 for the 1.1.1.1:1:vpls:GOLD LSP.
user@PE1> show vpls connections extensive | match FloodIngress RSVP-TE P2MP LSP: 1.1.1.1:1:vpls:GOLD, Flood next-hop ID: 600
- On Router PE1, use the show vpls connections
extensive command to verify the point-to-multipoint LSP name
and status of all the sites.
user@PE1> show vpls connections extensiveInstance: GOLD Local site: CE1 (1) Number of local interfaces: 1 Number of local interfaces up: 1 IRB interface present: no ge-1/0/0.1 lsi.1049353 3 Intf - vpls GOLD local site 1 remote site 3 lsi.1049346 4 Intf - vpls GOLD local site 1 remote site 4 Interface flags: VC-Down lsi.1049354 5 Intf - vpls GOLD local site 1 remote site 5 lsi.1049355 6 Intf - vpls GOLD local site 1 remote site 6 Label-base Offset Range Preference 262169 1 8 100 connection-site Type St Time last up # Up trans 3 rmt Up Oct 6 16:27:23 2009 1 Remote PE: 2.2.2.2, Negotiated control-word: No Incoming label: 262171, Outgoing label: 262145 Local interface: lsi.1049353, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 1 remote site 3 RSVP-TE P2MP lsp: Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up Egress branch LSP: 1.1.1.1:2.2.2.2:10:vpls:GOLD, State: Up Connection History: Oct 6 16:27:23 2009 status update timer Oct 6 16:27:23 2009 PE route changed Oct 6 16:27:23 2009 Out lbl Update 262145 Oct 6 16:27:23 2009 In lbl Update 262171 Oct 6 16:27:23 2009 loc intf up lsi.1049353 4 rmt RM RSVP-TE P2MP lsp: Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up 5 rmt Up Oct 6 16:27:27 2009 1 Remote PE: 3.3.3.3, Negotiated control-word: No Incoming label: 262173, Outgoing label: 262145 Local interface: lsi.1049354, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 1 remote site 5 RSVP-TE P2MP lsp: Ingress branch LSP: 3.3.3.3:1.1.1.1:1:vpls:GOLD, State: Up Egress branch LSP: to-pe1, State: Up Connection History: Oct 6 16:27:27 2009 status update timer Oct 6 16:27:27 2009 PE route changed Oct 6 16:27:27 2009 Out lbl Update 262145 Oct 6 16:27:27 2009 In lbl Update 262173 Oct 6 16:27:27 2009 loc intf up lsi.1049354 6 rmt Up Oct 6 16:27:31 2009 1 Remote PE: 4.4.4.4, Negotiated control-word: No Incoming label: 262174, Outgoing label: 800000 Local interface: lsi.1049355, Status: Up, Encapsulation: VPLS Description: Intf - vpls GOLD local site 1 remote site 6 RSVP-TE P2MP lsp: Ingress branch LSP: 4.4.4.4:1.1.1.1:1:vpls:GOLD, State: Up Egress branch LSP: to-pe1, State: Up Connection History: Oct 6 16:27:31 2009 status update timer Oct 6 16:27:31 2009 PE route changed Oct 6 16:27:31 2009 Out lbl Update 800000 Oct 6 16:27:31 2009 In lbl Update 262174 Oct 6 16:27:31 2009 loc intf up lsi.1049355 Local site: Direct (2) Number of local interfaces: 1 Number of local interfaces up: 1 IRB interface present: no Interface name Remote site ID Description ge-1/1/0.1 lsi.1049347 3 Intf - vpls GOLD local site 2 remote site 3 Interface flags: VC-Down lsi.1049348 4 Intf - vpls GOLD local site 2 remote site 4 Interface flags: VC-Down lsi.1049350 5 Intf - vpls GOLD local site 2 remote site 5 Interface flags: VC-Down lsi.1049352 6 Intf - vpls GOLD local site 2 remote site 6 Interface flags: VC-Down Label-base Offset Range Preference 262177 1 8 100 connection-site Type St Time last up 3 rmt LM RSVP-TE P2MP lsp: Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up 4 rmt LM RSVP-TE P2MP lsp: Ingress branch LSP: 2.2.2.2:1.1.1.1:1:vpls:GOLD, State: Up 5 rmt LM RSVP-TE P2MP lsp: Ingress branch LSP: 3.3.3.3:1.1.1.1:1:vpls:GOLD, State: Up 6 rmt LM RSVP-TE P2MP lsp: Ingress branch LSP: 4.4.4.4:1.1.1.1:1:vpls:GOLD, State: Up Ingress RSVP-TE P2MP LSP: 1.1.1.1:1:vpls:GOLD, Flood next-hop ID: 600 - Junos OS Release 9.0 and later identifies the flood
next-hop route as a composite next hop. On Router PE1, use the show route forwarding-table family vpls vpn GOLD detail command
to verify that three composite flood next-hop routes are installed
in the Packet Forwarding Engine.
user@PE1> show route forwarding-table family vpls vpn GOLD detailRouting table: GOLD.vpls VPLS: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 518 1 00:00:28:28:28:02/48 user 0 ucst 617 4 ge-1/1/0.1 00:00:28:28:28:06/48 user 0 indr 1048576 4 10.10.3.2 Push 800000, Push 390384(top) 621 2 xe-0/2/0.0 lsi.1049353 intf 0 indr 1048574 3 10.10.2.2 Push 262145 598 2 xe-0/1/0.0 lsi.1049354 intf 0 indr 1048575 4 10.10.1.2 Push 262145, Push 302272(top) 602 2 xe-0/3/0.0 lsi.1049355 intf 0 indr 1048576 4 10.10.3.2 Push 800000, Push 390384(top) 621 2 xe-0/2/0.0 00:14:f6:75:78:00/48 user 0 indr 1048575 4 10.10.1.2 Push 262145, Push 302272(top) 602 2 xe-0/3/0.0 00:19:e2:57:e7:c0/48 user 0 ucst 604 4 ge-1/0/0.1 0x30003/51 user 0 comp 613 2 0x30002/51 user 0 comp 615 2 0x30001/51 user 0 comp 582 2 ge-1/0/0.1 intf 0 ucst 604 4 ge-1/0/0.1 ge-1/1/0.1 intf 0 ucst 617 4 ge-1/1/0.1You can also use the use the show route forwarding-table family vpls extensive command to match the flood identifier and note the flood label. To match the label out corresponding to the point-to-multipoint LSP, use the show rsvp session ingress p2mp command.
- On Router PE1, use the show route forwarding-table
family vpls vpn GOLD extensive | find 0x30003/51 command to get
more details about the composite next-hop route and the associated
point-to-multipoint LSP labels.
user@PE1> show route forwarding-table family vpls vpn GOLD extensive | find 0x30003/51Destination: 0x30003/51 Route type: user Route reference: 0 Route interface-index: 0 Flags: sent to PFE Nexthop: Next-hop type: composite Index: 613 Reference: 2 Nexthop: Next-hop type: composite Index: 556 Reference: 4 Next-hop type: unicast Index: 604 Reference: 4 Next-hop interface: ge-1/0/0.1 Next-hop type: unicast Index: 617 Reference: 4 Next-hop interface: ge-1/1/0.1 Destination: 0x30002/51 Route type: user Route reference: 0 Route interface-index: 0 Flags: sent to PFE Nexthop: Next-hop type: composite Index: 615 Reference: 2 Nexthop: Next-hop type: composite Index: 556 Reference: 4 Next-hop type: unicast Index: 604 Reference: 4 Next-hop interface: ge-1/0/0.1 Next-hop type: unicast Index: 617 Reference: 4 Next-hop interface: ge-1/1/0.1 Nexthop: Next-hop type: composite Index: 603 Reference: 3 Next-hop type: flood Index: 600 Reference: 2 Nexthop: 10.10.2.2 Next-hop type: Push 262145 Index: 599 Reference: 1 Next-hop interface: xe-0/1/0.0 Nexthop: 10.10.3.2 Next-hop type: Push 390496 Index: 622 Reference: 1 Next-hop interface: xe-0/2/0.0 Nexthop: 10.10.1.2 Next-hop type: Push 302416 Index: 618 Reference: 1 Next-hop interface: xe-0/3/0.0 Destination: 0x30001/51 Route type: user Route reference: 0 Route interface-index: 0 Flags: sent to PFE Nexthop: Next-hop type: composite Index: 582 Reference: 2 Nexthop: Next-hop type: composite Index: 556 Reference: 4 Next-hop type: unicast Index: 604 Reference: 4 Next-hop interface: ge-1/0/0.1 Next-hop type: unicast Index: 617 Reference: 4 Next-hop interface: ge-1/1/0.1 Nexthop: Next-hop type: composite Index: 603 Reference: 3 Next-hop type: flood Index: 600 Reference: 2 Nexthop: 10.10.2.2 Next-hop type: Push 262145 Index: 599 Reference: 1 Next-hop interface: xe-0/1/0.0 Nexthop: 10.10.3.2 Next-hop type: Push 390496 Index: 622 Reference: 1 Next-hop interface: xe-0/2/0.0 Nexthop: 10.10.1.2 Next-hop type: Push 302416 Index: 618 Reference: 1 Next-hop interface: xe-0/3/0.0 Destination: ge-1/0/0.1 Route type: interface Route reference: 0 Route interface-index: 84 Flags: sent to PFE Next-hop type: unicast Index: 604 Reference: 4 Next-hop interface: ge-1/0/0.1 Destination: ge-1/1/0.1 Route type: interface Route reference: 0 Route interface-index: 86 Flags: sent to PFE Next-hop type: unicast Index: 617 Reference: 4 Next-hop interface: ge-1/1/0.1 - On Router PE1, use the show vpls mac-table
instance GOLD command to verify the learned MAC addresses of
CE routers connected to the VPLS domain.
user@PE1> show vpls mac-table instance GOLDMAC flags (S -static MAC, D -dynamic MAC, SE -Statistics enabled, NM -Non configured MAC) Routing instance : GOLD Bridging domain : __GOLD__, VLAN : NA MAC MAC Logical address flags interface 00:00:28:28:28:02 D ge-1/1/0.1 00:00:28:28:28:04 D lsi.1049353 00:14:f6:75:78:00 D lsi.1049354 00:19:e2:51:7f:c0 D lsi.1049353 00:19:e2:57:e7:c0 D ge-1/0/0.1 - On Router PE1, use the show vpls statistics command to verify the broadcast, multicast, and unicast traffic
flow using the packet statistics for the VPLS instance.
user@PE1> show vpls statisticsVPLS statistics: Instance: GOLD Local interface: lsi.1049347, Index: 72 Current MAC count: 0 Local interface: lsi.1049348, Index: 73 Current MAC count: 0 Local interface: lsi.1049346, Index: 82 Current MAC count: 0 Local interface: lsi.1049353, Index: 83 Remote PE: 2.2.2.2 Current MAC count: 2 Local interface: ge-1/0/0.1, Index: 84 Broadcast packets: 421 Broadcast bytes : 26944 Multicast packets: 3520 Multicast bytes : 261906 Flooded packets : 509043345 Flooded bytes : 130315095486 Unicast packets : 393836428 Unicast bytes : 100822118854 Current MAC count: 1 (Limit 1024) Local interface: ge-1/1/0.1, Index: 86 Broadcast packets: 0 Broadcast bytes : 0 Multicast packets: 0 Multicast bytes : 0 Flooded packets : 22889544 Flooded bytes : 5859702144 Unicast packets : 472 Unicast bytes : 30838 Current MAC count: 1 (Limit 1024) Local interface: lsi.1049354, Index: 88 Remote PE: 3.3.3.3 Current MAC count: 1 Local interface: lsi.1049350, Index: 89 Current MAC count: 0 Local interface: lsi.1049355, Index: 90 Remote PE: 4.4.4.4 Current MAC count: 0 Local interface: lsi.1049352, Index: 91 Current MAC count: 0
Results
The configuration, verification, and testing part of this example has been completed. The following section is for your reference.
The relevant sample configuration for Router PE1 follows.
PE1 Configuration
chassis {dump-on-panic;fpc 1 {pic 3 {tunnel-services {bandwidth 1g;}}}network-services ethernet;}interfaces {xe-0/1/0 {unit 0 {family inet {address 10.10.2.1/30;}family mpls;}}xe-0/2/0 {unit 0 {family inet {address 10.10.3.1/30;}family mpls;}}xe-0/3/0 {unit 0 {family inet {address 10.10.1.1/30;}family mpls;}}ge-1/0/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}ge-1/1/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}lo0 {unit 0 {family inet {address 1.1.1.1/32;}}}}routing-options {static {route 172.0.0.0/8 next-hop 172.19.59.1;}autonomous-system 65000;}protocols {rsvp {interface all;interface fxp0.0 {disable;}}mpls {label-switched-path to-RR {to 7.7.7.7;}label-switched-path vpls-GOLD-p2mp-template {template;optimize-timer 50;link-protection;p2mp;}label-switched-path to-PE2 {to 2.2.2.2;}label-switched-path to-PE3 {to 3.3.3.3;}label-switched-path to-PE4 {to 4.4.4.4;}interface all;interface fxp0.0 {disable;}}bgp {group to-RR {type internal;local-address 1.1.1.1;family l2vpn {signaling;}neighbor 7.7.7.7;}}ospf {traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}}}routing-instances {GOLD {instance-type vpls;interface ge-1/0/0.1;interface ge-1/1/0.1;route-distinguisher 1.1.1.1:1;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;protocols {vpls {site-range 8;no-tunnel-services;site CE1 {site-identifier 1;interface ge-1/0/0.1;}site Direct {site-identifier 2;interface ge-1/1/0.1;}}}}}
The relevant sample configuration for Router PE2 follows.
PE2 Configuration
chassis {dump-on-panic;aggregated-devices {ethernet {device-count 1;}}fpc 1 {pic 3 {tunnel-services {bandwidth 1g;}}}}interfaces {xe-0/1/0 {unit 0 {family inet {address 10.10.2.2/30;}family mpls;}}xe-0/2/0 {unit 0 {family inet {address 10.10.5.1/30;}family mpls;}}xe-0/3/0 {unit 0 {family inet {address 10.10.4.1/30;}family mpls;}}ge-1/0/1 {gigether-options {802.3ad ae0;}}ge-1/0/2 {gigether-options {802.3ad ae0;}}ge-1/1/0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}ae0 {vlan-tagging;encapsulation vlan-vpls;unit 1 {encapsulation vlan-vpls;vlan-id 1000;family vpls;}}fxp0 {apply-groups [ re0 re1 ];}lo0 {unit 0 {family inet {address 2.2.2.2/32;}}}}routing-options {static {route 172.0.0.0/8 next-hop 172.19.59.1;}autonomous-system 65000;}protocols {rsvp {interface all;interface fxp0.0 {disable;}}mpls {label-switched-path to-RR {to 7.7.7.7;}label-switched-path vpls-GOLD-p2mp-template {template;optimize-timer 50;link-protection;p2mp;}label-switched-path to-PE1 {to 1.1.1.1;}label-switched-path to-PE3 {to 3.3.3.3;}label-switched-path to-PE4 {to 4.4.4.4;}interface all;interface fxp0.0 {disable;}}bgp {group to-RR {type internal;local-address 2.2.2.2;family l2vpn {signaling;}neighbor 7.7.7.7;}}ospf {traffic-engineering;area 0.0.0.0 {interface all;interface fxp0.0 {disable;}}}}routing-instances {GOLD {instance-type vpls;interface ge-1/1/0.1;interface ae0.1;route-distinguisher 2.2.2.2:10;provider-tunnel {rsvp-te {label-switched-path-template {vpls-GOLD-p2mp-template;}}}vrf-target target:65000:1;protocols {vpls {site-range 8;site CE1 {site-identifier 3;interface ae0.1;}site Direct {site-identifier 4;interface ge-1/1/0.1;}}}}}
