GNS3 Lab: Any Transport over MPLS (AToM) basic configuration for Ethernet 802.1q and Frame-relay

AToM stands for Any Transport over MPLS, a quite reassuring technology which, provided you have a MPLS enabled network and some good gears, let you set up L2 circuits across your IP backbone.

This lab offers a very simple topology with 2 AToM links; an ethernet with an 802.1q trunk and a frame-relay link.

Core

Core (P) routers configuration is pretty simple; we only enable MPLS switching on interfaces toward PE routers and setup LDP for labels exchange. A good core doesn’t care about what kind of traffic it switches!

P1:

mpls label protocol ldp
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 description PE1 facing interface
 mpls ip
!
interface FastEthernet1/0
 description P2 facing interface
 mpls ip
!
mpls ldp router-id Loopback0 force

PE routers

The hard work is done on PE routers. PE routers face CE routers, which they receive L2 traffic from, and network core P routers, which they have to send MPLS encapsulated traffic to.
In order to build up a L2 circuit, PE routers have to setup a pseudowire connection between them, so they know how to switch traffic. Each pseudowire uses a virtual-circuit ID (VC ID), which is locally significant on each PE pair and is used to identify the pseudowire itself and to bind it to a specific MPLS label.

First off, they must be MPLS aware:

PE2

mpls label protocol ldp
!
interface Loopback0
 ip address 1.1.2.2 255.255.255.255
!
interface FastEthernet0/1
 description P2 facing interface
 mpls ip
!
mpls ldp router-id Loopback0

Now, we have to set up pseudowires between PE and L2 connections with CEs.

Let’s start with the Ethernet 802.1q trunk.

Port mode Ethernet over MPLS (EoMPLS)

In port mode EoMPLS every frame received on a PE interface is forwarded to the other PE almost unchanged (just preamble and FCS are removed).

Basic configuration is very simple:

PE2

interface FastEthernet0/0
 description CE_Switch2 facing interface
 no ip address
 duplex auto
 speed auto
 xconnect 1.1.2.1 10 encapsulation mpls

The xconnect command does all the work! This command tells the PE router to encapsulate every frame in a MPLS packet and to forward it to the peer 1.1.2.1 using VC ID 10.
It also allow Label Distribution Protocol (LDP) to exchange informations about the pseudowire circuit between PEs (VC ID / label mapping, VC type, MTU).

Once we have applied this configuration to both PE routers (on PE1 we have to change the xconnect peer address!), we can verify if LDP did its work and if pseudowire is up:

PE2#show mpls l2transport vc 10 detail
Local interface: Fa0/0 up, line protocol up, Ethernet up
  Destination address: 1.1.2.1, VC ID: 10, VC status: up
    Output interface: Fa0/1, imposed label stack {18 16}
    Preferred path: not configured
    Default path: active
    Next hop: 172.16.2.0
  Create time: 01:16:07, last status change time: 01:15:44
  Signaling protocol: LDP, peer 1.1.2.1: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:
    [cut]

Now, setup and test VLAN connectivity on customer side:

Net1_H1#sh run int fa0/0 | beg interface
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
end
Net1_H2#sh run int fa0/0 | beg interface
interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
 duplex auto
 speed auto
end
Net1_H1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 148/168/192 ms

Frame-relay over MPLS, DLCI-to-DLCI mode

Frame-relay over MPLS requires a few more lines of configuration, but the pseudowire setup is the same as EoMPLS.

We have to enable frame-relay switching on the PE router, configure the Serial interface as DCE and setup the switching path for the DLCI:

PE2

frame-relay switching
!
interface Serial1/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay intf-type dce
!
connect FR2-FR1 Serial1/0 201 l2transport
 xconnect 1.1.2.1 20 encapsulation mpls

PE1

frame-relay switching
!
interface Serial1/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay intf-type dce
!
connect FR1-FR2 Serial1/0 102 l2transport
 xconnect 1.1.2.2 20 encapsulation mpls

Let’s verify everything is ok:

PE2#show mpls l2transport vc 20

Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
Se1/0          FR DLCI 201                1.1.2.1         20         UP

With this configuration we have DLCI 102 for FR1-to-FR2 traffic, and DLCI 201 for FR2-to-FR1 traffic.

Customer side configuration:

FR1

