[c-nsp] Incarnations of 0.0.0.0

[William McCall]

I felt inclined to share this because I have heard more than a few
misconceptions regarding 0.0.0.0/32 and 0.0.0.0/0.

1) The default route is always 0.0.0.0/0. In the case of prefix lists,
adding any sort of accept length will cause prefixes of the configured
length to be permitted. (everyone has probably already said this by
now, 6 or 7 times). Prefix lists will match exact prefixes unless you
add a length statement to it.

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]

Why was this interesting enough to share? It came up as a question
once to me and seemed like a bad idea to try to recurse the default
(even though I didn't realize at the time that the 0.0.0.0/32 entry
was in the CEF table), but it should help with the understanding of
the significance of 0.0.0.0 in its 2 most common forms.

Hope this is useful for someone.

-- 
William McCall

[1] http://tools.ietf.org/html/rfc5735

On Fri, Jul 23, 2010 at 5:45 AM, roy <bandwidth.user at gmail.com> wrote:
> On Friday, 23 July, 2010 06:27 PM, Phil Mayers wrote:
>
>> ip prefix-list annonce-C1 seq 100 permit 0.0.0.0/0
>
> Shouldn't it be '... permit 0.0.0.0/32' ? IMHO, 0/0 is "all".
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>