i am told that aads seems to be planning to renumber, seemingly as there is some service charge for the address space they do not wish to pay. please correct/confirm. should this be true and a real issue, o will folk be happy renumbering at larger exchanges? o does anyone see why the exchange address space needs to be globally routable? randy
I don't know about the specifics of ADS, but this question:
o does anyone see why the exchange address space needs to be globally routable?
is valid in any case. Global announcement of IX address space has caused me trouble in the past when "remote" maintenance access depends on it; inconsistent policy with respect to IX prefix announcement caused the path to the IX prefix to be wildly lossy, while announcement of a non-IX prefix was much better. We addressed that by making sure that all equipment was maintained and monitored remotely using non-IX address space addresses so that there was slightly better control over the announcement (and over packet-level access to addresses on which monitoring was permitted). That said, I think it's still important to have global reachability for exchange point addresses so that problems like congestion can be remotely diagnosed. Sometimes the difference in packet loss between a provider's IX address and some address one hop beyond it is a valuable clue in tracking down problems; without global routing of exchange point addresses, such diagnosis would only be possible to those who distribute the IX prefix within their IGP. Stephen
At 3:27 PM -0800 1/24/99, Randy Bush wrote:
i am told that aads seems to be planning to renumber, seemingly as there is some service charge for the address space they do not wish to pay. please correct/confirm.
should this be true and a real issue,
o will folk be happy renumbering at larger exchanges?
o does anyone see why the exchange address space needs to be globally routable?
Traceroute.
o does anyone see why the exchange address space needs to be globally routable? Traceroute.
as the fabric is used for peering under bi-lats, if we each announce the mesh to our customers and not to our peers, then i believe you will have your tracroutes and yet the prefix does not have to be globally routable, e.g. could be 209.666.42/24. randy
On Sun, Jan 24, 1999 at 09:35:13PM -0800, Randy Bush wrote:
o does anyone see why the exchange address space needs to be globally routable? Traceroute.
as the fabric is used for peering under bi-lats, if we each announce the mesh to our customers and not to our peers, then i believe you will have your tracroutes and yet the prefix does not have to be globally routable, e.g. could be 209.666.42/24.
randy
Holdon, i don't even see the need for that; if you traceroute out, the packets will cross the exchange irregardless of whether you're announcing it to your customers, and a message of TTL exceeded will be generated from the exchange's address.. The important question is, should they be globally UNIQUE for troubleshooting purposes? I think so. Mike -- Michael P. Lyle Security Architect Exodus Communications
Holdon, i don't even see the need for that; if you traceroute out, the packets will cross the exchange irregardless of whether you're announcing it to your customers, and a message of TTL exceeded will be generated from the exchange's address.. The important question is, should they be globally UNIQUE for troubleshooting purposes? I think so.
When not advertising exchange point address space, the conditions with respect to traceroute are much the same as that of RFC 1918 address space; you can traceroute *through* it and get reports of TTL exceeded from source addresses that you cannot reach as a destination. No big deal to some, major diagnosis headache to others. I'd argue in favor of reducing diagnosis headaches ... and I *hate* it when I can't traceroute to points in the interior of providers who use RFC 1918 addresses internally. :-) If the shared L2 media of an exchange point fabric did *not* have a shared L3 address prefix as Alan Hannan noted earlier, where (as Alan said) one party of a bi-lat coughed up a /30, then the reachability of said prefix could be left to the parties to the bi-lat. Modern equipment should be able to handle the quantity of secondary/alias addresses needed to deal with number of /30s required to uniquely number each bi-lat, no? Stephen
Modern equipment should be able to handle the quantity of secondary/alias addresses needed to deal with number of /30s required to uniquely number each bi-lat, no?
do i want to find out if ciscos and junipers can handle a hundred+ secondary addresses? and do we want to maintain such configurations?? randy
Modern equipment should be able to handle the quantity of secondary/alias addresses needed to deal with number of /30s required to uniquely number each bi-lat, no?
do i want to find out if ciscos and junipers can handle a hundred+ secondary addresses? and do we want to maintain such configurations??
it is odd to see you ask questions about yourself. it is well known that modern routers can easily maintain logical interfaces in excess of 300. this should not be an issue. what you want to do is up to you, what one can do is of interesting discussion on this mailing list. -alan
Randy et al.,
should this be true and a real issue,
o will folk be happy renumbering at larger exchanges?
There have been some recent presentations by LINX over their renumbering exercise. I guess there were about 60 members and perhaps 80-90 routers at the time, but the presentation would be more accurate. Essentially it was smooth. The main problems (from my POV) were caused by one minor Cisco bizarreness on BGP router ID, by people reading /23 as /24, and by people not disabling gacky things such as proxy ARP and other spawn-of-the-devil type things which AADS, not been MAC based, will not suffer from.
o does anyone see why the exchange address space needs to be globally routable?
Aids debugging (i.e. traceroutes will always give reverse DNS, and every hop should be reachable somehow; possible to IP source-route for traceroute -g to the address etc.). I thought the advantages and disadvantages of reachability of IXP DMZ have been pretty extensively covered, and the consensus should be: 1. IXPs should set some policy on who should advertise their DMZ, and other people should not. 2. ISPs should be wary of accepting IXP DMZ advertisements, or more specifics thereof. An obvious way to do this is (for Cisco speakers) to set next-hop-self in their IBGP mesh and not introduce the DMZ into either the IGP or into iBGP, instead carrying the exit address as the loopback interface of the connected router throughout. More to the point, if you take it as a necessity that people configure routers on IXPs sensibly for all sorts of other reasons, does anyone see why the IXP address space should *not* be globally routable? ATM NAPS such as AADS are better protected against the abuses such as GRE to IXP connected routers (i.e. the PVC must preexist) than most common-access exchanges. My take on the LINX exercise was merely that those who suffered in some way did so *in general* due to their own cluelessness. Everything that happened *due solely to renumbering* which caused anyone else pain would have have been discovered at some point anyhow. Your router load may vary, of course. -- Alex Bligh GX Networks (formerly Xara Networks)
i am told that aads seems to be planning to renumber, seemingly as there is some service charge for the address space they do not wish to pay. please correct/confirm.
should this be true and a real issue,
i have received the attached email. as it is not marked confidential I have attached it here for review.
o will folk be happy renumbering at larger exchanges?
quite.
o does anyone see why the exchange address space needs to be globally routable?
no. in fact, i believe nsps should use bilaterally provided unique address space at public exchange points, to model private interconnections, though the public fabric is shred. ie - instead of using 198.32.136.x/24, a network should use a.b.c.d/30, where a.b.c.d/30 comes out of one, or the other, peer's address space. the maes and naps are no longer the center of the internet, and therefore mae/nap reachability is of little consequence. -alan
- Plan is to move the router servers to a totally new subnet.
Have to be really careful when assigning IP address to the Route Servers if they are still connected to the ATM via a cisco router. The RSs, without its own ATM interfaces, have been connected via a cisco to the ATM NAP and a proxy-arp-kludge has been used to make it work, which involves clever ip address assignment. --Jessica
Hi Jessica! I think we have this covered... -abha ;) On Mon, 25 Jan 1999, Jessica Yu wrote:
- Plan is to move the router servers to a totally new subnet.
Have to be really careful when assigning IP address to the Route Servers if they are still connected to the ATM via a cisco router. The RSs, without its own ATM interfaces, have been connected via a cisco to the ATM NAP and a proxy-arp-kludge has been used to make it work, which involves clever ip address assignment.
--Jessica
__________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja@merit.edu Merit Network, Inc. 734.764.0294
Unless someone knows differently, the renumbering at AADS been called off. (Enough people signed up to pay for the space, independent of AADS operations) At least, this is true according to Bill Manning. (As if *he* knows anything ;) . Ciaou .
Date: Mon, 25 Jan 1999 11:55:56 -0500 From: Richard Irving <rirving@onecall.net> Sender: owner-nanog@merit.edu
Unless someone knows differently, the renumbering at AADS been called off. (Enough people signed up to pay for the space, independent of AADS operations)
At least, this is true according to Bill Manning.
(As if *he* knows anything ;)
No. Bill only said that he had agreements to fund support of the existing numbers from enough people at AADS that he would not turn off name service on 1/15. The message from Kevin Peterson at AADS came out significantly after this transpired and the NANOG BOF on AADS renumbering is still very much on the agenda. I imagine that the renumbering to some Ameritech owned address space will take place within the next month. and that it will continue to be a single prefix and not a mass of /30s. The message from Kevin (Peterson, not me) stated that the last octet would remain the same as it is now, so it would simply be a matter of adding a single secondary address to each router interface and a new set of addresses to the ATM address map. (This assumes Cisco routers. I have no experience with others.) Until I hear otherwise from AADS, I assume the renumbering is on. We should all know more about a week from tonight after the BOF in Denver. It does seem odd that several organizations that should have heard about this direct from AADS seem unaware. Maybe it just has not trickled up to Randy from whoever receives these things from AADS at Verio. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Unless someone knows differently, the renumbering at AADS been called off. (Enough people signed up to pay for the space, independent of AADS operations)
At least, this is true according to Bill Manning.
(As if *he* knows anything ;)
. Ciaou .
Indeed. The view from here is that one of the participants at the AADS exchange agreed to sign the acceptable use paperwork, which was the gist of the problem I had with the current situation. That taken care of, the prefix 198.32.130.0/24 is good for use at the AADS exchange. This does not preclude AADS from implementing a renumbering plan for its clients. It is then up to the clients to determine which/ how many prefixes they intend to use. Also note. There is -NOT- payment for address space. There are costs associated with doing delegation and those costs have to be recovered somewhere.
participants (12)
-
Abha Ahuja -
Alan Hannan -
Alex Bligh -
bmanning＠vacation.karoshi.com -
Howard C. Berkowitz -
Jessica Yu -
Kevin Oberman -
Michael P. Lyle -
Randy Bush -
Randy Bush -
Richard Irving -
Stephen Stuart