What is the first thing that pop up in your head when you've heard a MPLS L2 VPN services?
Complicated..., it was my first impression, because most of the time I deal with L3 VPN, since in the R/S world, this L2 Service is not a main focus :p
but, when we dig it deeper, L2 VPN services on the MPLS is quite simple, there are no complicated BGP configurations compare to the L3 VPN Service. The main idea of this L2 VPN Service is that some of the customer don't want to change the IP Addressing / IGP scheme that force them to reconfigure the existing Networking Device Configuration. So they want the configuration, from they side, is what it used to be, for example, they have been using the Frame-Relay or PPP protocol for eons, they might comfort with it ;)
well, from the SP perspective, we want to satisfy their requirement, by assigning a Circuit label that will become a VPN Label, instead of VPNv4 prefix that eventually become a VPN label in the L3 VPN Service.
ok, now let's go to Scenario here:
|  | 
- Configure EoMPLS where R7 can have direct connection to the XR2 using Ethernet
- Configure Leased Line, where R7 can have direct Serial connection to XR2
- Configure Frame-Relay Circuit, where R7 can have Frame-Relay Connection to the XR2, where R7 will use DLCI 720 and XR2 will use 207
- Configure AToM where R7 F0/1 can have connection to the XR2 Frame-Relay, where XR2 use DLCI 702
First off, we have to make sure that R1 having MPLS transport label to
the XR1
| 
R1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
1000      
  9000       10.10.10.10/32   0             Fa0/0      20.1.9.9     
1001      
  Pop Label  9.9.9.9/32       0             Fa0/0      20.1.9.9     
1002      
  9001       20.10.19.0/24    0             Fa0/0      20.1.9.9     
1003      
  Pop Label  20.9.10.0/24     0             Fa0/0      20.1.9.9     
1004      
  9003       19.19.19.19/32   0             Fa0/0      20.1.9.9    
R1#traceroute 19.19.19.19 source lo0 
Type escape sequence to abort. 
Tracing the route to 19.19.19.19 
  1
  20.1.9.9 [MPLS: Label 9003 Exp 0] 276 msec 188 msec 140 msec 
  2
  20.9.10.10 [MPLS: Label 10003 Exp 0] 108 msec 84 msec 92 msec 
  3
  20.10.19.19 116 msec *  236 msec  | 
- Configure EoMPLS where R7 can have direct connection to the XR2 using Ethernet
This task is fairly simple, we need to create a pseudowire-class that
tells the router that the created connection would use MPLS as a transport
network as opposed to L2TPv3 where we don’t need the MPLS Transport. Well from
the functional point of view both L2TPv3 and EoMPLS is fairly the same, but
since EoMPLS using MPLS backbone as a transit, meaning that we can use the MPLS
feature such as MPLS TE or MPLS FRR later on, so basically using EoMPLS or AToM
we will get additional benefit later on
Now, go back to the task, after we specified the Pseudowire-class, now
we have to create an Attachment Circuit (AC) on the PE interface that facing
the Customer, in this case F0/1 on R1 or F1/0 on XR1, note that XR1 using
regular IOS, not an IOS-XR
| 
R1 
! 
pseudowire-class PC_ETH_TO_ETH 
 encapsulation mpls 
! 
interface FastEthernet0/1 
 xconnect
  19.19.19.19 119 pw-class PC_ETH_TO_ETH 
! 
End 
XR1 
! 
pseudowire-class PC_ETH_TO_ETH 
 encapsulation mpls 
! 
interface FastEthernet0/1 
 xconnect
  1.1.1.1 119 pw-class PC_ETH_TO_ETH 
! 
End | 
After we specified this command, what happen then R1 or XR1 try to
create an Targeted LDP session between them, and both R1-XR1 will create an
additional label for this specific circuit, which is number 119
| 
R1#debug mpls ldp targeted-neighbors  
ldp-trgtnbr: 19.19.19.19 -> 19.19.19.19 Req
  active by client, MPLS AToM Circuit 
ldp-trgtnbr: Created avl tree for vrf default 
ldp-trgtnbr: 19.19.19.19 allocated 
ldp-trgtnbr: 19.19.19.19 Set peer start; flags
  0x10 
ldp-trgtnbr: 19.19.19.19 Defer peer cleanup;
  cleancnt 1 
