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@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@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/