Is the customer connecting via PPPoE? That would generate a /32 route that is being advertised.
No. There is a hotspot involved, but we’ve already tried bypassing that and no difference. Any routing marks involved? Any mangle or firewall rules which would match this customer and not others? No When you're saying "traceroute stops at", is that the site giving the last reply? Yes One other thing....I had a couple of anomalies go away when I switched OSPF interfaces from broadcast to point-to-point mode. I thought the only difference was the OSFP messages are sent unicast, but a few goofy things stopped happening when I did that. That’s something I hadn’t thought to try. Would I need to do it on all interfaces involved? or just from Tower B to Tower A? (that’s where the issue seems to be, even though I can still reach the customer from Tower B, just not the NOC) Thanks, Justin From: Af [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, March 31, 2017 1:34 PM To: [email protected] Subject: Re: [AFMUG] Strange OSPF problem Is the customer connecting via PPPoE? That would generate a /32 route that is being advertised. On Fri, Mar 31, 2017 at 1:27 PM, Adam Moffett <[email protected]<mailto:[email protected]>> wrote: Any routing marks involved? Any mangle or firewall rules which would match this customer and not others? When you're saying "traceroute stops at", is that the site giving the last reply? What if you specify different source IP's on your traceroute from the NOC? Maybe tower A is missing one route, but not others. One other thing....I had a couple of anomalies go away when I switched OSPF interfaces from broadcast to point-to-point mode. I thought the only difference was the OSFP messages are sent unicast, but a few goofy things stopped happening when I did that. ------ Original Message ------ From: "Justin Marshall" <[email protected]<mailto:[email protected]>> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Sent: 3/31/2017 12:55:43 PM Subject: [AFMUG] Strange OSPF problem Hi, I have an odd situation with OSPF. There are 2 towers (Tower A and Tower B) and a NOC involved that feeds both towers. Tower A is directly connected to the NOC via Mikrotik Backhaul. Tower B is directly connected to the NOC via Fiber. Tower B is connected to Tower A via Fiber. When tower A is running straight off the NOC (via Mikrotik Backhaul) everything works as it should. We are trying to make a switchover to have Tower A run off Tower B so it will be a Fiber connection all the way to Tower A (through tower B) and eliminate the Mikrotik Backhaul. When I change cost on the OSPF interfaces to make this happen, all customers work as they should and following the normal path to/from the Internet as expected. However, for one of the customers on Tower A, traceroutes to that one customer stop at Tower A (through tower B) from the NOC. Traceroutes towards the NOC, from the customer stops at Tower B. All customers are on the same subnet. I can directly ping the customer in question from both Tower B and Tower A (and the traffic is taking the correct path), but not from the NOC. From the NOC all traffic stops at Tower B The only real difference for the customer that is not working is they are using a Sonic Wall, and the other customers have Mikrotik routers behind the CPE's. We have tried elimating the sonc wall, and replacing it with a laptop for testing, and the traffic flow failed in the same way. Tried all kinds of things and we are quite stumped. Anyone have any suggestions? Thanks, Justin [email protected]<mailto:[email protected]>
