> 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.
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 198.172.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
>> 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
> 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".
> 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.
Thanks,
Justin
-----Original Message-----
From: [email protected]
[mailto:[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]
> [mailto:[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 _______________________________________________
> Mikrotik mailing list
> [email protected]
> http://mail.butchevans.com/mailman/listinfo/mikrotik
>
> Visit http://blog.butchevans.com/ for tutorials related to Mikrotik
> RouterOS
--
Scott Lambert KC5MLE Unix SysAdmin
[email protected]
How to be a "computer expert," http://www.xkcd.com/627/
_______________________________________________
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
