Register a SA Forums Account here!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
  • Post
  • Reply
Nov 4, 2008

feld posted:

Hi guys,

I need some VRRP help badly

The issue is this: I have two VRRP instances running on each RB1100. One is VRRP-External and the other is VRRP-Internal

The problem is that only whole device failover works. If the one that is MASTER for both is running and you unplug the internal interface only the internal interface fails over to the secondary router.

This is not good. Effectively what happens is the traffic keeps flowing to a router but now it has no way to get out because it is not master of the VRRP-External.

I assume this could be figured out with some script? So far I'm not having any luck figuring out what I need to do it. I've located some scripts but even when I tell them to run the run count doesn't go up... I'm referring to this thread:

Thanks to anyone who can help!

You ain't running no dynamic routing protocol (which should detect the removed cable and announce the lack of connectivity upstream to the external ~cloud~).
Static route solution: Add a cable between the 2 routers, add a static route with less precedence to the other router. Repeat for the external interfaces' routes.
I assume mikrotik has route precedence (linux kernel does) and that you have a spare port on each router and a spare cable
Even with dynamic routing you may want to run a cable between redundant routers.


Nov 4, 2008

feld posted:

Negative, it does not have this feature. Sounds like Vyatta did VRRP the right way...

Even running a dynamic routing protocol on the network would not solve it. I don't think you're considering that I'm using VRRP and no routing protocol can detect that a cable has been removed because of how VRRP works....

Router-A injects a connected route into OSPF, so does Router-B. OSPF domain sees two announcements for the client network.
Cable is cut, interface goes down, router-A doesn't announce route into OSPF anymore. Router-B is still injecting the connected route into OSPF, the OSPF area still can see an announcement to that route.

But client side (I'll assume a DHCP LAN full of PCs) aint't doing dynamic routing, so if the master VRRP loses upstream connectivity, you're hosed, yeah.

feld posted:

I was actually discussing this with a coworker last night and the only good solution we could come up with is to run a cable between both Mikrotiks and run OSPF.

* Cable gets unplugged
* Traffic routes to other Mikrotik which is in Backup mode for the uplink side
* OSPF routes traffic over to the other Mikrotik which has Master
* Off to the internet it goes!

This should work fine as long as VRRP plays nice and when you're the Backup it doesn't have the uplink's entries in the routing table. We have yet to test that, though.

You don't need OSPF just for the backup solution.
Router-A's got a connected route to the client LAN, now add a static route to that network via the crossover cable to R-B and a reciprocating route on B. Packets coming from upstream will reach the clients as long as 1 connection to the LAN stands. This will generate a nice routing loop if both LAN cables are cut, but then who cares?

For the other side I'll assume a default route. Add a static route on R-A pointing to R-B with a "distance" higher than 1 (the default distance for static routes) and vice versa. Again, you got yourself a nice routing loop if both upstreams are cut.
Grep for "distance":

mikrotik posted:

Value used in route selection. Routes with smaller distance value are given preference. If value of this property is not set, then the default depends on route protocol:

connected routes: 0
static routes: 1
eBGP: 20
OSPF: 110
RIP: 120
MME: 130
iBGP: 200

TL,DR: use OSPF, gently caress this poo poo.

Nov 4, 2008

feld posted:

I certainly know how OSPF, etc works, so I know what you're talking about. However, we implemented the Mikrotiks for the customer tonight and all but one failover scenario worked correctly. (Mind you, we have IPSec VPNs and whatnot also involved which makes this setup pretty rad because the IPSec failover is nearly instantaneous in our testing)
Sorry, didn't check your proficiency level. So it's just them mikrotiks between the LAN and an internet router? No OSPF otherwise? Like the map at

feld posted:

OK, so current failing "failover" scenario:

* Router A is master
* Connections to LAN on are cut on Router A
* Router B picks up as master for LAN's gateway
* Router B has an extra link going back to Router A with OSPF going over it and all the VPNs
* You can still contact all INTERNAL networks (local and over VPNs) that were advertised by OSPF. However, you can't access the internet because Router B isn't the master of the uplink so its default route is failing

Thoughts? How can I get OSPF to tell the other router that it has access to the internet and inject a default route into its table telling it to go over the link between the routers?

I'm very tired right now and haven't put a lot of thought into this scenario, but outside of scripting or possibly trying to add a second default route with a higher distance... I'm stumped

We have equipment to test this tomorrow so hopefully we can come up with a solid and reliable solution.

I'm a bit confused on why R-B doesn't have a default route active all the time. VRRP is removing the routes towards an active up/up interface when not master? Do you have static IP adresses on the physical ethernets in addition to the virtual router IP?

But yeah, redistribute the default route into ospf, dont't give a gently caress. That's what routing protocols are for, not giving a gently caress.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply