BGP Routing Issue: Traffic Still Preferring Default Route Despite Prepending and MED Adjustments
-
Another option to think of and I'm not sure how well this would work is for each BGP peer, you have gateway monitoring enabled. Monitor IP can be whatever you want just different for each BGP peer.
There is an option when the gateway fails to kill states
https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html#state-killing-gateway-failure
-
@michmoor
I actually have that enabled….i forced the gateway down but it still didn’t reset the states until it was actually down… -
@Kevin-S-Pare
Ok yeah that sucks…migrate… -
@michmoor yup! Ordering the Cisco today
-
@Kevin-S-Pare
Just frustrating.
This is a similar situation I ran into with Cumulus. I’m all for open source software and do want to support but there are just situations I find myself in where something basic just doesn’t work. whether it’s an IPsec bug or dynamic routing. It’s just frustrating so I understand where you are coming from. -
@michmoor we’ve done some amazing stuff with Netgate so I can’t complain….they are doing great things but they have their limits and their place…
-
If you have the Netgate 8200 or 8300 I forget which one you said, I would seriously reach out to Netgate sales and ask for TNSR. It’s close to Cisco syntax and it’s better suited for your task
-
@Kevin-S-Pare said in BGP Routing Issue: Traffic Still Preferring Default Route Despite Prepending and MED Adjustments:
@michmoor
I actually have that enabled….i forced the gateway down but it still didn’t reset the states until it was actually down…The "force gateway down feature" is a bit misleading and could probably use better wording and or further consideration. Forcing the gateway down doesn't trigger the same action as a link/packet issue hence why it doesn't kill states. If the gateway is forced down, it shouldn't be getting used so the states that already exist on it won't come back once they expire. If you want to immediately kill the states on top of preventing the gateway from being used, then you can force it down then separately kill states for that gateway from either Status > Gateways or Diagnostics > States.
FWIW it sounds like you may have TAC. They are a great resource and ultimately would have been able to explain/resolve both the state policy and gateway issue.
@michmoor brings up some good points about stateful filtering for routing. It does sound like TNSR would be better suited in your environment but that's not to say pfSense couldn't be made to work either. There have been times I've made the same decision to try an alternative product to then later on learn more about the issue and realize how it could have been solved. At the same time for better and worse the alternative brought its own challenges. Those kinds of things keep you humble.
-
@Kevin-S-Pare said in BGP Routing Issue: Traffic Still Preferring Default Route Despite Prepending and MED Adjustments:
@amithb we host hundreds of citrix sessions, and with the states low we are getting complaints about disconnects so we've change the settings back and will be looking to replace pfsense as our bgp router....just isn't working how we need it.
@Kevin-S-Pare - No worries. I think I got some ideas to try from the conversation here.
-
@marcosm The FRR with stateful handling is a big deal. Will there be any incoming fix? Redmine was noted a few posts above
-
-
@marcosm Yes if that can be reviewed that would be great. As outlined in the ticket, dynamic routing just plainly doesn't work and there are no workable in-place solutions. As of now FRR would only work with a single routing adjacency.
-
@marcosm
Curious but is the only way to have dynamic failover with BGP/OSPF is to manually kill states? Looking for confirmation for the best path forward. -
@michmoor I don't know. I have a lab set up for BGP/OSPF but I need to spend time testing and understanding what exactly is happening.
Edit: See https://forum.netgate.com/topic/196577.
-
@marcosm
I saw your change of the clarification of killing states in the gateway group (redmine). I think the wording is better as it makes reference to states formed using POLICY. Should you put something like "POLICY ONLY" or "POLICY ONLY not FRR" or something to that affect?To me at least it tells me that for sure states created due to FRR is omitted.
-
@michmoor It's not specific to FRR so I don't it warrants mentioning that specifically on those options. To clarify, I updated the description for the global options, though looking at the gateway groups themselves they could use clarification as well.
-
@marcosm understood. i was just adding unsolicited feedback :)