ldp-trgtnbr: 19.19.19.19 Set peer finished; flags
  0x13 
ldp-trgtnbr: 19.19.19.19 ref count incremented to
  1 
ldp-trgtnbr: 19.19.19.19 Received address
  addition notif start; flags 0x13 
ldp-trgtnbr: 19.19.19.19 Set peer start; flags
  0x13 
ldp-trgtnbr: 19.19.19.19 Set peer finished; flags
  0x1F 
ldp-trgtnbr: 19.19.19.19 Received address
  addition notif finish; flags 0x1F | 
we can see now that both R1 and XR1 will have an targeted LDP Peer
each other
| 
R1#show mpls ldp neighbor 19.19.19.19 
    Peer
  LDP Ident: 19.19.19.19:0; Local LDP Ident 1.1.1.1:0 
        TCP
  connection: 19.19.19.19.40470 - 1.1.1.1.646 
       
  State: Oper; Msgs sent/rcvd: 34/33; Downstream 
        Up
  time: 00:16:34 
        LDP
  discovery sources: 
          Targeted Hello 1.1.1.1 ->
  19.19.19.19, active, passive 
       
  Addresses bound to peer LDP Ident: 
         
  20.10.19.19     19.19.19.19     
XR1#show mpls ldp neighbor 1.1.1.1 
    Peer
  LDP Ident: 1.1.1.1:0; Local LDP Ident 19.19.19.19:0 
        TCP
  connection: 1.1.1.1.646 - 19.19.19.19.40470 
       
  State: Oper; Msgs sent/rcvd: 33/34; Downstream 
        Up
  time: 00:17:00 
        LDP
  discovery sources: 
          Targeted Hello 19.19.19.19
  -> 1.1.1.1, active, passive 
       
  Addresses bound to peer LDP Ident: 
         
  20.1.9.1        1.1.1.1           | 
And they will assign an additional label for the specific Circuit,
since we use number 119 as and Pseudowire-ID, the R1/XR1 will use this number
as an circuit Identifier
| 
R1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
1000      
  9000       10.10.10.10/32   0             Fa0/0      20.1.9.9     
1001      
  Pop Label  9.9.9.9/32       0             Fa0/0      20.1.9.9     
1002      
  9001       20.10.19.0/24    0             Fa0/0      20.1.9.9     
1003      
  Pop Label  20.9.10.0/24     0             Fa0/0      20.1.9.9     
1004      
  9003       19.19.19.19/32   0             Fa0/0      20.1.9.9     
1005       No Label   l2ckt(119)       10718         Fa0/1      point2point 
XR1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
19000     
  Pop Label  10.10.10.10/32   0             Fa0/0      20.10.19.10  
19001     
  10000      9.9.9.9/32       0             Fa0/0      20.10.19.10  
19002     
  10002      1.1.1.1/32       0             Fa0/0      20.10.19.10  
19003     
  10001      20.1.9.0/24      0             Fa0/0      20.10.19.10  
19004      Pop Label 
  20.9.10.0/24     0             Fa0/0      20.10.19.10  
19005      No Label   l2ckt(119)       20302         Fa1/0      point2point | 
So let see the status of the circuit itself
| 
R1#show mpls l2transport summary  
Destination address: 19.19.19.19, total number of
  vc: 1 
  0
  unknown, 1 up, 0
  down, 0 admin down, 0 recovering, 0 standby, 0 hotstandby 
  1 active
  vc on MPLS interface Fa0/0 
R1#show mpls l2transport vc   
Local intf    
  Local circuit              Dest
  address    VC ID      Status     
------------- 
  -------------------------- --------------- ---------- ---------- 
Fa0/1         
  Ethernet                  
  19.19.19.19     119        UP         
R1#show mpls l2transport vc detail  
Local interface: Fa0/1 up, line protocol up,
  Ethernet up 
 
  Destination address: 19.19.19.19, VC ID: 119, VC status: up 
    Output
  interface: Fa0/0, imposed label stack {9003 19005} 
   
  Preferred path: not configured   
    Default
  path: active 
    Next
  hop: 20.1.9.9 
  Create
  time: 00:21:48, last status change time: 00:07:11 
  Signaling protocol: LDP, peer
  19.19.19.19:0 up 
   
  Targeted Hello: 1.1.1.1(LDP Id) -> 19.19.19.19, LDP is UP 
    Status
  TLV support (local/remote)   :
  enabled/supported 
      LDP
  route watch                   : enabled 
     
  Label/status state machine       
  : established, LruRru 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: No fault 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC
  labels: local 1005, remote 19005  
    Group
  ID: local 0, remote 0 
    MTU:
  local 1500, remote 1500 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 307, send 649 
    transit
  byte totals:   receive 26069, send
  63117 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 | 
