I wasn't questioning whether the state/gigapop is or isn't using BGP, I meant was BGP involved in your various incidents specifically? I get the feeling this kind of flip flopping of routing is sporadically occurring in a semi regular basis or something and not just a single isolated incident. As for failover, I take it to mean a failover pair in an active-standby configuration and the standby unit becomes the active unit when one of these network incidents occur? I would look into a tool like ping plotter. It will identify route changes, route performance, destination reachability, etc and have all of the historical info available from the duration of when you're running it. You can run it against the responder.sonicwall.com target and compare it's results to that of the behavior and/or logs of the sonicwall themselves. <div>-------- Original message --------</div><div>From: Raymond Norton <admin at lctn.org> </div><div>Date:01/20/2015 9:36 PM (GMT-06:00) </div><div>To: TCLUG Mailing List <tclug-list at mn-linux.org> </div><div>Subject: Re: [tclug-list] OT network question </div><div> </div>Network engineers from the state communicated to me they use BGP. The Sonic does not use BGP. The northernlights hop is a good 10 hops away. The Internet works for all other districts at the same time the sonic flips over to the fail-over, with no complaints that specific sites cannot be reached. I can only assume the state really is using BGP. The one constant is the school traffic always follows the same path to responder.sonicwall.com On 01/20/2015 09:19 PM, Justin Krejci wrote: Well I guess I would ask how is it you know there is a BGP route change happening? Do you have bidirectional traceroutes? Much of the Internet has asymmetrical routing so even if you don't see a problem or change in one direction that doesn't mean the return path is the same or is problem free. In general, yes your pings will continue to work under a normal BGP re-routing, you may just see a change in RTT if the new path is faster or slower than the previous one. There is nothing special about plain old pings that would otherwise be affected by a route change. What could be possible is one router along the problem path has some kind of filter that is filtering pings, doing DPI with some kind of filtering policy, or some other wonky behavior. It's it clear if the sonicwalls in question are doing BGP or not (sounds like no). It is also not clear of the gigapops hop is the the sonicwalls first hop or not. -------- Original message -------- From: Raymond Norton Date:01/20/2015 8:56 PM (GMT-06:00) To: TCLUG Mailing List Subject: Re: [tclug-list] OT network question > My un-educated answer: it depends. If the BGP route is the next hop > from the machine sending the ping, then yes, you'll probably need to > restart. The ping instance will continue to want to use the broken > path as its next hop. If, however, you're downstream from the BGP > route (another hop between you and the BGP router) it shouldn't matter > because your machine's next hop wouldn't change. > > Does that describe the behavior you're seeing? Specifically, this is what we have going: A couple school districts use Sonicwall firewalls. The fail-over system does a sustained ping to responder.sonicwall.com. The path it takes 100% of the time always hits northernlights.gigapop.net (146.57.252.194) and another dozen hops after that. The state has been having a lot of difficulty with this hop, because of some major routing changes made by the U of M for traffic destined to Chicago. Almost all of our districts never know there is a problem, because BGP on the state routers finds a better path. However, the two districts (both use sonic) sustained pings insists on using the northernlights hop, thus triggering their fail-over circuit, even though there is not an actual Internet outage. Just trying to come to a definitive reason why this occurs so I can possibly find a fix . _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list -- Raymond Norton LCTN 952.955.7766 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20150120/0b424e7a/attachment.html>