interface Serial0/0
 no ip address
 encapsulation frame-relay IETF
!
interface Serial0/0.1 point-to-point
 ip address 172.16.0.1 255.255.255.252
 frame-relay interface-dlci 102

Similar configuration on FR2:

interface Serial0/0.1 point-to-point
 ip address 172.16.0.2 255.255.255.252
 frame-relay interface-dlci 201

Some tests…

FR1#show frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len 0
  Num Status Enq. Sent 615              Num Status msgs Rcvd 573
  Num Update Status Rcvd 0              Num Status Timeouts 42
  Last Full Status Req 00:00:24         Last Full Status Rcvd 00:00:24
FR1#
FR1#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 = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

  input pkts 115           output pkts 120          in bytes 32266
  out bytes 33844          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 100       out bcast bytes 31764
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 01:43:39, last time pvc status changed 01:10:26
FR1#
FR1#ping 172.16.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 164/185/220 ms

Please note how the subnet 172.16.0.0/32 on the FR routers does not conflict with 172.16.0.0/31 between P routers; it’s on a totally different L3 domain and it is not routed by the network, but transparently encapsulated in L2 over MPLS packets.

Packet captures

You can find some nice packet captures about this lab at PacketLife.net Captures section, under the MPLS category; they have been taken on P1-P2 link, with inner (pseudowire) and outer MPLS label on top of every packet. They are “LDP_Ethernet_FrameRelay”, which shows how LDP setup the pseudowire circuit, “EoMPLS_802.1q” and “Frame-Relay over MPLS”, which show an ICMP ping encapsulated in Ethernet and Frame-relay respectively.

Anyway, if you don’t know PacketLike.net you must take a tour of that great website, really worth it!

Conclusion and download

This post only shows a little basic configuration of some AToM solutions; there are many more capabilities than which I wrote on this blog. A good starting point is to read documents you can find using links below.

If you want to download this GNS3/Dynamips lab, you can find it here.

References

Cisco.com: MPLS AToM Technical Overview

Cisco.com: Any Transport over MPLS

The following two tabs change content below.
Italian, born in 1980, I started working in the IT area in the late '90s; I'm now a system and network administrator with a deep knowledge of the global Internet and its core architectures.