And now, R7 and XR2 configuration will be simple
| 
R7 
! 
Interface f0/1 
 Ip address
  10.0.0.7 255.255.255.0 
! 
End 
XR2 
! 
Interface fa1/0 
 Ip address
  10.0.0.20 255.255.255.0 
! 
end | 
Now they will have direct communication and the broadcast will span
from R7 to the XR2 and vice versa:
| 
R7#ping 255.255.255.255  
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to
  255.255.255.255, timeout is 2 seconds: 
Reply to request 0 from 10.0.0.20, 140 ms 
Reply to request 1 from 10.0.0.20, 168 ms 
Reply to request 2 from 10.0.0.20, 140 ms 
Reply to request 3 from 10.0.0.20, 164 ms 
Reply to request 4 from 10.0.0.20, 164 ms | 
- Configure Leased Line, where R7 can have direct Serial connection to XR2
This task was quite obvious, the same like the previous one, note that
I will remove the previous xconnect configuration on both R1 and XR1.
| 
R1 
! 
pseudowire-class PC_PPP_TO_PPP 
 encapsulation mpls 
! 
interface Serial1/0 
 encapsulation ppp 
 clock rate
  252000 
 xconnect
  19.19.19.19 119 pw-class PC_PPP_TO_PPP 
! 
End 
XR1 
! 
pseudowire-class PC_PPP_TO_PPP 
 encapsulation mpls 
! 
interface POS2/0 
 encapsulation ppp 
 xconnect
  1.1.1.1 119 pw-class PC_PPP_TO_PPP 
! 
end | 
We can now see that the Targeted LDP session was successfully build up
| 
R1#show mpls ldp neighbor  
    Peer
  LDP Ident: 9.9.9.9:0; Local LDP Ident 1.1.1.1:0 
        TCP
  connection: 9.9.9.9.57667 - 1.1.1.1.646 
       
  State: Oper; Msgs sent/rcvd: 54/54; Downstream 
        Up
  time: 00:38:34 
        LDP
  discovery sources: 
         
  FastEthernet0/0, Src IP addr: 20.1.9.9 
       
  Addresses bound to peer LDP Ident: 
         
  9.9.9.9         20.1.9.9        20.9.10.9        
    Peer
  LDP Ident: 19.19.19.19:0; Local LDP Ident 1.1.1.1:0 
        TCP
  connection: 19.19.19.19.54310 - 1.1.1.1.646 
        State: Oper; Msgs
  sent/rcvd: 13/13; Downstream 
        Up
  time: 00:02:22 
        LDP
  discovery sources: 
          Targeted Hello 1.1.1.1 ->
  19.19.19.19, active, passive 
       
  Addresses bound to peer LDP Ident: 
         
  20.10.19.19     19.19.19.19      
XR1#show mpls ldp neighbor 1.1.1.1 
    Peer
  LDP Ident: 1.1.1.1:0; Local LDP Ident 19.19.19.19:0 
        TCP
  connection: 1.1.1.1.646 - 19.19.19.19.54310 
        State: Oper; Msgs
  sent/rcvd: 14/14; Downstream 
        Up
  time: 00:03:02 
        LDP
  discovery sources: 
          Targeted Hello 19.19.19.19
  -> 1.1.1.1, active, passive 
       
  Addresses bound to peer LDP Ident: 
         
  20.1.9.1        1.1.1.1          | 
Now, lets take a look the Label binding and the L2transport
verification on one of the PE Router
| 
R1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
1000      
  9000       10.10.10.10/32   0             Fa0/0      20.1.9.9     
1001      
  Pop Label  9.9.9.9/32       0             Fa0/0      20.1.9.9     
1002      
  9001       20.10.19.0/24    0             Fa0/0      20.1.9.9     
