Home page logo
/

nanog logo nanog mailing list archives

Re: Filtering on RFC1918 cruft
From: randy () psg com (Randy Bush)
Date: Sat, 18 Jan 97 05:02 PST

deny   ip 198.32.146.0 0.0.0.255 255.255.255.0 0.0.0.255 (543 matches)
deny   ip 198.32.176.0 0.0.0.255 255.255.255.0 0.0.0.255 (10 matches)
deny   ip 192.157.69.0 0.0.0.255 255.255.255.0 0.0.0.255 (96 matches)
deny   ip 198.32.128.0 0.0.0.255 255.255.255.0 0.0.0.255 (335 matches)

  ya, ya, teh last four aren't rfc1918 but i filter them anyway (nap 
dmz's) :)  lot's of people announcing them.  the first two are the 
only rfc1918 nets i see announced on our nap routers.

I used to wonder about announcing them too.  I came up with reasons
on both sides, and in the end decided it didn't matter for real
traffic.  Real traffic isn't sourced or destined for the exchange
point networks.  On the other hand, the users most likely to send
traffic to or from an exchange point network are also the network
engineers configuring the announcements.  Announcing the networks
make network debugging (and other network hacking) a lot easier. 

Same conclusion.  So we carry public mesh routes internally, but do not
(intentionally) announce them.

The point could be made that, by not announcing them to peers, we are not
helping our peers when they are trying to get to a box which has its FDDI
up but its WAN down.

On the other hand, if everybody announces, that's a lot of rubbish.  So
everybody whose interface MOD X, for some smallish value of X, is zero
announces?

Bill, it would be cool if you SWIPped the public /24s.  It would make life
easier for curious folk (some of us don't know MAE-LA's mesh offhand), and
Kim ain't gonna give you any more unless you do <g>.

randy
- - - - - - - - - - - - - - - - -


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault