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 ;)