[c-nsp] iBGP not propogating route to 0/8

[Justin Shore]

The default-info originate solution makes me nervous without a lab to 
test this in.  Forcing the advertisement with the network statement 
though works like a champ.  I hadn't even considered that this was being 
caused by Cisco's martian handling.  But as David Sinn pointed out, 
there are more prefixes than just 0/8 that are being suppressed.  I'll 
use the network command to force the advertisement for those networks 
too.  I need to put up a RTBH HOWTO on my website I think.

Thanks.  TGIF!
  Justin



Tassos Chatzithomaoglou wrote:
> I think it has to do with the default route "confusion"...
> 
> 1) You can use "default-information originate" under the bgp process and 
> trick bgp that this is the default route (i guess only the network part 
> is checked). The network is shown as "0.0.0.0/8" which means that the 
> router doesn't consider /8 to be the default length of 0.0.0.0, like in 
> 3.0.0.0.
> 
> R1>sh ip bgp
> BGP table version is 20, local router ID is 1.1.1.1
> Status codes: s suppressed, d damped, h history, * valid, > best, i - 
> internal,
>               r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
> 
>    Network          Next Hop            Metric LocPrf Weight Path
> *>i0.0.0.0/8        1.1.1.2                  0    500      0 i
> *>i3.0.0.0          1.1.1.2                  0    500      0 i
> 
> 
> 2) You can use "network 0.0.0.0 mask 255.0.0.0 route-map static-to-bgp" 
> under bgp and force its advertisement.
> 
> Method 1 requires redistribution of the route, method 2 requires route 
> to be present in IGP/static.
> In your case, you have both ;)
> 
> -- 
> Tassos
> 
> 
> David Sinn wrote on 16/5/2008 7:06 μμ:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On May 15, 2008, at 2:31 PM, Justin Shore wrote:
>>
>>> I can't think of any reason why this prefix wouldn't be advertised.   
>>> Any
>>> ideas?  I noticed it today because I have customers trying to hit 0/8
>>> IPs (0.4.24.200 for example) that my egress ACLs are catching.
>>
>> This is due to how Cisco treats martian networks per their  
>> interpretation (or real meaning) of RFC 1812.  Since the following 
>> are  martians, to cover the "Should not" route part of 5.3.7, they 
>> won't  install them in the route table.
>>
>> 0.0.0.0/8
>> 127.0.0.0/8
>> 128.0.0.0/16
>> 181.255.0.0/16
>> 192.0.0.0/24
>> 233.255.255.0/24
>> 240.0.0.0/4
>>
>> I've only personally tested 240.0.0.0/4 and it will not install in 
>> the  route table.  I've also not tried to figure out what more or 
>> less  specific routes you could try and install to cover these blocks.
>>
>> David
>>
>>
>>> Thanks
>>>  Justin
>>>
>>>
>>> _______________________________________________
>>> 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/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (Darwin)
>>
>> iEYEARECAAYFAkgtsPYACgkQLa9jIE3ZamNprgCfUAoV0GXj0Ob1HNg8pyifER1a
>> 6T8AoIWpvrB87i+VjRmp3avNPNRTJAV8
>> =1Klc
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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/
>>
>