Any Transport Over MPLS (AToM)

Hello Rene,

I have the same message as Bounpasong:

PE1(config-if)#xconnect 13 encapsulation mpls
Incompatible with ip address command on Fa2/0 - command rejected.

I am okay to remove the IP address but OSPF and MPLS will go down…

How did you manage this situation ?

Thanks a lot,
Kind regards,

Hi Rene / Andrew
Another awesome job / lesson
I re-created the scenario, but I can see we will have an MTU problem- I understand the obvious next step would be to increase it on MPLS enabled interfaces because of additional overhead ?
What would be recommended size of MTU on them ? 1526 bytes?
Thank you

I believe ip mtu 1456 would do the trick, and here’s why:

1500 (default) - 20 (TCP Header) - 20 (IP Header) - 4 (MPLS Label) = 1456

Hi Rene,

At HQ and Branch there is L2 connection.

If yes then how we are giving ip address on this interface.


You are right that ATOM uses an layer 2 (really a layer “2.5”) encapsulation via MPLS. Because of this, the provider network has no knowledge of what is happening at higher layers. This means you can treat the HQ and Branch interfaces just like you would any other ethernet port–just assign IP addresses normally.

Hi Rene,

If my network backbone is not support Jumbo Frame, but i want to run the EOMPLS.

Definitely there’s MTU issue, how we can address this? Can we set any IP PMTU or IP MTU for this EOMPLS?


With a network backbone that doesn’t support jumbo frames (meaning frames larger than 1500), you might have some trouble. Common practice is to set the entire core to support an MTU of 9216. You would have to support 14 bytes for Ethernet, 4 bytes for a VLAN tag (if you are using 802.1Q), 4 bytes for MPLS. So, far, that is 22 bytes of overhead, which would reduce your payload size to 1478. Whether you can force your MTU down so your core won’t exceed 1500 bytes, I just don’t know.

I did find an article that might be of help, though:

In the article, it states that the MTU on the physical ports must be set to at least 1504, and that the x-connect protocol actually checks to see whether the other end of the circuit has the same MTU.

Ok. Noted.

Thanks Andrew.

19 posts were merged into an existing topic: Any Transport Over MPLS (AToM)

Hi Rene,

Need your awesome lesson regarding VPLS/HVPLS/MPLS-TE very soon .The topic need to learn badly & you know your write up is simply excellent as compared to any other , Challenge !!! .So ,eagerly waiting for your excellent lesson.Thx


1 Like

i think i find it .

1 Like

wt’s the difference between AToM vs VPLS?

Hello Ray

Both AToM and VPLS are technologies that are enabled by MPLS. As such they are related, but are each distinct and used for slightly varying purposes.

AToM is an open standards based architecutre that leverages the label switching architecture of MPLS. It can be integrated into any network that is running MPLS. The major advantage is that it can connect any technology (Frame relay, ATM, IP, Ethernet) so the customer doesn’t need to change anything. They don’t even need to run IP to the edge of the network to connect. Now AToM is a point to point service and thus cannot support broadcast frames.

VPLS on the other hand is a technology that does support multipoint to multipoint topologies. It is specifically geared towards applications that require multipoint and broadcast access.

I hope this has been helpful!



I’m wondering what is the exact benefit of using targeted LDP session, especially in the case of AToM. Why we need targeted LDP session between PE routers, I think even if we dont have targeted LDP session we can pass traffic through hop by hop learning.

Karthik N

Hello Karthik

A targeted LDP session is required between LSRs that are not directly connected. This is especially true concerning an AToM network. Specifically, an LDP session must exist between each pair of PE routers. The remote LDP session is actually set up when the xconnect command is initiated on the PE routers of the AToM network.

I hope this has been helpful!


Thank you for reply post.

Yes, its requirement for AToM we must have targeted LDP session, but the technical standpoint whats the benefit/value add of having targeted LDP session ?

I read it will protect the session for longer time compared to directly connected LDP session, apart from that I unable to come up with any reason why we need this.

Karthik N

Hello Karthik

One reason for this is that it improves label convergence time. If you have two PE routers that are separated by three or four hops for example, and there is network instability, the targeted LDP packets will still be able to be exchanged between the two PE routers via alternate routes within the network (assuming dynamic routing and redundancy are part of the network design), even if some links may have been compromised. In this way, the adjacency session will be maintained because the targeted LDP packets found outer routes to reach the two PEs. If targeted LDP sessions were not used, and network instability ensued, adjacencies would be lost and would have to be re-established, causing some network downtime.

BGP can be configured to function in a similar way, when using multi-hop, where neighbour adjacencies can be created between two non-directly connected routers.

I hope this has been helpful!


Thank you Laz.

Karthik N

1 Like

Why two MPLS header added in the EoMPLS packet transmission?
EoMPLS packet format:

On what basis it switches the packet if there is two label ?

Thanks and Regards,

Hello Srinivasan

Like all AToM, EoMPLS requires the use of two level labels. Specifically, Cisco states:

AToM uses a directed Label Distribution Protocol (LDP) session between edge routers for setting up and maintaining connections. Forwarding occurs through the use of two level labels that provide switching between the edge routers. The external label (tunnel label) routes the packet over the MPLS backbone to the egress PE at the ingress PE. The VC label is a demuxing label that determines the connection at the tunnel endpoint (the particular egress interface on the egress PE as well as the VLAN identifier for an Ethernet frame).

I hope this has been helpful!