This section demonstrates the configuration that is required to establish connectivity between the customer sites using EoMPLS transport. Although it is impossible to cover all possible situations, a wide range of EoMPLS scenarios is provided. The case studies do not concentrate on specific platforms; rather, they offer generic configuration for routers and switches. The beginning case studies show topologies and configurations that involve routers and move on to case studies that involve switches.
Figure 7-5 shows the general topology used throughout the case studies. Some variations from one case study to the next require configuration or topology modifications. The goal that is common to all case studies is to establish Layer 2 and higher connectivity between the two customer sites (Oakland and Albany) by extending Layer 2 across an MPLS-enabled and routed core network. Routed means that IP traffic is switched at Layer 2 and not bridged across the core.
Prior to configuring tasks that are specific to each case study, you must complete configuration that is applicable to all case studies. This configuration involves the three service provider core routers: SanFran, Denver, and NewYork. The configuration tasks are as follows (not necessarily in this order):
Assign IP addresses to all physical core links.
Choose an interior IP routing protocol to propagate those networks.
Configure loopback interfaces. Remember to use the /32 subnet mask because no summarization is allowed into an LDP-targeted session. For instance, the IP addresses that are employed in the case studies are 192.168.1.102 for SanFran, 192.168.1.101 for Denver, and 192.168.1.103 for NewYork.
Enable CEF (necessary for MPLS to work) with the ip cef command. (On some higher-end router platforms, you need to enable distributed CEF [dCEF] instead.)
Configure MPLS globally using the mpls ip command.
Configure LDP to tell the routers to exchange MPLS labels with the mpls label protocol ldp command.
Specify the loopback interface for the LDP router ID selection via the mpls ldp router-id loopback# [force] command.
Enable MPLS on the router-to-router interfaces by using the mpls ip and mpls label protocol ldp interface commands.
Example 7-3 demonstrates the preceding configuration for SanFran, Denver, and NewYork, respectively.
hostname SanFran ! ip cef mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 force ! interface Loopback0 ip address 192.168.1.102 255.255.255.255 ! interface Serial6/0 ip address 10.1.1.102 255.255.255.0 no ip directed-broadcast mpls label protocol ldp mpls ip ! router ospf 100 log-adjacency-changes detail network 0.0.0.0 255.255.255.255 area 0 hostname Denver ! ip subnet-zero ip cef mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 force ! interface Loopback0 ip address 192.168.1.101 255.255.255.255 no ip directed-broadcast ! interface Serial5/0 ip address 10.1.2.101 255.255.255.0 no ip directed-broadcast mpls label protocol ldp mpls ip ! interface Serial6/0 ip address 10.1.1.101 255.255.255.0 no ip directed-broadcast mpls label protocol ldp tag-switching ip ! router ospf 100 log-adjacency-changes detail network 0.0.0.0 255.255.255.255 area 0 hostname NewYork ! ip subnet-zero ip cef mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 force ! interface Loopback0 ip address 192.168.1.103 255.255.255.255 ! interface Serial5/0 ip address 10.1.2.103 255.255.255.0 mpls label protocol ldp mpls ip ! router ospf 100 log-adjacency-changes detail network 0.0.0.0 255.255.255.255 area 0
Note
Normally, you would not use network 0.0.0.0 when configuring your OSPF statements. Here, it is used strictly in a practice lab environment.
At this point, you should verify that basic connectivity between the core devices works before moving on to specific EoMPLS configuration. Apply the following verification and troubleshooting principles to each router. For brevity, output for only one router is shown for each step.
Check that the routes are being received via an IGP, as shown in Example 7-4.
SanFran#show ip route ospf 10.0.0.0/24 is subnetted, 2 subnets O 10.1.2.0 [110/128] via 10.1.1.101, 00:11:11, Serial6/0 192.168.1.0/32 is subnetted, 3 subnets O 192.168.1.101 [110/65] via 10.1.1.101, 00:11:11, Serial6/0 O 192.168.1.103 [110/129] via 10.1.1.101, 00:11:11, Serial6/0
Verify that the MPLS-enabled interfaces are operationalin other words, that MPLS is enabled on an interface, as in Example 7-5.
Denver#show mpls interfaces Interface IP Tunnel Operational Serial5/0 Yes (ldp) No Yes Serial6/0 Yes (ldp) No Yes
Ensure that the PE routers have discovered the P router via the show mpls ldp discovery command, as shown in Example 7-6.
NewYork#show mpls ldp discovery
Local LDP Identifier:
192.168.1.103:0
Discovery Sources:
Interfaces:
Serial5/0 (ldp): xmit/recv
LDP Id: 192.168.1.101:0
You can also confirm that LDP sessions are established between the routers (see Example 7-7). You can see that NewYork has established a session with Denver.
NewYork#show mpls ldp neighbor Peer LDP Ident: 192.168.1.101:0; Local LDP Ident 192.168.1.103:0 TCP connection: 192.168.1.101.646 - 192.168.1.103.11004 State: Oper; Msgs sent/rcvd: 10/10; Downstream Up time: 00:02:00 LDP discovery sources: Serial5/0, Src IP addr: 10.1.2.101 Addresses bound to peer LDP Ident: 10.1.2.101 192.168.1.101 10.1.1.101
Another way of verifying whether the label forwarding table is built correctly is to issue the show mpls forwarding-table and show mpls forwarding-table detail commands, as in Example 7-8.
SanFran#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.1.2.0/24 0 Se6/0 point2point
17 Pop tag 192.168.1.101/32 0 Se6/0 point2point
18 17 192.168.1.103/32 0 Se6/0 point2point
-----------------------------------------------------------
SanFran#show mpls forwarding-table detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.1.2.0/24 0 Se6/0 point2point
MAC/Encaps=4/4, MRU=1504, Tag Stack{}
0F008847
No output feature configured
17 Pop tag 192.168.1.101/32 0 Se6/0 point2point
MAC/Encaps=4/4, MRU=1504, Tag Stack{}
0F008847
No output feature configured
18 17 192.168.1.103/32 0 Se6/0 point2point
MAC/Encaps=4/8, MRU=1500, Tag Stack{17}
0F008847 00011000
No output feature configured
You are now ready to begin the specialized EoMPLS case studies. They are as follows:
Case Study 7-1: Router to RouterPort Based
Case Study 7-2: Router to RouterVLAN Based
Case Study 7-4: Switch to SwitchVLAN Based
Case Study 7-5: Switch to SwitchPort Based
Case Study 7-6: VLAN Rewrite in Cisco 12000 Series Routers
Case Study 7-7: Map to Pseudowire
In this case study, you build on the preconfigured portion of the service provider core routers by using the topology presented in Figure 7-5. Your objective is to transport all customer traffic without utilizing 802.1q. In this case, CE devices are routers. You explore the CE switches scenario in Case Study 7-5, later in this chapter.
The port transparency feature is designed for Ethernet port-to-port transport, where the entire Ethernet frame without the preamble or FCS is transported as a single packet based on the VC type 5.
Port transparency configuration involves the two PE routers: SanFran and NewYork. Keep all settings from the previous section and issue the xconnect peer-router id vcid encapsulation mpls command for those Ethernet links that face the customer. This command allows you to make a connection to the peer PE routerthat is, from SanFran to NewYork and vice versa. peer-router-id was specified as the loopback interface's address on each of the PEs. vcid is a unique identifier shared between the two PEs. The vcid value must match on both routers. The encapsulation mpls portion of the command identifies MPLS instead of L2TPv3 as the tunneling method that encapsulates data in the pseudowire.
Example 7-9 shows the new configuration on the SanFran and NewYork routers.
hostname SanFran ! ! ! Output omitted for brevity ! interface Ethernet0/0 xconnect 192.168.1.103 100 encapsulation mpls description to Oakland ! hostname NewYork ! ! Output omitted for brevity ! interface Ethernet0/0 xconnect 192.168.1.102 100 encapsulation mpls description to Albany !
You can take several steps to ensure that your configuration is complete. First, you might want to check the status of the VCs by issuing the show mpls l2transport vc command. Example 7-10 shows that VC 100 is up on both SanFran and NewYork.
SanFran#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- ----------------------- --------------- ---------- ---------- Et0/0 Ethernet 192.168.1.103 100 UP ------------------------------------------------------------------------------- NewYorkshow mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- ----------------------- --------------- ---------- ---------- Et0/0 Ethernet 192.168.1.102 100 UP
To view more detailed information on VC 100, type in the show mpls l2transport vc 100 detail command on either of the PE routers, as shown in Example 7-11. From the output, you learn the VC and interface status, label values, MTU presets, among other useful facts.
SanFran#show mpls l2transport vc 100 detail
Local interface: Et0/0 up, line protocol up, Ethernet up
Destination address: 192.168.1.103, VC ID: 100, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 17, next hop point2point
Output interface: Se6/0, imposed label stack {17 19}
Create time: 00:07:06, last status change time: 00:06:27
Signaling protocol: LDP, peer 192.168.1.103:0 up
MPLS VC labels: local 19, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description: to Albany
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 45, send 45
byte totals: receive 4806, send 4812
packet drops: receive 0, send 0
To check the VC type, you can turn on debugging with the debug mpls l2transport signaling message command. Try using it immediately followed by the interface xconnect command. Your output should match that in Example 7-12.
#SanFran#debug mpls l2transport signaling message AToM LDP message debugging is on SanFran(config)#int e 0/0 SanFran(config-if)# xconnect 192.168.1.103 100 encapsulation mpls 00:29:01: %LDP-5-NBRCHG: LDP Neighbor 192.168.1.103:0 is UP 00:29:01: AToM LDP [192.168.1.103]: Sending label mapping msg vc type 5, cbit 1, vc id 100, group id 0, vc label 19, status 0, mtu 1500 00:29:01: AToM LDP [192.168.1.103]: Received label mapping msg, id 100 vc type 5, cbit 1, vc id 100, group id 0, vc label 19, status 0, mtu 1500 00:29:02: %SYS-5-CONFIG_I: Configured from console by console
In addition, you can use the show mpls l2transport binding command to get similar information without debugging.
Note
With the output of some commands, you can determine the VC type. The most common way is by observing the configuration of the interface. A physical interface without a subinterface represents VC type 5. A VLAN or subinterface means VC type 4. In newer Cisco IOS Software implementations, such details become less critical because of auto-negotiation of the VC type.
Finally, you should be able to verify connectivity by looking at the ARP table of the CE routers and sending an ICMP message from one CE router to the other. Example 7-13 displays the output of these commands issued on the Oakland router.
Oakland#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.100.1 - 00D0.0c00.6c00 ARPA Ethernet0/0 ____________________________________________________________________________ Oakland#ping 192.168.100.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 16/18/20 ms Oakland#ping 192.168.100.2 _________________________________________________________ Oakland#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.100.1 - 00D0.0c00.6c00 ARPA Ethernet0/0 Internet 192.168.100.2 0 00D0.0c00.6f00 ARPA Ethernet0/0 Oakland#
In Example 7-13, notice the difference between the first and the second time that the show arp command is used.
This case study explains how to enable MPLS to transport Layer 2 VLAN packets between the two customer sites. The configuration is based on the topology from Figure 7-6.
Again, for this case study, you can use the preconfigured portion described earlier in the chapter. However, instead of VC type 5, as in the previous case study, you will use VC type 4.
To configure VLAN-based EoMPLS on the imposition/disposition routers, follow these steps:
Step 1.
| Specify an Ethernet interface that is facing the customer.
|
Step 2.
| Specify the Ethernet subinterface on that interface. Set up the subinterface for the label imposition.
|
Step 3.
| Specify 802.1q encapsulation for the subinterface with the encapsulation dot1Q vlan-id command. The vlan-id value should match that of the adjoining CE router.
|
Step 4.
| Finally, specify the VC for use to transport the VLAN packets with the xconnect peer-router id vcid encapsulation mpls command. The purpose of the command was discussed previously in Case Study 7-1. Its use and method of application are the same here.
|
Example 7-14 demonstrates the SanFran and NewYork configuration needed for this case study.
hostname SanFran ! ! Output omitted for brevity ! interface FastEthernet0/0 ! interface FastEthernet0/0.100 encapsulation dot1Q 100 xconnect 192.168.1.103 100 encapsulation mpls ! hostname NewYork ! ! ! interface FastEthernet0/0 ! interface FastEthernet0/0.100 encapsulation dot1Q 100 no ip directed-broadcast no cdp enable xconnect 192.168.1.102 100 encapsulation mpls !
VLAN-based EoMPLS also requires configuration of the CE routers. The CE routers must have the same VLAN ID as the PE routers. Use the following configuration on the CE routers to transport Layer 2 VLAN packets:
Step 1.
| Select an Ethernet interface that is facing the PE.
|
Step 2.
| Set up the subinterface. It should have the same VLAN ID as the adjacent PE.
|
Step 3.
| Give an IP address to the subinterface.
|
Step 4.
| Specify an 802.1q encapsulation for the subinterface, along with the VLAN ID, via the encapsulation dot1Q vlan-id command.
|
Example 7-15 shows the customer-side router configuration of Oakland and Albany.
hostname Oakland ! interface Ethernet0/0 no ip address no ip directed-broadcast ! interface Ethernet0/0.100 encapsulation dot1Q 100 ip address 192.168.100.1 255.255.255.0 no ip directed-broadcast ----------------------------------------------------------------------- hostname Albany ! interface Ethernet0/0 no ip address no ip directed-broadcast ! interface Ethernet0/0.100 encapsulation dot1Q 100 ip address 192.168.100.2 255.255.255.0 no ip directed-broadcast
To ensure the validity of your configuration, you can use the same techniques as in Case Study 7-1. For instance, issue show mpls l2transport vc on one of the PE routers to check the status of the VC, as shown in Example 7-16. Note the subinterface in the Local intf column.
SanFran#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- ----------------------- --------------- ---------- ---------- Et0/0.100 Eth VLAN 100 192.168.1.103 100 UP
The show mpls l2transport vc 100 detail command output from Example 7-17 presents the .100 numbered subinterface, in addition to the Eth VLAN 100 up, indicating the use of the VLAN-based EoMPLS. Compare it to Ethernet up from the same command's output for port-based EoMPLS used in Case Study 7-1.
SanFran#show mpls l2transport vc 100 detail
Local interface: Et0/0.100 up, line protocol up, Eth VLAN 100 up
Destination address: 192.168.1.103, VC ID: 100, VC status: up
Preferred path: not configured
Default path: active
Tunnel label: 17, next hop point2point
Output interface: Se6/0, imposed label stack {17 16}
Create time: 00:00:57, last status change time: 00:00:20
Signaling protocol: LDP, peer 192.168.1.103:0 up
MPLS VC labels: local 16, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 3, send 3
byte totals: receive 1627, send 1628
packet drops: receive 0, send 0
The show mpls forwarding-table command in Example 7-18 shows label 16 advertised to the remote PE and used in disposition.
SanFran#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Untagged l2ckt(100) 1603 Et0/0.100 point2point 17 Pop tag 10.1.2.0/24 0 Se6/0 point2point 18 Pop tag 192.168.1.101/32 0 Se6/0 point2point 19 17 192.168.1.103/32 0 Se6/0 point2point
The VLAN rewrite feature is needed when The VLAN IDs on either side of the customer Ethernet network do not match. The network scenario in Figure 7-7 illustrates such a situation.
To compensate for the mismatch, change VLAN encapsulation on SanFran to match the VLAN ID of NewYork. Following Figure 7-7, modify the Case Study 7-2 configuration on the Oakland router to reflect the new VLAN ID.
Example 7-19 shows the Oakland and Albany interface configurations. Note that in comparison to Case Study 7-2, the settings for Albany remain the same, whereas Oakland displays 200 as its VLAN ID for the dot1Q encapsulation.
hostname Albany ! interface Ethernet0/0 ! interface Ethernet0/0.100 encapsulation dot1Q 100 ip address 192.168.100.2 255.255.255.0 no ip directed-broadcast _______________________________________________________________________ hostname Oakland ! interface Ethernet0/0 ! interface Ethernet0/0.200 encapsulation dot1Q 200 ip address 192.168.100.1 255.255.255.0
On the PE side, reconfigure the VLAN ID for the subinterface to match that of its neighboring CE. According to the topology used in this case study, you do not need to change the VLAN ID on NewYork from your previous configuration because the VLAN ID for Albany remains 100. However, you need to reset the ID for SanFran to 200 to equal Oakland's new ID.
As previously mentioned, vcid values of both PEs need to be the same. Therefore, they will remain 100 in the xconnect command, thereby rewriting the 200 VLAN to 100 to meet the requirement. The PE configuration is illustrated in Example 7-20.
hostname SanFran ! ! ! Output omitted for brevity ! interface Ethernet0/0 ! interface Ethernet0/0.200 encapsulation dot1Q 200 xconnect 192.168.1.103 100 encapsulation mpls ----------------------------------------------------------------------- hostname NewYork ! ! Output omitted for brevity ! ! interface Ethernet0/0 ! interface Ethernet0/0.100 encapsulation dot1Q 100 xconnect 192.168.1.102 100 encapsulation mpls
The issue of VLAN mismatch is not as simple when switches are concerned. This is discussed further in Case Study 7-6.
In this case study, the topology differs from the rest in that both PE and CE devices are switches instead of routers. The PEs are 7600 routers with gigabit WAN interfaces facing the MPLS core. Both CE switches connect to the PEs via 802.1q trunks.
The new topology is presented in Figure 7-8.
Note
EoMPLS can run either on a SUP720-3BXL-based system or a supervisor engine 2-based system. With SUP720-3BXL-based systems, you can implement EoMPLS on either the supervisor engine 720 or on an OSM or a Flexwan module facing the MPLS core network, whereas the supervisor engine 2-based system must be equipped with an OSM module or a Flexwan module facing the MPLS core.
To start, you do not need to make configuration changes on the Denver router of the service provider network. The majority of the SanFran and NewYork switches' configuration mirrors that of the SanFran and NewYork routers from previous case studies. Example 7-21 shows the configuration of the SanFran and NewYork switches prior to the settings needed for this case study. Notice that the serial interfaces changed to GE-WAN.
hostname SanFran ! ip cef mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 192.168.1.102 255.255.255.255 no ip directed-broadcast ! interface GE-WAN3/1 ip address 10.1.1.102 255.255.255.0 no ip directed-broadcast mpls label protocol ldp mpls ip ! router ospf 100 log-adjacency-changes detail network 0.0.0.0 255.255.255.255 area 0 __________________________________________________________ hostname NewYork ! ip subnet-zero ip cef mpls ip mpls label protocol ldp mpls ldp router-id Loopback0 ! interface Loopback0 ip address 192.168.1.103 255.255.255.255 ! interface GE-WAN3/1 ip address 10.1.2.103 255.255.255.0 mpls label protocol ldp mpls ip ! router ospf 100 log-adjacency-changes detail network 0.0.0.0 255.255.255.255 area 0
Now you can configure specific tasks for this case study.
Assume that SanFran is a SUP2-based system. Follow these steps to configure SanFran for EoMPLS:
Step 1.
| Configure a VLAN ID or VLAN range with the vlan {vlan-id | vlan-range} global command. Activate the VLAN with the state active command.
|
Step 2.
| Configure the physical port facing the CE for switching by issuing the switchport interface command.
|
Step 3.
| Set the trunk encapsulation to dot1Q when the interface is in trunking mode with the switchport trunk encapsulation dot1q command.
|
Step 4.
| Change the allowed list for the specified VLANs via the switchport trunk allowed vlan list command.
|
Step 5.
| Specify a trunking VLAN Layer 2 interface with the switchport mode trunk interface command.
|
Step 6.
| Create a VLAN interface with the interface vlan vlan-id command.
|
Step 7.
| Specify the VC for transporting the Layer 2 VLAN packets via the mpls l2transport route destination vc-id command.
|
Example 7-22 demonstrates the configuration added by following the preceding steps.
hostname SanFran ! vlan 100 state active ! interface GigabitEthernet1/4 no ip address switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 100 switchport mode trunk no shut ! interface Vlan100 no ip address no ip mroute-cache mpls l2transport route 192.168.1.103 100 no shut !
The following set of steps applies EoMPLS on the SUP720-3BXL-based system for the NewYork PE:
Step 1.
| Disable VLAN Trunking Protocol (VTP) using the vtp mode transparent global command.
|
Step 2.
| Specify the Gigabit Ethernet subinterface with the interface gigabitethernetslot/interface.subinterface command. Make sure the subinterface on the adjoining CE switch is on the same VLAN as this PE switch.
|
Step 3.
| Enable the subinterface to accept 802.1q VLAN packets via the encapsulation dot1q vlan-id command. The subinterfaces between the CE switches that are running EoMPLS should be in the same subnet.
|
Step 4.
| Bind the attachment circuit to a pseudowire VC with the xconnect command.
|
Example 7-23 demonstrates the SUP720 configuration, as discussed in the preceding steps.
! hostname NewYork ! vtp mode transparent ! interface GigabitEthernet2/4 no ip address no shut ! interface GigabitEthernet2/4.1 encapsulation dot1Q 100 xconnect 192.168.1.102 100 encapsulation mpls no shut !
Example 7-24 shows the CE switches configuration for Oakland and Albany. Notice that the CE side is the same, regardless of whether the PE system is SUP2- or SUP720-3BXL-based.
hostname Oakland ! interface GigabitEthernet1/0 negotiation auto no cdp enable no shut ! interface GigabitEthernet1/0.100 encapsulation dot1Q 100 ip address 192.168.100.1 255.255.255.0 no cdp enable no shut ! _____________________________________________________________________ hostname Albany ! interface GigabitEthernet4/0 negotiation auto no cdp enable no shut ! interface GigabitEthernet4/0.100 encapsulation dot1Q 100 ip address 192.168.100.2 255.255.255.0 no ip directed-broadcast no cdp enable no shut !
This section describes the verification techniques recommended for this case study.
Issue the gshow vlan brief command on a PE to check whether the interface can provide two-way communication, as seen in Example 7-25.
SanFran#Show vlan brief VLAN Name Status Ports ---- -------------------------------- --------- ----------------------- 1 default active 2 VLAN0100 active
The show mpls ldp discovery and show mpls ldp neighbor commands (as described earlier in the opening paragraphs of the "Case Studies" section of this chapter), in addition to the show mpls forwarding-table command, are useful. Although the show mpls forwarding-table command was already displayed in Examples 7-6 and 7-16 of this chapter, what makes it different now is the line highlighted in Example 7-26 showing the Layer 2 circuit (VLAN) configured in this case study.
SanFran#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 0 Untagged l2ckt(100) 133093 Vl100 point2point ! Output omitted for brevity
You can check the status of your VCs by issuing the show mpls l2transport vc command.
Note the difference in the output of the show mpls l2transport vc command between Example 7-16 (earlier in this chapter) and Example 7-27. The local intf portion that showed Et0/0.100 before now shows VLAN 100.
SanFran#show mpls l2transport vc Local intf Local circuit Dest address VC ID Status ------------- ----------------------- --------------- ---------- ---------- Vl100 Eth VLAN 100 192.168.1.103 100 UP
To view detailed information about your VC, issue the show mpls l2transport vc detail command, as in Example 7-28.
SanFran#show mpls l2transport vc detail
Local interface: Vl100 up, line protocol up, Eth VLAN 100 up
Destination address: 192.168.1.103, VC ID: 100, VC status: up
Tunnel label: 17, next hop 192.168.1.101
Output interface: GE3/3, imposed label stack {17 16}
Create time: 00:00:57, last status change time: 00:00:20
Signaling protocol: LDP, peer 192.168.1.103:0 up
MPLS VC labels: local 16, remote 16
Group ID: local 71, remote 89
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 3, send 3
byte totals: receive 1627, send 1628
packet drops: receive 0, send 0
In this case study, you learn how to configure port-based EoMPLS in the switch-based environment. As in the preceding case study, SanFran is a supervisor engine 2-based system and NewYork is a SUP720-3BXL-based system. The configuration presented in this case study supports both QinQ and native Ethernet traffic. Figure 7-9 shows the topology for this case study.
Note
You could allow for port-based EoMPLS without 802.1q support. This would include all basic configuration and exclude all dot1Q-related tasks. Because this is a simpler approach with the same basic configuration, it does not warrant its own case study in this book.
To set up the SanFran SUP2-based system for port-based EoMPLS with QinQ support, follow these steps:
Step 1.
| Enter the VLAN ID with the vlan {vlan_id | vlan_range} command.
|
Step 2.
| Enable dot1Q tagging for all VLANs in a trunk via the vlan dot1q tag native command.
|
Step 3.
| Configure the physical port facing the CE for switching by using the switchport interface command.
|
Step 4.
| Set the trunking mode to tunneling with the switchport mode dot1qtunnel interface command.
|
Step 5.
| Specify a VLAN whose traffic will be accepted by the port through the switchport access vlan vlan_id command.
|
Step 6.
| Configure bridge protocol data unit (BPDU) filtering on an interface with the spanning-tree bpdufilter enable command to prevent a port from sending and receiving BPDUs to protect the provider's side from potential spanning-tree attacks.
|
Step 7.
| Create a virtual VLAN interface via the interface vlan vlan_id command.
|
Step 8.
| Specify the VC to transport the VLAN traffic with the mpls l2transport route destination vc_id command.
|
Example 7-29 demonstrates the SanFran EoMPLS port-based configuration for transporting QinQ traffic described in the preceding steps.
hostname SanFran ! vlan 100 ! vlan dot1q tag native ! interface GigabitEthernet1/4 no ip address switchport switchport access vlan 100 switchport trunk encapsulation dot1q switchport mode dot1q-tunnel no cdp enable spanning-tree bpdufilter enable no shut ! interface Vlan100 no ip address no ip mroute-cache mpls l2transport route 192.168.1.103 100 no shut
Note
Be careful when enabling BPDU filtering on an interface, because it effectively disables the spanning tree for that interface. If used incorrectly, bridging loops can occur.
NewYork is a SUP720-3BXL-based system that requires the following configuration:
Step 1.
| Enter the Gigabit Ethernet interface.
|
Step 2.
| Bind the attachment circuit to a pseudowire VC with the xconnect command, as shown in previous case studies.
|
As you can see, essentially two commands exist: old (mpls l2transport route) and new (xconnect) to enable port mode EoMPLS on a SUP720-3BXLbased system. This is because significant improvements were made to the system in an effort to simplify command-line interface (CLI).
Example 7-30 demonstrates the needed configuration on the NewYork switch.
hostname NewYork ! interface GigabitEthernet2/4 no ip address xconnect 192.168.1.102 100 encapsulation mpls no shut !
CE switches do not require special configuration. You have the choice of enabling or forgoing dot1Q on the CEs. You can review Example 7-24 from the preceding case study for Oakland and Albany's settings.
To verify your configuration, use the techniques described in Case Study 7-4. In the outputs of these commands, you will not find specifics that indicate the difference between VLAN and port modes. However, you will see whether your configuration is working.
As mentioned earlier in this chapter, the VLAN ID rewrite feature on routers and switches allows the use of different VLAN IDs on VLAN interfaces at two ends of the tunnel.
Some router platforms perform VLAN rewrites automatically on the disposition router on output; therefore, no special configuration is needed. When you are using certain line card combinations of the Cisco 12000 routers, however, manual configuration of the VLAN rewrite feature is required. In this case study, the SanFran and NewYork PEs are the Cisco 12000 series routers. The topology is shown in Figure 7-10.
When you are configuring the VLAN rewrite on the Cisco 12000 series platforms, keep in mind that because of the difference in functionality, additional configuration might be required if the ends of the EoMPLS connections are not provisioned with the same line cards.
Some examples of the difference in system flow between different line cards with VLAN rewrite are outlined next:
For example, a 4-port Gigabit Ethernet line card is used, traffic flows from VLAN 100 on Oakland to VLAN200 on Albany. As the frame reaches the edge-facing line card of NewYork, the VLAN ID in the dot1Q header changes to the VLAN ID that is assigned to VLAN 200. This is because the 4-port Gigabit Ethernet line card performs a VLAN ID rewrite on the disposition side.
When a 3-port Gigabit Ethernet line card is used, traffic flows from VLAN 100 on Oakland to VLAN 200 on Albany. But, unlike the preceding example, as the frame reaches the edge-facing line card of SanFran, the VLAN ID in the dot1Q header changes to the VLAN ID that is assigned to VLAN 200. This is because the 3-port Gigabit Ethernet line card performs VLAN ID rewrite on the imposition side.
To configure VLAN rewrite on the PEs with the 3-port Gigabit Ethernet line card scenario, follow these steps:
Step 1.
| Specify the Gigabit Ethernet subinterface. Ensure that the subinterface on the adjoining CE router is on the same VLAN.
|
Step 2.
| Enable the subinterface to accept 802.1q VLAN packets with the encapsulation dot1q vlan_id command.
|
Step 3.
| Bind the attachment circuit to a pseudowire VC with the xconnect command.
|
Step 4.
| Enable the use of VLAN interfaces with different VLAN IDs at both ends of the tunnel via the remote circuit id remote_vlan_id command.
|
Example 7-31 shows the VLAN rewrite configuration on SanFran and NewYork.
hostname SanFran ! interface GigabitEthernet1/4.100 encapsulation dot1Q 100 no cdp enable no ip directed-broadcast xconnect 192.168.1.103 100 encapsulation mpls remote circuit id 200 no shut ! hostname NewYork ! interface GigabitEthernet2/4.200 encapsulation dot1Q 200 no cdp enable no ip directed-broadcast xconnect 192.168.1.102 100 encapsulation mpls remote circuit id 100 !
When you use the remote circuit id command, you are effectively enabling the VLAN Rewrite to be performed at imposition. In this case, the disposition (egress) PE router needs to inform the imposition (ingress) PE router of the VLAN used in the attachment circuit by means of signaling. This remote VLAN signaling is accomplished with the interface parameter Requested VLAN ID (parameter ID 0x06) attached to the LDP mapping message.
In newer Cisco IOS Software releases, the remote circuit id command is not required in line cards because the VLAN ID Rewrite feature is implemented automatically, and the 4-port Gigabit Ethernet line card was enhanced to perform VLAN ID rewrite, either on imposition or disposition. This allows you to configure EoMPLS in a consistent manner without checking for line card hardware dependencies.
To determine whether VLAN rewrite is enabled on Cisco 12000 series PEs, issue the show controllers eompls forwarding-table [port] [vlan] command. To execute this command, open a session directly to the line card. Example 7-32 shows the output of the command on SanFran and NewYork.
SanFran LC-CON0#show controllers eompls forwarding-table 0 100 Port # 0, VLAN-ID # 100, Table-index 100 EoMPLS configured: 1 tag_rew_ptr = D001BB58 Leaf entry? = 1 FCR index = 20 **tagrew_psa_addr = 0006ED60 **tagrew_vir_addr = 7006ED60 **tagrew_phy_addr = F006ED60 [0-7] loq 8800 mtu 4458 oq 4000 ai 3 oi 04019110 (encaps size 4) cw-size 4 vlanid-rew 200 gather A30 (bufhdr size 32 EoMPLS (Control Word) Imposition profile 81) 2 tag: 18 18 counters 1182, 10 reported 1182, 10. Local OutputQ (Unicast): Slot:2 Port:0 RED queue:0 COS queue:0 Output Q (Unicast): Port:0 RED queue:0 COS queue:0 _______________________________________________________________________________ NewYork LC-CON0#show controllers eompls forwarding-table 0 200 Port # 0, VLAN-ID # 200, Table-index 200 EoMPLS configured: 1 tag_rew_ptr = D0027B90 Leaf entry? = 1 FCR index = 20 **tagrew_psa_addr = 0009EE40 **tagrew_vir_addr = 7009EE40 **tagrew_phy_addr = F009EE40 [0-7] loq 9400 mtu 4458 oq 4000 ai 8 oi 84000002 (encaps size 4) cw-size 4 vlanid-rew 100 gather A30 (bufhdr size 32 EoMPLS (Control Word) Imposition profile 81) 2 tag: 17 18 counters 1182, 10 reported 1182, 10. Local OutputQ (Unicast): Slot:5 Port:0 RED queue:0 COS queue:0 Output Q (Unicast): Port:0 RED queue:0 COS queue:0
Note
Other platforms that do not require manual configuration do not provide VLAN ID rewrite information in their output.
Chapter 4) still runs between the customer end devices, and it is transported across the MPLS core backbone. In a VLAN ID rewrite scenario, Port VLAN ID (PVID) inconsistency stems from the Per VLAN Spanning Tree + (PVST+) BPDU being received on a different VLAN than it was originated. Therefore, when the trunk port on Oakland receives a PVST+ BPDU from the Albany's STP of VLAN 200 with a tag of VLAN 200, you get an error message as soon as the circuit comes up:
%SPANTREE-2-BLOCK_PVID_LOCAL : Blocking [chars] on [chars]. Inconsistent local vlan.
The listed STP instance is that of the native VLAN ID of the listed interface. The first [chars] is the interface, and the second [chars] is the STP instance. As a result, the trunk port is held in a blocking state (for both VLAN 100 and VLAN 200) until the inconsistency is resolved.
To unblock the interface, change the VLAN IDs on the CEs so that they match. When this is not possible and VLAN ID rewrite is required, you must turn off the STP. This alternative opens a door to bridging loops; therefore, you should use it with extreme caution.
For EoMPLS configuration, you might choose to configure a pseudowire class template that consists of configuration settings used by all attachment circuits that are bound to the class. Pseudowire was introduced in Chapters 2, "Pseudowire Emulation Framework and Standards," and 6 and is discussed in further detail in the advanced configuration case studies of Chapter 9, "Advanced AToM Case Studies."
Example 7-33 shows configuration of the VC 100 in Ethernet port mode.
hostname SanFran ! pseudowire-class ethernet-port encapsulation mpls int GigabitEthernet1/4 xconnect 192.168.1.103 100 pw-class ethernet-port !