[c-nsp] Incarnations of 0.0.0.0
William McCall
william.mccall at gmail.com
Fri Jul 23 09:28:27 EDT 2010
This behavior looks like a bug documented here:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsj11038&from=summary
As far as it operating, well... As you said, leave well enough alone.
--WM
On Fri, Jul 23, 2010 at 8:07 AM, Sascha Pollok <nsp-list at pollok.net> wrote:
> Hello William,
>
>> 2) Routing to 0.0.0.0 does not do what you may think it does. That is
>> because CEF maintains a receive entry for 0.0.0.0/32
>>
>> ex:
>> ip route 0.0.0.0 0.0.0.0 172.16.1.1
>> ip route 10.0.0.0 255.255.255.0 0.0.0.0
>>
>> This will cause all traffic except the 10.0.0.0/24 prefix to be routed
>> to 172.16.1.1. When it comes time for 10.0.0.0/24 to be routed, you
>> just pointed the traffic back at the router. This is because of the
>> receive entry in the CEF table. This behavior originates from RFC5735
>> (formerly RFC3330) which makes 0.0.0.0/32 represent "[...] this host
>> on this network."[1]
>
> It does not seem like Cisco is always treating it like this.
> I just tried this on an SXI3 running box that gives an "invalid next hop"
> so far so good.
>
> However, a Cisco 2811 running 12.4(23) where I configured something like
> this many years ago is still running and does indeed route 10.0.0.0
> (or actually a /32 in my case) recursively to the active 0.0.0.0 route.
> Still the 0.0.0.0/32 is in the CEF table as receive. No explanation
> so far. And I'd rather not look for one.
>
> Cheers
> Sascha
>
>
More information about the cisco-nsp
mailing list