1003       Pop Label 
  20.9.10.0/24     0             Fa0/0      20.1.9.9     
1004      
  9003       19.19.19.19/32   0             Fa0/0      20.1.9.9     
1006       No Label   l2ckt()          0             drop        
R1#show mpls l2transport summary  
Destination address: 19.19.19.19, total number of
  vc: 1 
  0
  unknown, 0 up, 1 down,
  0 admin down, 0 recovering, 0 standby, 0 hotstandby 
R1#show mpls l2transport vc 119 detail  
Local interface: Se1/0 up, line protocol up, PPP
  up 
 
  Destination address: 19.19.19.19, VC ID: 119, VC status: down 
    Output
  interface: none, imposed label stack {} 
   
  Preferred path: not configured   
    Default
  path: no route 
    No
  adjacency 
  Create
  time: 00:05:18, last status change time: 00:04:32 
  Signaling
  protocol: LDP, peer 19.19.19.19:0 up 
   
  Targeted Hello: 1.1.1.1(LDP Id) -> 19.19.19.19, LDP is UP 
    Status
  TLV support (local/remote)   :
  enabled/supported 
      LDP
  route watch                   : enabled 
     
  Label/status state machine        : remote invalid, LruRnd 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: DOWN PW(rx/tx faults) 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC
  labels: local 1006, remote 19006  
    Group
  ID: local 0, remote 0 
    MTU:
  local 1500, remote 4470 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 0, send 0 
    transit
  byte totals:   receive 0, send 0 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 | 
The verification show us that the L2tranposrt circuit is not up!!!
Unfortunately on the IOS, the software will not tell us which component that
causing this circuit is not up and running L,
but the problem lies in here
| 
XR1#show mpls l2transport vc detail  
Local interface: PO2/0 up, line protocol up, PPP
  up 
 
  Destination address: 1.1.1.1, VC ID: 119, VC status: down 
    Output
  interface: none, imposed label stack {} 
   
  Preferred path: not configured   
    Default
  path: no route 
    No
  adjacency 
  Create
  time: 00:06:32, last status change time: 00:06:29 
  Signaling
  protocol: LDP, peer 1.1.1.1:0 up 
   
  Targeted Hello: 19.19.19.19(LDP Id) -> 1.1.1.1, LDP is UP 
    Status
  TLV support (local/remote)   :
  enabled/supported 
      LDP
  route watch                   : enabled 
      Label/status
  state machine        : remote invalid,
  LruRru 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: DOWN PW(rx/tx faults) 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC
  labels: local 19006, remote 1006  
    Group
  ID: local 0, remote 0 
    MTU: local 4470, remote 1500 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 0, send 0 
    transit
  byte totals:   receive 0, send 0 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 | 
The MTU is mismatch, while XR1 using POS interface that having higher
bandwidth, by default it will have a higher MTU, which is 4470. This is the
main problem actually, in the IOS-XR the software will tell us that the MTU
mismatch is the source of the problem, cool right?!?.
And as a side note, when we configure MTU in the IOS, let say 1500, if
the Interface are using PPP which is use 4 Bytes overhead, the IOS Software
will decrease the payload automatically, so that the total of the L2 Header and
the payload will be 1500, if the payload size is 1500 Bytes, then the
fragmentation will be occurred
On the contrary in the IOS-XR, if we specified MTU 1500 Bytes, this
MTU will be use only for the payload + header, since PPP using 4 Bytes, and the
payload will be 1496 Bytes maximum. So this could lead to the error in some
cases, let say OSPF configuration, the OSPF will detect the MTU only 1496
instead of 1500. So, the bottom line is, we have to count for an additional
header when we configuring MTU, in our case, the MTU should be configured 1504.
| 
XR1 
! 
Interface POS2/0 
 Mtu 1500 
