Why is there no way to make a second tunnel “standby” I have two 1350s deployed in two DCs that share a LAN (they have a l2 connection outside of the peplinks). When I peer up both 1350’s with a remote site, they learn the same routes over both tunnels. Even when I put an OSPF cost of 1000 on the secondary tunnel and in the remote device I put in an outbound policy to prefer the primary tunnel first, I still get random traffic over the secondary tunnel. It seems to me that just putting the second speedfusion tunnel in “standby” would make for a pretty easy fix? If not how do I fix this?
Please share the firmware version of both Balance 1350 and the remote device.
1 Like
7.0.1 build 2094 on the 1350s
And
7.0.2 build 3155 on the HD2s
Please share your network diagram with IP subnets. You may put the fake IP subnets, I just want to review your design. If this sensitive, please open ticket for us to take a closer look.
1 Like
At the head end both 1350 have LAN connection in the same address space, let’s say 192.168.1.0/24
1350#1 is 192.168.1.171
1350#2 is 192.168.1.169
Additionally, both head end peplinks have 0.0.0.0 0.0.0.0 static routed to their LAN side.
There is also an open ticket from my team with Frontier (ticket number 777347)
Ticket number 777347 is not reporting this issue. Anyway, I have checked your settings and status of the SpeedFusion connection. The SpeedFusion connection is working as expected. I randomly check 3 of the remote sides. The SpeedFusion tunnel of 3 remote sides shows “Established” to primary DC and show “Updating Route” to secondary DC. This is the expected behavior.
Can you elaborate more of your problem below? How you notice there is random traffic over the secondary tunnel when the second tunnel is showing “Updating Route”?
1 Like
The issue isn’t with all sites. In the diagram below. The sites that use CTL MPLS do exactly what you have stated, they never establish a secondary tunnel, they just keep cycling though (this is where I wish there was a way to make that tunnel 2nd priority/standby). However on the sites that are L3 MPLS they do establish their second tunnel and when they do, we see packet drops because the packets appear to be load balanced across both tunnels. In the L3 sites the only difference is that we only have one head end MPLS connection, there is no redundant MPLS at the head end site. However this shouldn’t matter since ospf on the tunnel is still configured at 1000 for the redundant 1350’s tunnel and the outbound policy is set to priority for the 1st tunnel.
[/uploads/peplink/original/2X/7/77b4b49c4547cfd6db29e8dd8db5326b173c1fce.png]
Please PM me the serial number of one of the L3 MPLS sites for further checking.
1 Like
The provided device of L3 MPLS site only has 1 SpeedFusion tunnel established to primary DC. Possible to establish SpeedFusion tunnel to secondary DC for me to observe the problem? May I know the problem is intermittent and easy to replicate?
I suggest opening ticket for this case.
1 Like