<div dir="ltr">Hi,<div><br></div><div>Thank you all for your help. Even getting warnings about only 50 to 100 routes in router logs, we tought that wouldn't cause this behavior since technically we still had free routes.</div><div><br></div><div>We ended up filterning /24 routes and adding a default route to reduce the full routing table and everything is fine now. This way we will be able to use this equipment before being able to migrate to a 1M routes equipment.</div><div><br></div><div>If any of you in the future has this issue, I recommend the following:</div><div>Issue an "show ip route ... detail" and you'll be able to see the route, however it will not be installed in CAM partition if in field "Cam:Index" you  see "INVALID CAM".</div><div><br></div><div>Regards,</div><div>José</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 October 2014 16:46, Franz Georg Köhler <span dir="ltr"><<a href="mailto:lists@openunix.de" target="_blank">lists@openunix.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
<br>
this could be bogon filtering.<br>
<br>
You can try to disable it and afterwards reinstall thge route manually:<br>
<br>
no ip martian filtering-on<br>
<br>
<br>
Best regards,<br>
<br>
Franz Georg Köhler<br>
<br>
Am 01.10.14 um 21:19 schrieb José Santos:<br>
<div class="HOEnZb"><div class="h5">> Hi,<br>
><br>
> We are new to Brocade and we are experiencing an unexpected behavihor:<br>
><br>
> We have an MLX 4 with 5.6b, receiving a full routing table, including<br>
> default route from our ISP.<br>
><br>
> We are receiving multiple routes from our internal devices like<br>
> <a href="http://192.168.0.0/25" target="_blank">192.168.0.0/25</a>, <a href="http://192.168.0.128/25" target="_blank">192.168.0.128/25</a> and aggregating with aggregate-address<br>
> <a href="http://192.168.0.0/24" target="_blank">192.168.0.0/24</a> summary-only.<br>
><br>
> We have this same setup with other networks that work perfectly, however<br>
> before had this same issue and worked intermitently. This one give us<br>
> always TTL exceeded with ping test from outside and in a traceroute we can<br>
> see it looping towards our ISP. From the router we are able to ping the<br>
> IPs.<br>
><br>
> We tried to advertise the /24 route from another device with iBGP, however<br>
> it's ignored and the traffic is still is routed to our ISP.<br>
><br>
> Even after configuring an static route to an internal device, it's ignored<br>
> as well and the <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> route is used to route traffic.<br>
><br>
> If we poing the default route to null0 we lose the TTL exceeded messages<br>
> but we lose connectivity as well. We pointed a static to the device where<br>
> our /25s and /24 is being advertised right now (192.168.0.26) and<br>
> everything started working...<br>
><br>
> We thought about no free CAM space to install routes, however we don't have<br>
> any warning/error message in logs and we have 50 free routes.<br>
><br>
> May this this be related with classless / classful routing implementations?<br>
> We find very weird to have a more specific route ignored to a<br>
> default-route, even when a "show ip route" shows the more specific one<br>
> choosen. We never had this behavior before.<br>
><br>
> Thank you in advance for your help!<br>
><br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a></div></div></blockquote></div><br></div>