! 
end | 
After we configured the MTU on the POS interface, let see the
verification of the MPLS L2Transport
| 
XR1#show mpls l2transport vc detail  
Local interface: PO2/0 up, line protocol up, PPP
  up 
 
  Destination address: 1.1.1.1, VC ID: 119, VC status: up 
    Output
  interface: Fa0/0, imposed label stack {10002 1006} 
   
  Preferred path: not configured   
    Default
  path: active 
    Next
  hop: 20.10.19.10 
  Create
  time: 00:00:12, last status change time: 00:00:12 
  Signaling
  protocol: LDP, peer 1.1.1.1:0 up 
   
  Targeted Hello: 19.19.19.19(LDP Id) -> 1.1.1.1, LDP is UP 
    Status
  TLV support (local/remote)   :
  enabled/supported 
      LDP
  route watch                   : enabled 
     
  Label/status state machine       
  : established, LruRru 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: No fault 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC
  labels: local 19005, remote 1006  
    Group
  ID: local 0, remote 0 
    MTU:
  local 1500, remote 1500 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 20, send 20 
    transit
  byte totals:   receive 1581, send 1786 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 
R1#show mpls l2transport vc 119 detail  
Local interface: Se1/0 up, line protocol up, PPP
  up 
 
  Destination address: 19.19.19.19, VC ID: 119, VC status: up 
    Output
  interface: Fa0/0, imposed label stack {9003 19005} 
   
  Preferred path: not configured   
    Default
  path: active 
    Next
  hop: 20.1.9.9 
  Create
  time: 00:19:52, last status change time: 00:04:25 
  Signaling
  protocol: LDP, peer 19.19.19.19:0 up 
   
  Targeted Hello: 1.1.1.1(LDP Id) -> 19.19.19.19, LDP is UP 
    Status
  TLV support (local/remote)   :
  enabled/supported 
      LDP
  route watch                   : enabled 
     
  Label/status state machine       
  : established, LruRru 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: No fault 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC labels: local 1006, remote 19005  
    Group
  ID: local 0, remote 0 
    MTU:
  local 1500, remote 1500 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 127, send 128 
    transit
  byte totals:   receive 6668, send 10289 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 | 
Now both R1 and XR1 will assign the label for the specified Circuit:
| 
R1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
1000      
  9000       10.10.10.10/32   0             Fa0/0      20.1.9.9     
1001      
  Pop Label  9.9.9.9/32       0             Fa0/0      20.1.9.9     
1002      
  9001       20.10.19.0/24    0             Fa0/0      20.1.9.9     
1003      
  Pop Label  20.9.10.0/24     0             Fa0/0      20.1.9.9     
1004      
  9003       19.19.19.19/32   0         
     Fa0/0      20.1.9.9     
1006       No Label   l2ckt(119)       7338          Se1/0      point2point 
XR1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
19000     
  Pop Label  10.10.10.10/32   0             Fa0/0      20.10.19.10  
19001     
  10000      9.9.9.9/32       0             Fa0/0      20.10.19.10  
19002     
  10002      1.1.1.1/32       0             Fa0/0      20.10.19.10  
19003     
  10001      20.1.9.0/24      0             Fa0/0      20.10.19.10  
19004     
  Pop Label  20.9.10.0/24     0             Fa0/0      20.10.19.10  
19005      No Label   l2ckt(119)       8256          PO2/0      point2point | 
And the configuration in the R7 and XR2 as a CE will be very simple
| 
R7 
! 
interface Serial0/0 
 ip address
  10.0.0.7 255.255.255.0 
 encapsulation ppp 
! 
End 
XR2 
! 
interface POS2/0 
 mtu 1500 
 ip address
  10.0.0.20 255.255.255.0 
 encapsulation ppp 
! 
end | 
XR2 will have direct adjacency with the R7
| 
XR2#ping 10.0.0.7 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.0.0.7,
  timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max =
  136/152/172 ms 
XR2#ping 255.255.255.255 rep 2 
Type escape sequence to abort. 
Sending 2, 100-byte ICMP Echos to
  255.255.255.255, timeout is 2 seconds: 
Reply to request 0 from 10.0.0.7, 208 ms 
Reply to request 1 from 10.0.0.7, 172 ms | 
- Configure Frame-Relay Circuit, where R7 can have Frame-Relay Connection to the XR2, where R7 will use DLCI 720 and XR2 will use 207
First of there are a minor configuration differences between AToM
using Ethernet and PPP with Frame-Relay. First of, the PE should be configured
as a Frame-relay Switching to be on, as a side note, in the IOS-XR the
Frame-Relay switching is ready.
Then the xconnect statement is not bound to the Interface, but it is
bound to the PVC that we assigned to the Frame-Relay PVC
| 
R1 
! 
frame-relay switching 
! 
pseudowire-class PC_FR_TO_FR 
 encapsulation mpls 
