Hi, I have recently come across the need to test BGP peering with a number of people and have found that it is occasionally useful to establish a peer and then send a test route. There were a number of options here: 1- Use a route that I should correctly source. 2- Send the loopback address 3- Use an RFC 1597 address 4- Use the TestNetwork address Due to certain vendors/ISPs desire to (correctly) squash RFC 1597 advertisments and my inability to verify routing correctness if I propogated via third-party my internal routes, I chose to use the TestNetwork. What is the TestNetwork? zed 30% whois 192.0.2.0 [No name] (NET-TEST) Netname: AMEX Netnumber: 192.0.2.0 Coordinator: Reynolds, Joyce K. (JKR1) JKRey@ISI.EDU (310) 822-1511 Record last updated on 24-Oct-94. This was a number allocated prior to RFC 1597 to assist people in correctly documenting how to configure IP in their documentation. (a fix for the infamous defaults SUN had in the config scripts for so many years) It's usefullness in testing devolves from its not being included in the RFC 1597 ban on forwarding. It seems to me that we should encourage any/all NSP/ISP types to block the following networks: 127.0.0/8 10.0.0/8 172.16.0/20 192.168.0/16 --bill
Date Sent: 30-JAN-1995 15:05:48 With respect to Bill Manning,
It seems to me that we should encourage any/all NSP/ISP types to block the following networks:
127.0.0/8 10.0.0/8 172.16.0/20 192.168.0/16
--bill
Perhaps it's time we admitted the arpanet isn't just dead... It's long dead. Instead of blocking 10.0.0/8, break it up into Bs and Cs! 10.128.0/9 Bs 10.0/9 Cs (10.0.1 through 10.127.255) Ehud -- Ehud Gavron (EG76) gavron@Hearts.ACES.COM
Perhaps it's time we admitted the arpanet isn't just dead... It's long dead. Instead of blocking 10.0.0/8, break it up into Bs and Cs! 10.128.0/9 Bs 10.0/9 Cs (10.0.1 through 10.127.255)
Well.... That might be a good idea except 10.0.0/8 is already consumed via RFC 1597. Won't work to split it into "B/C" nets. Of course classfull nets are a thing of the past and what we deal with now are CIDR prefixes and Masks. --bill
Perhaps it's time we admitted the arpanet isn't just dead... It's long dead. Instead of blocking 10.0.0/8, break it up into Bs and Cs! 10.128.0/9 Bs 10.0/9 Cs (10.0.1 through 10.127.255)
I was not clear. We need to have a policy of blocking along these lines: 10.0.0/8 down to 10.0.0.1/24 For the truly paranoid... (catches those hard to get host routes !!) -- --bill
Let me play Devil's Advocate here for a moment... Why do you need a -policy-? Why do you need anything other than what 1597 already says? 1597 was VERY careful to be general and leave implementation of policy up to the users. The RA, NAPs, IXs, and others do not need to concern themselves with how or when these suggestions are implemented. The thing to understand is that the 1597 network addresses are not unique throughout the entire Internet. There use and administration is done on a local basis, but it behoves us to not get parochial about the term local. Actually, there's a really interesting point here that's about to give you a big whopping ulcer. I hate to do this to you but... You, as RA, need to support your customer's routing policies. If, for instance, someone at Sprint and someone at MCI get together and decide jointly that they want to share network 10 "privately" for their BGP loopbacks or their porno FTP servers, they could form the Sprint/MCI net-10 consortium and you'd need to carry an advertisement for net 10 in your RA database so the two sites could exchange routes. Here's where the fun comes in... now say Alternet and PSI get together and want to share network 10 "privately" for their BGP loopbacks or their porno FTP sites and form the Alternet/PSI net-10 consortium... :-) The long and the short of it is that as RA, not only do you need to not block 1597 advertisements in your database, you need to correctly implement virtual private networking for 1597 advertisements. Remember Bill, that the RA needs to not get bogged down by parochial definitions of "local." I bet now you're wishing you hadn't brought this up and got me thinking... Sorry...I'll buy you a drink in Danvers to make it up to you. Best regards, Paul p.s. the B block of 1597 has 12 bits of prefix-signifcance, not 20 (32-20=12...)
Let me play Devil's Advocate here for a moment...
What no horns? No cloven hooves? No pointy tail?
Why do you need a -policy-?
Easy, My policy is to not propogate any customer routes unless they are properly registered in the routing registry. But how do I check that I have a "working" BGP peer up unless I can actually exchange a route? Here the testroute comes in real handy.
Why do you need anything other than what 1597 already says?
See above. And besides, 192.0.2.0 is not part of RFC 1597.
1597 was VERY careful to be general and leave implementation of policy up to the users. The RA, NAPs, IXs, and others do not need to concern themselves with how or when these suggestions are implemented.
Yup.
The thing to understand is that the 1597 network addresses are not unique throughout the entire Internet. There use and administration is done on a local basis, but it behoves us to not get parochial about the term local.
Yup
Actually, there's a really interesting point here that's about to give you a big whopping ulcer. I hate to do this to you but...
Not a problem
You, as RA, need to support your customer's routing policies.
Darn! I was in it for the praise and adoration
If, for instance, someone at Sprint and someone at MCI get together and decide jointly that they want to share network 10 "privately" for their BGP loopbacks or their porno FTP servers, they could form the Sprint/MCI net-10 consortium and you'd need to carry an advertisement for net 10 in your RA database so the two sites could exchange routes.
Here's where the fun comes in... now say Alternet and PSI get together and want to share network 10 "privately" for their BGP loopbacks or their porno FTP sites and form the Alternet/PSI net-10 consortium...
You forgot the guys who register their net10 with a policy of "don't route per RFC 1597. I don't think this is a problem in the RADB. We can take this offline to reduce my public exposure.
The long and the short of it is that as RA, not only do you need to not block 1597 advertisements in your database, you need to correctly implement virtual private networking for 1597 advertisements.
Yup again.
Remember Bill, that the RA needs to not get bogged down by parochial definitions of "local."
Only when it pertains directly to the RA maintained route servers.
I bet now you're wishing you hadn't brought this up and got me thinking... Sorry...I'll buy you a drink in Danvers to make it up to you.
Nope, this is really good. See you in Danvers... :) --bill
Paul Traina (pst@cisco.com) on January 30:
If, for instance, someone at Sprint and someone at MCI get together and decide jointly that they want to share network 10 "privately" for their BGP loopbacks or their porno FTP servers, they could form the Sprint/MCI net-10 consortium and you'd need to carry an advertisement for net 10 in your RA database so the two sites could exchange routes.
Here's where the fun comes in... now say Alternet and PSI get together and want to share network 10 "privately" for their BGP loopbacks or their porno FTP sites and form the Alternet/PSI net-10 consortium...
Interesting. Actually, RA route servers can handle this situation as we speak. RA RSs maintain a view per peer. In the view for Alternet, one would install the route from PSI and would not install the routes from Sprint and MCI. (In the view for sprint, install MCI's route and do not install Alternet's and PSI's, etc.) Of course, we need policies to do this. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute Voice: (310) 822-1511 University of Southern California
participants (4)
-
bmanning＠ISI.EDU -
cengiz＠ISI.EDU -
Ehud Gavron -
Paul Traina