11 Comments

  1. Marco Rizzi says:

    Nice to hear from you again with this very very interesting post!

    I’ll try the FR part for shure!

    keep it up ,-)
    Marco

    • pierky says:

      I was sure you would be interested in this post! 🙂

      You can test port-to-port Frame-Relay also if you want! Unfortunately, AFAIK dynamips doesn’t support ATM l2transport command, so we can’t try ATM over MPLS!

      Have fun 😉

  2. Bowman says:

    Dear Pierky:
    I try to follow up your lab configuration setup GNS3/Dynamips lab as below:
    All interfaces are FastEthernet. Test Router-Based Ethernet over MPLS—Port Mode.

    R1[CE1],F0/0F0/0,R2[PE1],F0/1F0/0,R4[PE2],F0/1F0/0,R5[CE2]

    R1-F0/0: ip address 172.16.1.1 255.255.255.252
    R5-F0/0: ip address 172.16.1.2 255.255.255.252

    R2:
    ip cef
    mpls label range 101 500000 static 16 100
    mpls label protocol ldp
    mpls ldp router-id Loopback0 force

    interface Loopback0
    ip address 10.10.10.101 255.255.255.255
    R2-F0/0:
    interface FastEthernet0/0
    no ip address
    duplex auto
    speed auto
    no cdp enable
    xconnect 10.10.10.102 123 encapsulation mpls
    R2-F0/1:
    interface FastEthernet0/1
    ip address 10.10.10.2 255.255.255.248
    duplex auto
    speed auto
    mpls ip

    R4:
    ip cef
    mpls label range 101 500000 static 16 100
    mpls label protocol ldp
    mpls ldp router-id Loopback0 force

    interface Loopback0
    ip address 10.10.10.102 255.255.255.255

    R4-F0/0:
    interface FastEthernet0/0
    ip address 10.10.10.4 255.255.255.248
    duplex full
    speed auto
    mpls ip
    R4-F0/1:
    interface FastEthernet0/1
    no ip address
    duplex auto
    speed auto
    xconnect 10.10.10.2 123 encapsulation mpls

    ====================================================
    R2#show xconnect all detail
    Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State
    UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No Hardware
    XC ST Segment 1 S1 Segment 2 S2
    ——+———————————+–+———————————+–
    DN ac Fa0/0(Ethernet) UP mpls 10.10.10.102:123 DN
    Interworking: none Local VC label 101
    Remote VC label unassigned
    pw-class:

    R2#show mpls ldp discovery
    Local LDP Identifier:
    10.10.10.101:0
    Discovery Sources:
    Interfaces:
    FastEthernet0/1 (ldp): xmit/recv
    LDP Id: 10.10.10.102:0; no route
    Targeted Hellos:
    10.10.10.101 -> 10.10.10.102 (ldp): active, xmit

    10.10.10.2 -> 10.10.10.102 (ldp): passive, xmit/recv
    LDP Id: 10.10.10.102:0; no route

    =================================================================
    R4#show mpls l2transport vc de
    Local interface: Fa0/1 up, line protocol up, Ethernet up
    Destination address: 10.10.10.2, VC ID: 123, VC status: down
    Create time: 00:04:41, last status change time: 00:04:41
    Signaling protocol: LDP, peer 10.10.10.2:0 down
    MPLS VC labels: local 1000, remote unassigned
    Group ID: local 0, remote unknown
    MTU: local 1500, remote unknown
    Remote interface description:
    Sequencing: receive disabled, send disabled
    VC statistics:
    packet totals: receive 0, send 0
    byte totals: receive 0, send 0
    packet drops: receive 0, seq error 0, send 0

    R4#show mpls ldp discovery
    Local LDP Identifier:
    10.10.10.102:0
    Discovery Sources:
    Interfaces:
    FastEthernet0/0 (ldp): xmit/recv
    LDP Id: 10.10.10.101:0; no route
    Targeted Hellos:
    10.10.10.102 -> 10.10.10.2 (ldp): active, xmit

    ============================================================

    Do you know What kind of reason let both interface show “Remote VC label unassigned”??

    Thanks for any advise.

  3. pierky says:

    Hi Bowman,

    it seems R2 doesn’t know how to reach 10.10.10.102 (R4 loopback); you should check your routing table and add static routes or a routing protocol.

    You should also modify the R4 xconnect peer, otherwise the circuit won’t go up:

    xconnect 10.10.10.101 123 encapsulation mpls

    Bye,

    pierky

  4. Sean says:

    Stumbled onto your blog by mistake; glad I did–there is some interesting stuff here. Question for you on this one, though. Can I combine the P1 and PE1 configs? The reason I ask is that we have a L3 MPLS WAN which requires us to run BGP with the provider and redistribute back to EIGRP. I was thinking I could use AToM to create a pseudo wire between all my WAN routers. Then I wouldn’t have to redistribute EIGRP because all the WAN sites could “see” each other over the pseudo wire. I would then need just a minimal BGP config (or possibly none) with the provider. So, back to my question: can I combine P1 and PE1 configs? And the next question: do you have an example of a config that I am suggesting?
    Thanks,
    Sean

    • pierky says:

      Hi Sean, I’m glad to see that my blog is useful to you!

      Of course you can “merge” P routers and PE routers functionalities, but I don’t think this may be the solution in your real network.

      In this lab you just have to remove links between PE1-P1 and PE2-P2, then add a direct link between PE1 fa0/1 and PE2 fa0/1 and change PE2 IP address:

      interface FastEthernet0/1
       ip address 172.16.1.0 255.255.255.254

      If I’m not wrong your goal is to have both routers on the same network segment and subnet, but you can’t achieve this layout on your own, you have to ask your provider to build the pseudowire circuit between your routers.

      Anyway I’m a bit unsure about your real needs, I guess I didn’t understand them very well.

      Pierky

  5. bandsxbands says:

    I have a love-hate relationship with digital memory because of how prices are always dropping. I hate buying SD Cards for my R4 / R4i at (what seems to be) a cheap price only to see it become 10% cheaper a few weeks later.(Submitted using NetSurf for R4i Nintendo DS.)

  6. icha says:

    hello pierky, what ios router that you use for this.. sorry for my bad english, but you know what i mean, right?

  7. sidd says:

    excellent..thanks for explaining it with a lab…

  8. muhammad sheriyar says:

    Thanks for the nice share. transportation

Leave a Reply