Showing results for 
Search instead for 
Did you mean: 

Want to configure etherchannel over point to point link of different ISP

Want to configure etherchannel over point to point link of different ISP

New Contributor III
Want to configure LAG over point to point link of different ISP?
In below figure, we want to configure Fa0/1 and Fa0/2 LAG and both port 1 and 2 are connected via different ISP service provider.
Is this possible to perform on X440 switches?
WAN connection is L2-MPLS.



Extreme Employee
just my 2 cents... if the ISP connections are both pseudo wire, as Erik already suggested, you can run LACP across both links, however, it might make sense to double check (get it in writing) that L2CP (layer 2 control protocols) can pass over both connections.

Using LACP will help the x440s know/determine if there is a problem in one of the ISP networks and disable a dead link that still physically appears to be up.

It is my understanding that L2CPs use 'well known' destination MAC addresses and normally would not cross a switched link, the service provider would have to specifically provision the UNI to pass these well-known mac addresses/multicast mac addresses... if they do not, then LACP will not work.

from the LACP wiki
  1. LACP packets are sent with multicast group MAC address 01:80:c2:00:00:02 (01-80-c2-00-00-02)
hope that helps


Contributor II
Hi Alok,

you write that the WAN connection is layer 2 (L2VPN) over MPLS, and call the links point-to-point. That would usually be called pseudo wire, and should allow all layer two protocols between the two ends of a pseudo wire.

In the above case, you can in principle configure a LAG over the two pseudo wires. A LAG should always use LACP, thus the pseudo wires need to transport LACP. The X440 switches support LAG with LACP (a LAG is called load sharing on EXOS and configured using the command enable sharing). It primarily depends on the pseudo wire services how well this works. It is technically possible to use a static LAG, i.e. without LACP, but this cannot handle problems inside one providers MPLS cloud where the switch interfaces stay up, but data is not transported successfully.

That said, using layer 3 with dynamic routing, e.g. OSPF, over the WAN connections would be my preferred solution. OSPF on EXOS requires at least an advanced edge license, the X440 comes with just an edge license by default.

If you do not want to use OSPF, EXOS allows to bind static routes to a ping probe or even BFD, this is called static route protection and configured with the command configure iproute add protection. Note that this command was added in EXOS versions 16.2 and 22.1 and is part of the edge license level.


New Contributor
It might be possible if the two different ISPs agree to purchase the same switch/router at your connection point *and* run something like vPC between their switch/router. I am doubtful this will be the case. If you are looking to solve a resilience problem, look to run OSFP. If you are looking to increase throughput then you will need to widen the pipe between you and your ISPs.

LAG is a layer 2 construct, OSPF is layer 3. I am assuming that your connection is routed to your ISPs and not switched and even if it is switched, it is doubtful the two ISPs are serving the same VLANs over their connection to you making EtherChannel a non-starter option.

OSPF is (was?) a common method of providing redundant connections between multiple routers. I would start here . Your ISPs will need to support OSPF as well and I do not know whether or not they would need to share routing information with each other for this to work. I would think they would not need to share routing information but I have never tried what you are attempting to do. You will need to take care to not advertise your network as a routing option for either of the two ISPs.

The only other option I can think of is to assign different metrics for each route to your ISPs. You would need to check what happens to latencies when the lower cost route stops working. I do not know how ExOS handles this situation but I would think it would eventually use the higher cost routing option; possibly at the cost of latency.