! 
interface Serial1/0 
 encapsulation frame-relay IETF 
 frame-relay intf-type dce 
! 
connect L2VPN_FR Serial1/0 720 l2transport 
 xconnect
  19.19.19.19 119 pw-class PC_FR_TO_FR 
 ! 
! 
End 
XR1 
! 
frame-relay switching 
! 
pseudowire-class PC_FR_TO_FR 
 encapsulation
  mpls 
! 
interface POS2/0 
 mtu 1500 
 no ip
  address 
 encapsulation frame-relay IETF 
 frame-relay intf-type dce 
! 
connect L2VPN_FR POS2/0 207 l2transport 
 xconnect
  1.1.1.1 119 pw-class PC_FR_TO_FR 
 ! 
! 
end | 
Well, we have to configure the customer side, R7 and XR2, in order to
verify that the L2 Circuit is being up
| 
R7 
! 
interface Serial0/0 
 ip address
  10.0.0.7 255.255.255.0 
 encapsulation frame-relay IETF 
 serial
  restart-delay 0 
 clock rate
  2000000 
 frame-relay map ip 10.0.0.20 720 broadcast 
! 
End 
XR2 
! 
interface POS2/0 
 mtu 1500 
 no ip
  address 
 encapsulation frame-relay IETF 
! 
interface POS2/0.207 point-to-point 
 ip address
  10.0.0.20 255.255.255.0 
 frame-relay interface-dlci 207    
! 
end | 
The verification  on the PE side
is the same like the previous case with the Ethernet and the PPP
| 
R1#show mpls l2transport vc 119 detail  
Local interface: Se1/0 up, line protocol up, FR DLCI 720 up 
 
  Destination address: 19.19.19.19, VC ID: 119, VC status: up 
    Output
  interface: Fa0/0, imposed label stack {9003 19006} 
   
  Preferred path: not configured   
    Default
  path: active 
    Next
  hop: 20.1.9.9 
  Create
  time: 00:10:15, last status change time: 00:06:39 
  Signaling
  protocol: LDP, peer 19.19.19.19:0 up 
   
  Targeted Hello: 1.1.1.1(LDP Id) -> 19.19.19.19, LDP is UP 
    Status
  TLV support (local/remote)   :
  enabled/supported 
      LDP
  route watch                   : enabled 
     
  Label/status state machine       
  : established, LruRru 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: No fault 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC
  labels: local 1005, remote 19006  
    Group
  ID: local 0, remote 0 
    MTU:
  local 1500, remote 1500 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 108, send 21 
    transit
  byte totals:   receive 9156, send 1978 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 
R1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
1000      
  9000       10.10.10.10/32   0             Fa0/0      20.1.9.9     
1001      
  Pop Label  9.9.9.9/32       0             Fa0/0      20.1.9.9     
1002      
  9001       20.10.19.0/24    0             Fa0/0      20.1.9.9     
1003      
  Pop Label  20.9.10.0/24     0             Fa0/0      20.1.9.9     
1004      
  9003       19.19.19.19/32   0             Fa0/0      20.1.9.9     
1005       No Label   l2ckt(119)       9404          Se1/0      point2point 
R1#ping mpls pseudowire 19.19.19.19 119  
%Total number of MS-PW segments is less than
  segment number; Adjusting the segment number to 1 
Sending 5, 100-byte MPLS Echos to 19.19.19.19,  
    
  timeout is 2 seconds, send interval is 0 msec: 
Codes: '!' - success, 'Q' - request not sent, '.'
  - timeout, 
  'L' -
  labeled output interface, 'B' - unlabeled output interface,  
  'D' - DS
  Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch, 
  'M' -
  malformed request, 'm' - unsupported tlvs, 'N' - no label entry,  
  'P' - no
  rx intf label prot, 'p' - premature termination of LSP,  
  'R' -
  transit router, 'I' - unknown upstream index, 
  'X' -
  unknown return code, 'x' - return code 0 
Type escape sequence to abort. 
!!!!! 
Success rate is 100 percent (5/5), round-trip
  min/avg/max = 156/228/292 ms | 
