OSPF Routing
-
Good morning,
My central server is learning an route from our MPLS network that is then being redistributed to my VPN networks. Is there a way to block an OSPF route? I have reached out to the MPLS provider but they "require" this or will have to restructure their routers causing us to be down until its rebuilt… Basically, on our mpls, we also have a Inet drain. They are advertising a 0.0.0.0 route via ospf which in returns, then shares this route throughout my network. This has been causing problems for some time now as the O route will suddenly take priority over the routers kernel route making the network thin it takes the VPN to get to the Inet.Yes OSPF routes should not take priority, but they are and its completely random when it happens. My OSPF route for example on a normal day will be: O 0.0.0.0/0 [110/0] via 10.11.1.2, bge0, 07w1d17h (10.11.1.2 is my vpn back to my central site where it learned the 0.0.0.0/0 route via 10.10.15.1 (mpls network).
Once I get a call that inet is slow or not working at all, i jump on the router and the route now appears as:
O* 0.0.0.0/0 [110/0] via 10.11.1.2, bge0, 07w1d17hIn order to restore service, I have to reboot the router to get the route corrected. If theres a way to prevent this route, please let me know. I have been going back and forth with our MPLS provider and we are to the point we will pull away from mpls as its causing more problems than what it provides.
Thanks for taking the time to read this.
-
Also - regarding the same topic, this also breaks my vpns. once my vpn addresses are shared, and redistributed via mpls ospf, say my vpn on site A will go down, but in my routing table, you will still see the vpn address via mpls router. Rebooting is a quick fix. Other wise, I have to disable the interface from OSPF, wait until the tables clear on their own as restarting quagga will break connection.
-
You may be able to use an accept filter in quagga. Enter the exact route you don't want in the list on the Global Settings tab, tick "Disable Acceptance" and save.
Though I don't remember how well that works in quagga. It worked the last time I tried it in the FRR package though.
-
I know in previous versions, we (pfsense support) enabled this and it did not help. I have not tested in this version but will give it a shot. We did not try it for the any any route but for the vpn addresses as the routes being advertised from the mpls was causing hangups if the remote vpns went down. Routing table would still show the route resulting in the ifconfig command during the vpn starts up fails due to fatal error (typically we have multiple vpns for redundancy at each site). Will test and let you know how it goes.
With the VPN - the fatal error is due to the route already exist. If we manually change the Ip via ifconfig, it comes right up since the new address is not present.
-
Yeah, the quagga package has always had issues of that nature. The FRR package doesn't seem to suffer from the same limitations though. You might give it a try instead.
-
Good to hear as I was unaware of the FRR package. Do we know how stable it is? I see that it offers BGP as well as OSPF to run together. Could I run this on one site to test what I see prior to changing everyone? If it has more stability, im all for it! i'm actually about to build two routers for a new site going up Monday so i will install this and see how it looks.
-
The FRR package should be at least as stable as quagga. The OSPF stuff especially.
-
And just out of curiosity as im sure this is an OSPF thing all together, but in the event the central site needs ospf restarted, does this drop everyone for a few seconds to update their tables? I know this has been an issue deploying new sites and bringing up during mid day. We are pretty much a 24-7 manufacturing company.
-
It still restarts when making changes, so that would bump things momentarily.
We've looked into more of a live/vtysh style method of maintaining it but at the moment it isn't viable for the package to work that way.
-
Gotcha - I figured as much. We run rds connections via wyse thin clients through our broker and 1-2 drops disconnects their session. CSR's complain but it doesnt kill them as a simple click back in, but production may not be at their machine. We run live monitoring on our plant machines and this is where the issue comes into play as if they do not reconnect quickly, the RPM data is lost.
Anywho thats an issue in itself so with that being said, I will test this package and see how it goes. Thanks!
