Brainstorming for multi-site LAN (local), WAN (w/IPsec VPN), LAN (Metro Ethernet) setup


Sorry if this is a bit broad, but just need a nudge in the right direction.

Struggling with how to utilize Metro Ethernet as an SD-WAN path for RO WAN/LAN traffic through HO, and if it is even possible.

Also, similar issue, how to approach using IPsec failover for local LAN traffic in the event Metro Ethernet is down.

Goals are:

  1. To provide failover for LAN and WAN traffic at remotes using IPsec to HO (currently LAN->MetroE, WAN->CableModem)
  2. To provide load balancing for LAN traffic at ROs to HO using the MetroE & IPsec paths

Current schema:

  1. Network LAN traffic is passing over Metro Ethernet to Head Office fine, with OSPF configured and working for 13 RO subnets.
  2. Local internet traffic is passing over local internet interfaces.


Remote Offices XG125/135/210 v18-EAP3.

Port 1 – LAN (local networks) 192.168.n.x/24

Port 2 – WAN (internet and testing IPsec VPN to HO) using local cable modem

Port 4 – LAN (Metro Ethernet handoff) 172.30.255.x


Head Office XG230 v18-EAP3.

Port 1 – LAN (local networks) 192.168.x.x/16

Port 2 – WAN (HO internet, and planned backup internet for ROs) 

Port 3 – DMZ

Port 4 – LAN (Metro Ethernet handoff) 172.30.255.x

Port 5 – WAN (testing IPsec VPN to ROs)

Port 6 - HA




  • It will be much easier with EAP3 Refresh1, because the VTI (Route based VPN) is coming.

    In this concept, you can actually build an IPsec with a Interface and route the traffic with SD-WAN / Static routing.

    In that case, you do not have to figure out, which Precedence comes first. Instead both exists and uses the same "page". 


    Another approach would be: Use RED Site to Site.

    Same setup like VTI. You have an Interface for the VPN, so you can actually SD-WAN Route everything. 


  • Thanks LuCar. The VTI sounds very interesting, while also circling back for a Red second look.

    I actually had a XG Red connection setup between sites to start some testing, when someone suggested it may not be the best for optimization of resources, so I tore it down. Sorry, I should have paid more attention to their reasoning.

  • Well, I am back on this topic, if anyone is interested. I set up RED P2Ps, and I am trying to get  OSPF sorted out, if possible.

    I brought a RED circuit up, and configured 2 LAN gateways:

    1. Port 1 LAN -
    2. Port 4 LAN - (gateway
    3. red1 LAN - (gateway

    OSPF Network

    1. - Area
    2. - Area (showing off my naïveté)
    3. - Area

    OSPF Area


    Everything failed over to RED as needed when I added an to area 0 to the below layout (don't know if that is even kosher), but SIP became unreachable a short while later.

  • Did you check the route precedence?


     /  Maybe somebody could take a look at this one?


    Another approach: Does your Configuration work with static routes instead of OSPF?


    There are two KBAs for this:


    In the second one:


    The default OSPF route is shown in its routing table so it is restricted to be added to the kernel routing table. If admin wants to add the default OSPF route to the kernel, he has to manually enable it from the CLI using the following custom commands.


  • Thanks LuCar,

    Didn't see this, until I tried something, that I would like to file under "Do not try this".

    I hooked up another RED connection to a different remote site for testing, and found the second RED client was displaying the first RED client's external IP in the connection display. Yes, I had set up SD-WAN policy routing on the first site. The SD-WAN seems to be working even better than what I needed. I'm back to my topology drawing board. :)


  • Hi  

    Thanks for the feedback. Let us know in which scenario you are facing issue currently ?


    Rana Sharma