From the customer perspective, it looks like they connect to the real
FR cloud ;)
| 
R7#show frame-relay pvc  
PVC Statistics for interface Serial0/0 (Frame
  Relay DTE) 
             
  Active     Inactive      Deleted 
       Static 
 
  Local          1            0            0            0 
 
  Switched       0            0            0            0 
 
  Unused         0            0            0            0 
DLCI = 720, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE,
  INTERFACE = Serial0/0 
  input
  pkts 135           output pkts 23           in bytes 11668      
  out bytes
  1602           dropped pkts 0           in pkts dropped 0          
  out pkts
  dropped 0                out bytes
  dropped 0          
  in FECN
  pkts 0           in BECN pkts 0           out FECN pkts 0          
  out BECN
  pkts 0          in DE pkts 0             out DE pkts 0          
  out bcast
  pkts 10        out bcast bytes 640        
  5 minute
  input rate 0 bits/sec, 0 packets/sec 
  5 minute
  output rate 0 bits/sec, 0 packets/sec 
  pvc
  create time 00:09:37, last time pvc status changed 00:08:27 
R7#show frame-relay map 
Serial0/0 (up): ip 10.0.0.20 dlci
  720(0x2D0,0xB400), static, 
             
  broadcast, 
             
  IETF, status defined, active 
XR2#show frame-relay pvc  
PVC Statistics for interface POS2/0 (Frame Relay
  DTE) 
             
  Active     Inactive      Deleted       Static 
 
  Local          1            0            0            0 
 
  Switched       0            0            0           
  0 
 
  Unused         0            0            0            0 
DLCI = 207, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE,
  INTERFACE = POS2/0.207 
  input
  pkts 23            output pkts 144          in bytes 1602       
  out bytes
  12528          dropped pkts 0           in pkts dropped 0          
  out pkts
  dropped 0                out bytes
  dropped 0          
  in FECN
  pkts 0           in BECN pkts 0           out FECN pkts 0          
  out BECN
  pkts 0          in DE pkts 0             out DE pkts 0          
  out bcast
  pkts 130       out bcast bytes
  11504      
  5 minute
  input rate 0 bits/sec, 0 packets/sec 
  5 minute
  output rate 0 bits/sec, 0 packets/sec 
  pvc
  create time 00:09:22, last time pvc status changed 00:09:12 
XR2#show frame-relay map 
POS2/0.207 (up): point-to-point dlci, dlci
  207(0xCF,0x30F0), broadcast 
         
  status defined, active | 
- Configure AToM where R7 F0/1 can have connection to the XR2 Frame-Relay, where XR2 use DLCI 702
This is the advantage of using AToM, it can transport data regardless
of the L2 Attachment Circuit that facing to the interface, this task is one of
the example, where one customer, R7, using Ethernet to connect to other
customer, XR2, which is using Frame-Relay Connection.
Since we are going to have a different L2 transport in this case, we
should activate the ‘Internetworking’ feature under the pseudowire-class. Ok
let’s hop to the configuration here:
Note that I remove the previous configuration on both R1 and XR1
before starting the following configuration task
| 
R1 
! 
pseudowire-class PC_ETH_TO_FR 
 encapsulation mpls 
 interworking ip 
! 
interface FastEthernet0/1 
 xconnect
  19.19.19.19 29281 pw-class PC_ETH_TO_FR 
! 
End 
XR1 
! 
pseudowire-class PC_FR_TO_ETH 
 encapsulation mpls 
 interworking ip 
! 
interface POS2/0 
 mtu 1500 
 encapsulation frame-relay IETF 
 frame-relay intf-type dce 
! 
Frame-relay switching 
connect L2VPN_FR_TO_ETH POS2/0 207 l2transport 
 xconnect
  1.1.1.1 29281 pw-class PC_FR_TO_ETH 
 ! 
! 
end | 
While configuration on the customer side is straight forward
| 
R7 
! 
Default interface se0/0 
! 
interface FastEthernet0/1 
 ip address
  10.0.0.7 255.255.255.0 
! 
End 
XR2 
! 
interface POS2/0 
 mtu 1500 
 no ip
  address 
 encapsulation frame-relay IETF 
! 
interface POS2/0.207 point-to-point 
 ip address
  10.0.0.20 255.255.255.0 
 frame-relay interface-dlci 207    
