> Is the x.x.36.209 IP on your ImageStream or is 36.210 on your ImageStream? > I know you said it was on the ImageStream. When I traceroute > to x.x.213.1 from the outside, the traceroute stops at "a" > x.x.36.210. It may not be "the" 36.210.
The 36.210 is the IP on the imagestream. Looking back at my original post I can't believe I made the mistake of saying it was the 36.209. Sorry; a little new to describing problems of these sorts in long detailed posts. I guess that would be an important distinction :) My mistake. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Scott Lambert Sent: Thursday, March 13, 2014 3:46 AM To: Mikrotik discussions Subject: Re: [Mikrotik] OSPF Issue On Wed, Mar 12, 2014 at 02:29:06PM +0000, Justin Marshall wrote: > > I wanted to see "in x.x.213.0/24" so that we could see if there was > > any covering route which would send traffic a different direction > > when the /26 went away. > > It may have a covering route in the /20 or /16 or whatever you were > > allocated. > > Sorry I misunderstood that. I'd just thought maybe you were unaware it was a > /26. E-mail is like that. :-) > Tower A: > [admin@Tower-VB_SBA] /ip route> print where dst-address in > x.x.213.0/24 > Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, > r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P > - prohibit > # DST-ADDRESS PREF-SRC GATEWAY DISTANCE > 0 ADo x.x.213.0/26 x.x.214.66 110 > 1 ADo x.x.213.64/26 x.x.215.116 110 > x.x.214.73 > 2 ADC x.x.213.128/26 198.172.213.129 WAP_Bridge 0 > 3 ADo x.x.213.192/26 x.x.214.2 110 > > Tower B: > [admin@Tower-FP_Selvitz] /ip route> print where dst-address in > x.x.213.0/24 > Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, > r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - > prohibit > # DST-ADDRESS PREF-SRC GATEWAY DISTANCE > 0 ADC x.x.213.0/26 x.x.213.1 LAN_Bridge 0 > 1 ADo x.x.213.64/26 x.x.214.65 110 > 2 ADo x.x.213.128/26 x.x.214.65 110 > 3 ADo x.x.213.192/26 x.x.214.65 110 Okay, no covering route in the /24, but there may be at the /22 level since that seems to be the size of the allocation to you. It doesn't have to be a static, it could be a BGP null route or an OSPF aggregated route. > >> Tower B: > >> [admin@Tower-FP_Selvitz] /ip route> print where dst-address > >> x.x.213.0/26 > >> Flags: X - disabled, A - active, D - dynamic, C - connect, S - > >> static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - > >> unreachable, P - prohibit > >> # DST-ADDRESS PREF-SRC GATEWAY DISTANCE > > > Whoa, this is the MikroTik which is supposed to have x.x.213.1 on a > > local interface? Did you just paste one too few lines? We should > > have seen a connected route on that box. > > Maybe that was my mistake by pasting one too few lines, but I'm almost > sure there wasn't anything there the other day when I pasted it. > Issued the same command just now and I got. > > [admin@Tower-FP_Selvitz] /ip route> print where dst-address in > x.x.213.0/26 > Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, > r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - > prohibit > # DST-ADDRESS PREF-SRC GATEWAY DISTANCE > 0 ADC x.x.213.0/26 x.x.213.1 LAN_Bridge 0 *IF* the route is missing when your traceroutes loop, I think there is something going on on Tower-FP_Selvitz which is making that IP fall out of the routing table on that router. It is probably not OSPF related. Are there any netwatch rules related to the subnet? Maybe VRRP? Other scripts? I have no idea what we are looking for. I am just flailing around. Picture that "IF" starting the previous paragraph as being written in 72 point red flashing font. To verify the "IF", I'd like to check your routes in x.x.213.0/24 on FP_Selvitz while the traceroute is looping, if you can catch it. I wonder if a supout could even complete in time that the route is missing from the tables. It takes a while on my systems. A big percentage of 8 to 10 second, IIRC. 8 to 10 seconds is a short window for humans to run a few commands. Running the commands in a script every couple of seconds to catch it automatically could bring your router to its knees. Win, win. Right? > > Okay, the specific /26 route is probably being withdrawn from OSPF. > > > There must be a covering route sending that traffic to the Tower A > > mikrotik in the absense of the specific /26 in order for the looping > > traceroute to occur. The Tower A mikrotik either doesn't have the > > covering route so uses it's default, or has the covering route > > pointed back to the ImageStream. Possibly a leftover static route > > on the ImageStream or the MikroTik at Tower A. > > There aren't any leftover static routes. Not quite sure what you mean > by "covering route". Routing uses the most specific route to a destination address. You can have a x.x.212.0/22 which could be an aggregate of some sort from BGP, or OSPF, or even just a manually configured null route to keep you from sending traffic for unallocated parts of your network toward your upstream. While the /26 route is present, traffic flows in the direction of the gateway for that route. If the route goes away, the traffic will flow in the direction of the gateway for the /23 or /22 which would contain the /26. We know there is no /24. If there is no x.x.212.0/23 or x.x.212.0/22 covering route, the next covering route is probably for dst-address 0.0.0.0/0, your default route. Is the x.x.36.209 IP on your ImageStream or is 36.210 on your ImageStream? I know you said it was on the ImageStream. When I traceroute to x.x.213.1 from the outside, the traceroute stops at "a" x.x.36.210. It may not be "the" 36.210. If x.x.36.209 is your upstream's router on your WAN link and 99.1 is the IP on the ImageStream interface which is closest to your traceroute source device, then your traceroutes are showing the packet looping on your uplink to your provider. If that is the case, your ImageStream is using your default route and your upstream is using the /22 they have installed on their router for your network, via BGP or static, doesn't really matter. > > Are there any interface up or down messages in the logs on the Tower > > B MikroTik? Is STP enabled on the Tower B MikroTik's bridge > > interface? Just grasping at staws. > > STP is disabled on the bridge interface. Also there are no interface > up/down messages in the logs on Tower B Mikrotik. We are narrowing it down even if we don't know toward what we are narrowing "it". > -----Original Message----- > From: [email protected] On Behalf Of Scott Lambert > Sent: Tuesday, March 11, 2014 4:00 PM > To: Mikrotik discussions > Subject: Re: [Mikrotik] OSPF Issue > > On Mon, Mar 10, 2014 at 02:18:57PM +0000, Justin Marshall wrote: > > > > What does "show ip ospf route" look like from the ImageStream for > > > anything in that /24? During the problem and while normal. > > > > Normal: > > N x.x.213.0/26 [30] area: 0.0.0.0 > > via x.x.214.74, eth1.206 > > > > During the problem it disappears from the "show ip ospf route" > > Okay, the specific /26 route is probably being withdrawn from OSPF. > > There must be a covering route sending that traffic to the Tower A > mikrotik in the absense of the specific /26 in order for the looping > traceroute to occur. The Tower A mikrotik either doesn't have the > covering route so uses it's default, or has the covering route pointed > back to the ImageStream. Possibly a leftover static route on the > ImageStream or the MikroTik at Tower A. > > Are there any interface up or down messages in the logs on the Tower B > MikroTik? Is STP enabled on the Tower B MikroTik's bridge interface? > Just grasping at staws. > > > -----Original Message----- > > From: [email protected] On Behalf Of Justin > > Marshall > > Sent: Monday, March 10, 2014 9:51 AM > > To: Mikrotik discussions > > Subject: Re: [Mikrotik] OSPF Issue > > > > > I may be interpreting your message incorrectly. Could you clarify > > > if x.x.36.209 is an IP on an interface on the ImageStream? Or is > > > it on a router at Tower C which may also be connected to Tower A > > > via a wireless link? I suspect it is on the ImageStream. > > > > Yes, the x.x.36.209 is an IP on an interface on the Imagestream... > > > > > So, only the one subnet is falling out? At the time that you get > > > looping traceroutes for 213.1, other subnets run clean? > > > > Yes, only the one subnet is falling out, all other subnets run clean > > > > > Are you only looping for the one IP in that subnet or for all > > > hosts in the subnet? > > > > All IP's in that subnet are failing... > > > > > What does "show ip ospf route" look like from the ImageStream for > > > anything in that /24? During the problem and while normal. > > > > I will answer this as soon as I catch it again... It's so > > intermittent, hard to catch it unless I stare at it...(most of the > > times I don't have to wait too long) > > > > > What does "/ip route print where dst-address in x.x.213.0/24" look > > > like on MikroTik A and B? > > > > Tower A: > > [admin@Tower-VB_SBA] /ip route> print where dst-address in > > x.x.213.0/26 > > Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - > > rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - > > prohibit > > # DST-ADDRESS PREF-SRC GATEWAY DISTANCE > > 28 ADo x.x.213.0/26 198.172.214.66 110 > > > > Tower B: > > [admin@Tower-FP_Selvitz] /ip route> print where dst-address > > x.x.213.0/26 > > Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - > > rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - > > prohibit > > # DST-ADDRESS PREF-SRC GATEWAY DISTANCE > > > > > Is x.x.213.1 the OSPF router ID of your MikroTik at Tower B? Have > > > you made sure your all of your OSPF router IDs are all manually > > > specified and unique within your network? > > > > No, the router ID is x.x.214.66. And Yes, all the OSPF router IDs > > are all manually specified and unique. > > > > > Does the problem resolve itself after a bit? how long? or do you > > > have to take some action to clear it? > > > > Yes, the problem resolves itself after about 8 to 10 seconds, > > haven't seen it go much longer than that... > > > > Thanks again for any input you can and have provided :) Justin > > > > > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Scott > > Lambert > > Sent: Friday, March 07, 2014 5:15 PM > > To: Mikrotik discussions > > Subject: Re: [Mikrotik] OSPF Issue > > > > On Wed, Mar 05, 2014 at 08:05:16PM +0000, Justin Marshall wrote: > > > Hi, > > > > > > We are having an OSPF issue. At least i'm assuming it's an OSPF > > > issue because there are no static routes involved. > > > > > > We have our core router (imagestream) connected via Fiber to a > > > Mikrotik at Tower A, Which in turn is connected via 2 RB411AH's > > > with Atheros AR922X's to a Mikrotik at Tower B. Every 500-1000 > > > pings we are loosing pings to 1 of the IP addresses on a bridge > > > interface on the Mikrotik at Tower B. When this happens I see an > > > IP address that is bound to one of the interfaces on our > > > imagestream, show up on an MTR like so... > > > > > > > How is the wireless link from Tower A to Tower B configured? Are > > the RB411s bridged or do they participate in OSPF? How are the > > wireless AP and station interfaces configured? > > > > What is the OSPF interface configuration across the wireless link? > > > > Is the ImageStream up to date? > > > > Are you losing OSPF neighbor associations on the MikroTiks? Should > > show in the MikroTik log or you can just see how long the OSPF > > neighbor association has been installed. > > > > > Host Loss% Snt > > > Last Avg Best Wrst StDev > > > 1. 10.192.172.1 0.0% 3642 > > > 0.7 0.4 0.4 27.1 1.0 > > > 2. x.x.99.1 0.3% 3642 > > > 0.8 0.6 0.5 36.5 1.2 > > > 3. x.x.214.74 0.0% 3642 > > > 9.7 0.7 0.6 33.4 1.3 > > > x.x.36.209 > > > 4. x.x.214.66 0.0% 3642 > > > 8.0 10.3 0.7 75.1 9.1 > > > x.x.99.1 > > > 5. x.x.213.1 0.2% 3642 > > > 32.7 26.1 0.8 288.3 21.3 > > > x.x.36.209 > > > > > > > > > This is how it should look: > > > Host Loss% Snt > > > Last Avg Best Wrst StDev > > > 1. x.x.172.1 0.0% 4 > > > 0.8 0.9 0.5 1.4 0.4 > > > 2. x.x.99.1 0.0% 4 > > > 0.7 0.8 0.6 1.0 0.2 > > > 3. x.x.214.74 0.0% 4 > > > 1.2 1.1 0.7 1.7 0.4 > > > 4. x.x.214.66 0.0% 3 > > > 29.8 15.5 5.7 29.8 12.7 > > > 5. x.x.213.1 0.0% 3 > > > 15.3 14.4 13.8 15.3 0.8 > > > > > > > > > Both Mikrotik's are on 6.7, running OSPF. What we can't figure > > > out is why this x.x.36.209 keeps showing up in the route. While > > > this is happening, pings come back as: TTL exceeded. Also we > > > aren't loosing any pings to any other IP's on the Mikrotik in > > > question at Tower B, nor are we loosing pings to any other IP > > > addresses bound to that bridge interface. > > > > > > The IP that we are loosing pings to is a public IP vs the others > > > being private and not being in the /routing ospf networks. This > > > may or may not be relevant. There is also no NAT involved whatsoever. > > > > I may be interpreting your message incorrectly. Could you clarify > > if x.x.36.209 is an IP on an interface on the ImageStream? Or is it > > on a router at Tower C which may also be connected to Tower A via a > > wireless link? I suspect it is on the ImageStream. > > > > So, only the one subnet is falling out? At the time that you get > > looping traceroutes for 213.1, other subnets run clean? > > > > Are you only looping for the one IP in that subnet or for all hosts > > in the subnet? > > > > What does "show ip ospf route" look like from the ImageStream for > > anything in that /24? During the problem and while normal. > > > > What does "/ip route print where dst-address in x.x.213.0/24" look > > like on MikroTik A and B? > > > > Is x.x.213.1 the OSPF router ID of your MikroTik at Tower B? Have > > you made sure your all of your OSPF router IDs are all manually > > specified and unique within your network? > > > > Does the problem resolve itself after a bit? how long? or do you > > have to take some action to clear it? > > > > RouterOS 6.x has been better for us than 5.x for wierd OSPF issues. > > But it still seems a bit delicate. Especially if you have a > > misconfiguration somewhere or the wrong OSPF network type on a > > wireless bridge. > > -- Scott Lambert KC5MLE Unix SysAdmin [email protected] _______________________________________________ Mikrotik mailing list [email protected] http://mail.butchevans.com/mailman/listinfo/mikrotik Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS _______________________________________________ Mikrotik mailing list [email protected] http://mail.butchevans.com/mailman/listinfo/mikrotik Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
