Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 38 subscribers
  • Views 855 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XG HO to XG BO advice for multiple paths

Andy Maus

Thanks for looking in.

I'm trying out a lab setup to replace the current end of lifel solution we have in our production environment.

We have a 1GB fibre link between the HO and BO and they are in the same layer 2 broadcast domain.  There is a single DC providing DNS and DHCP at the HO to DHCP clients at BO.  I'm unable to change the subnet range at either site.

What I'm trying to achieve is the following:

  1. Site-to-Site LAN traffic (172.16.1.0/24)
    1. Primary route via fibre link
    2. Secondary route via P2 (WAN) IPsec/RED tunnel if fibre link fails
  2. External traffic
    1. Primary route via local P2 WAN gateway
    2. Secondary route via fibre link to remote P2 WAN gateway

My test environment looks like this:

I've had mixed results so far with my tests.

I set up a RED interface and bridged with P1 (LAN) which routed between HO and BO via P4 (configured as WAN) and the external traffic routed out via P2 (WAN) without any trouble, but I've been unable to find how to add a secondary RED tunnel to provide failover.  Unlike the diagram example given in KB336999 Deployment Scenarios where "If SFOS_WAN1 is down: RED_WAN1 will connect to SFOS_WAN2" I'm trying to get "If SFOS_WAN1 is down: RED_WAN2 will connect to SFOS_WAN2".

I also tried setting up IPsec Site-to-Site as per Configuring Site-to-Site IPsec NAT and was able to set up a failover group on the BO which worked as far as the tunnel was concerned, but the NAT didn't work for me and I was unable to pass any traffic in either direction.

I'm sure that I'm re-treading old ground for many of you, but my searches have brought up more questions than answers (many of which are many years old) and any pointers would be very helpful.

Thanks again,

Andy



This thread was automatically locked due to age.
Parents
  • 0

    If you bring NAT to this table, you need to rethink your concept. Basically a 1:1 NAT will bring a transfer network to the table to avoid the duplicate usage.

    If you bridge the RED together, this will lead to a bad design, but basically will work. Your KB is about RED as a product, not the Site to Site version. In XG site to site via RED, you simply deploy two RED tunnels to both connections at the same time, which will be activate all the time. 

    You can put both into a Bridge, this will make the routing kernel crazy, so dont do that. You will have to work with NAT in this scenario. 

    There would be a edge case with SD-WAN PBR, where you could do this, but i never reproduce this. In this case, you would use one RED tunnel and bridge this together with your LAN. Then you force XG via SD-WAN PBR to use another gateway for RED, in case the first link is down, to connect the same RED interface to the other Interface. 

    Basically i would highly recommend to change your network, if you have the chance to do it. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Thanks for taking the time to reply.

    As changing the subnet range at the BO is not an option to me, I'll try the SD-WAN PBR with RED interfaced bridged with LAN.  Other than KB39331 (SD-WAN policy routing: Description and Configuration) are there any other KBs or guides you might be aware of that can fill in the gaps for me?

Reply
  • 0 in reply to LuCar Toni

    Thanks for taking the time to reply.

    As changing the subnet range at the BO is not an option to me, I'll try the SD-WAN PBR with RED interfaced bridged with LAN.  Other than KB39331 (SD-WAN policy routing: Description and Configuration) are there any other KBs or guides you might be aware of that can fill in the gaps for me?

Children
  • 0 in reply to Andy Maus

    I am curious, why is this not possible to change the Subnet, if you move the product? Because right now, you are in the position to lift this bad design for good. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    We have a number of statically assigned IPs in the 172.16.1.x network at the BO.  Some we don't have access to such (CCTV  systems) so would need to co-ordinate with 3rd parties.  Timescales are pretty tight for me taking the BO offline and reconfiguring any static assigned devices so I thought the RED with a primary and secondary would provide a simple swap out.

    Although not shown on the diagram above, there is also a VOIP server at HO which BO users handsets connect to on the 172.16.1.x network so keeping the L2 broadcast between both sites seems like the least complex option (in the short term).

    At this point, I've been unable to route any traffic using IPsec tunnels between the 2 demo sites.  The single RED tunnel works as intended between P4 to P4 and passes traffic without any trouble but only if I bridge the P1 LAN with the RED interface so I'm unsure how to manually apply the required routing/rules for SD-WAN PBR.

  • 0 in reply to Andy Maus

    I highly recommend still to go the way to change this network stage or work with a simple RED site to Site. 

    At this point, high availability with RED will not work, as you have to bridge this into a big loop. (actually it could work, if STP prevent this, but i am not sure, what will happen in such cases). But You will not be able to prioritize or route anything. 

    If you start to NAT, you will have to introduce a entire new Subnet, as 1:1 works that way. 

    As you can see, this is not a easy setup in the first place. 

    __________________________________________________________________________________________________________________

Unfiltered HTML