! 
end | 
Again, from the PE verification perspective, the command will be the
same like the previous 3 cases
| 
R1#show mpls l2transport vc 29281 detail  
Local interface: Fa0/1 up, line protocol up,
  Ethernet up 
 
  Interworking type is IP 
 
  Destination address: 19.19.19.19, VC ID: 29281, VC status: up 
    Output
  interface: Fa0/0, imposed label stack {9003 19005} 
   
  Preferred path: not configured   
    Default
  path: active 
    Next
  hop: 20.1.9.9 
  Create
  time: 00:09:26, last status change time: 00:08:07 
  Signaling
  protocol: LDP, peer 19.19.19.19:0 up 
   
  Targeted Hello: 1.1.1.1(LDP Id) -> 19.19.19.19, LDP is UP 
    Status
  TLV support (local/remote)   :
  enabled/supported 
      LDP
  route watch                   : enabled 
     
  Label/status state machine       
  : established, LruRru 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: No fault 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC
  labels: local 1006, remote 19005  
    Group
  ID: local 0, remote 0 
    MTU: local 1500, remote 1500 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 122, send 123 
    transit
  byte totals:   receive 7784, send 10980 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 
R1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
1000      
  9000       10.10.10.10/32   0             Fa0/0      20.1.9.9     
1001      
  Pop Label  9.9.9.9/32       0             Fa0/0      20.1.9.9     
1002      
  9001       20.10.19.0/24    0             Fa0/0      20.1.9.9     
1003      
  Pop Label  20.9.10.0/24     0  
            Fa0/0      20.1.9.9     
1004      
  9003       19.19.19.19/32   0             Fa0/0      20.1.9.9     
1007       No Label   l2ckt(29281)     652           Fa0/1      point2point 
XR1#show mpls l2transport vc detail  
Local interface: PO2/0 up, line protocol up, FR DLCI 207 up 
 
  Interworking type is IP 
 
  Destination address: 1.1.1.1, VC ID: 29281, VC status: up 
    Output
  interface: Fa0/0, imposed label stack {10002 1007} 
   
  Preferred path: not configured   
    Default
  path: active 
    Next
  hop: 20.10.19.10 
  Create
  time: 00:10:10, last status change time: 00:01:00 
  Signaling
  protocol: LDP, peer 1.1.1.1:0 up 
   
  Targeted Hello: 19.19.19.19(LDP Id) -> 1.1.1.1, LDP is UP 
    Status
  TLV support (local/remote)   : enabled/supported 
      LDP
  route watch                   : enabled 
     
  Label/status state machine       
  : established, LruRru 
      Last
  local dataplane   status rcvd: No fault 
      Last
  local SSS circuit status rcvd: No fault 
      Last
  local SSS circuit status sent: No fault 
      Last
  local  LDP TLV    status sent: No fault 
      Last
  remote LDP TLV    status rcvd: No fault 
      Last
  remote LDP ADJ    status rcvd: No fault 
    MPLS VC
  labels: local 19005, remote 1007  
    Group
  ID: local 0, remote 0 
    MTU: local 1500, remote 1500 
    Remote
  interface description:  
 
  Sequencing: receive disabled, send disabled 
  Control
  Word: On (configured: autosense) 
  VC
  statistics: 
    transit
  packet totals: receive 154, send 150 
    transit
  byte totals:   receive 9630, send 13488 
    transit
  packet drops:  receive 0, seq error 0,
  send 0 
XR1#show mpls forwarding-table  
Local     
  Outgoing   Prefix           Bytes Label   Outgoing  
  Next Hop     
Label     
  Label      or Tunnel Id     Switched      interface               
19000     
  Pop Label  10.10.10.10/32   0             Fa0/0      20.10.19.10  
19001     
  10000      9.9.9.9/32       0             Fa0/0      20.10.19.10  
19002     
  10002      1.1.1.1/32       0             Fa0/0      20.10.19.10  
19003     
  10001      20.1.9.0/24      0             Fa0/0      20.10.19.10  
19004     
  Pop Label  20.9.10.0/24     0             Fa0/0      20.10.19.10  
19005      No Label   l2ckt(29281)     1848          PO2/0      point2point  
XR1# | 
Well, I Hope this have been informative, and I’d like to thank you for
take your time to read this ;)

