August 1995 - NANOG - lists.nanog.org

Re: CIDR FAQ
by kwe＠6SigmaNets.com 18 Aug '95

18 Aug '95

At 5:04 AM 8/17/95, Yakov Rekhter wrote: > >In IPv6 there is a notion of "IPv4 compatible" addresses. These are >IPv6 addresses (128 bits) that have IPv4 address as their low order 32 >bits and the rest (96 bits) are zero. ... > >What you said is correct only if hosts use IPv6 addresses that >are not "IPv4 compatible". But transition with hosts that don't have >IPv4 compatible addresses is quite messy. Yakov; If you have an IPv6 capable host, why use "IPv4 compatible" addresses? Why not use an algorithmic translation that includes a provider prefix? It would seem to me that any IPv6 host should have the capability to algorithmically translate its IPv4 address, preferably dynamically. --Kent

2 1

Re: CIDR FAQ
by rrv＠uiuc.edu 18 Aug '95

18 Aug '95

At 4:57 PM 8/17/95, bmanning(a)ISI.EDU wrote: >Ah. here is the rub. When you ISP buddies come back, you should ask >them to return the origianal /22 for a /20. That way, the total size >of the routing system stays the same! If everyone did a clever job of allocation, and the ISP in question had grown quickly enough, you'd be able to expand the that /22 into a /20 at the very same address because the next 3 /22s would still be available. But I've already beaten that horse...

1 0

Re: CIDR FAQ
by Guy T Almes 18 Aug '95

18 Aug '95

At 08:22 AM 8/18/95 IST, Hank Nussbacher wrote: >On Thu, 17 Aug 1995 14:57:40 -0700 (PDT) Bill said: >>> >>> I assign /22s to ISPs. When they use them up I give them another /22. >>> Private companies that show a need for a /24 are assigned a /24. >>> >> >>Ah. here is the rub. When you ISP buddies come back, you should ask >>them to return the origianal /22 for a /20. That way, the total size >>of the routing system stays the same! > >Great idea. Know ANYONE who does that? The best I can do is give them a >/20 (in addition to the original /22) if their growth warrants it. > Hank, I like your idea. At first, you suggested giving the ISP a string of /22s. This could end up having a possibly large number of prefixes assigned to the same ISP. Then Bill suggested growth by requiring an exchange of an old /22 for a new /20. (And the next time requiring an exchange of the new /20 for a newer /18.) This could end up requiring this ISP's customers to renumber more frequently than the customers of its competitors, all due to a possibly quite reasonable judgement call by the registry. Your lastest idea provides an interesting compromise. If the ISP exhausts the initial /22, give them a new /20 and let them keep the /22. This does not achieve Bill's goal of a *constant* number of prefixes, but it does do the following: <> it keeps the growth in the ISP's prefixes logarithmic as a function of its customer base (not as good as constant, but better than linear), <> it allows the registry to grant as big or as little an initial prefix length without biasing the market in favor of one ISP over another, and <> it doesn't require as aggressive a rate of renumbering by customers as Bill's stricter notion. This is probably what many registries do now. The trouble with either your original (string of /22s) idea or Bills (strict exchange with constant number of prefixes) idea is that it puts too much weight on the registry's decision on how big a prefix to grant to a new ISP or an existing ISP in a rapidly growing market. If the registry grants too short a prefix, then address space is wasted. If the registry grants too long a prefix, then: [] under your original idea, routing table entries grow linearly, and [] under Bill's idea, the ISP's customers have to renumber too soon. By growing logarithmically, the registry doesn't have as much hanging on its initial prefix length decision, and the competitive field is more level. Two footnotes: ** as another person noted, you can optimize by leaving gaps around your initial prefix assignment and sometimes collapse blocks of a single ISP, and ** you could still require renumbering, though a little less aggressively than Bill does, by requiring the initial /22 to be returned, say, when the ISP's 4th prefix (a /16) is granted. At any rate, the 'renumbering cloud' hanging over the head of new customers should not depend on their choice of ISP. -- Guy

1 0

NANOG Meeting
by Pam Ciesla 18 Aug '95

18 Aug '95

OOPS! My mistake the NANOG Meeting is will be in PITTSBURG, PA. Pam

1 0

Re: CIDR FAQ
by Hank Nussbacher 18 Aug '95

18 Aug '95

On Thu, 17 Aug 1995 17:01:14 -0700 (MST) you said: >> On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said: >> >Simon Poole wrote: >> >> >> >> Yakov, if you have data that CIDR is -not- working for new allocations >> >> please present it here. >> >> >> >> Simon >> > >> >CIDR doesn't work as it should. We had to inject all of the more specifics >> >of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly. >> >> Can someone explain this a bit more? This sounds like a showstopper >> for CIDR. > >I have noticed some similar problems. MCI routing breaks if you provide them >with an identical path at multiple interconnects if it is advertised to them >at equal cost, hence they always like to see MEDs. In regards, a recent announcement (8/11): To All Maintainers of Data in the MCI Routing Registry, Until very recently, ANS's routers have been unable to support the MULTI_EXIT_DISCRIMINATOR (MED) attribute of BGP4. The result of this was that if an Autonomous System (AS) peered with ANS in more than one place, static configuration was required to specify which peer is the preferred exit point from ANS. This need for static configuration was satisfied with the 'advisory: AS690' attribute. ANS has now implemented MEDs in their routers and has already tested it with a few ASs. They have told us that they are willing to turn on MEDs with AS3561 on Tuesday 15 August. This greatly simplifies the 'advisory' attribute needed in the registry. For example, if your current 'advisory' attribute looks like: advisory: AS690 1:3561(11) 2:3561(144) 3:3561(27) 4:3561(147) 5:3561(218) it can now be reduced to: advisory: AS690 1:3561 We do not know which other providers, if any, have arranged to send MEDs to ANS. So, if some of the networks you maintain in the RR are multi-homed to provider(s) which also peer with ANS in more than one place, you would need to talk directly to the other provider(s) to see if the 'advisory' string should change. An example of an 'advisory' attribute for a network that is homed to both MCI and Alternet, with primary service through MCI, and assuming that ANS has not enabled MEDs with AS701, is: advisory: AS690 1:3561 2:701(147) 3:701(144) The RR Users Guide will be updated with this information; it will not contain any more information than this e-mail message. The most recent version of the Users Guide is always available from "ftp://ftp.mci.net/pub/rr/docs/mci-user.txt" (a PostScript version is also available with an extension of '.ps'). MCI is volunteering to change 'advisory' attributes in existing route objects in the MCI RR to the new syntax; ASs other than 3561 *will* be preserved, so the semantic of the 'advisory' will *not* change. We will make this change on Friday morning 11 August. If you have any questions or concerns about this, please tell us before Friday morning by sending a message to 'rr-types(a)mci.net'. Starting Friday morning 11 August, please make sure that all new and updated route objects contain the new 'advisory' string. Thank You. /jws >Dave Hank

1 0

Re: CIDR FAQ
by Sean Doran 18 Aug '95

18 Aug '95

>MCI routing breaks if you provide them with an identical >path at multiple interconnects I find this very strange, since MCI does this properly at multiple interconnects with a number of providers. Please -- if there are problems let's try to fix them in the normal fashion, rather than offer generalizations on mailing lists in what is likely to be easily misunderstood as "things don't work in general" rather than "there are specific problems which creep up from time to time". Sean.

2 1

Re: CIDR FAQ
by Hank Nussbacher 18 Aug '95

18 Aug '95

On Wed, 16 Aug 95 13:09:52 PDT you said: >Paul, > >> New allocations are (as of 1466bis) being done through providers, on CIDRized >> lines. Whether IPv4 or IPv6, new allocations are not going to badly impact >> the core routing table size. > >Does that mean that all the internet registries no longer allocate >/24 (or longer) prefixes that have nothing to do with the actual >Internet topology (these prefixes aka "portable addresses") ? Perhaps >folks from various Internet registries would be able to answer this >question. I assign /22s to ISPs. When they use them up I give them another /22. Private companies that show a need for a /24 are assigned a /24. >Yakov. Hank

4 3

Re: CIDR FAQ
by Sean Doran 18 Aug '95

18 Aug '95

This is something that should have been sent to engineer(a)sprint.net. Please re-send, and when it is convenient you and one of our engineering staff (or even me, if you like) can sit down and have you withdraw your more specifics and try to watch what's going on. BTW, if you have a ticket number from the INSC, management around here would love to know what it is. Sean.

1 0

Re: CIDR FAQ
by Sean Doran 18 Aug '95

18 Aug '95

I am having trouble understanding the assertion still, and am wondering what the problem is; I'm going to dive into all sorts of archived mail looking for clues about 194.45/16, but in the mean time here are some observations: Network Next Hop Metric LocPrf Weight Path *> 194.45.0.0/16 192.41.177.240 3 90 0 1800 1755 517 ? interesting prefixes *> 194.45.40.161/32 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.120.0/26 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.120.64/26 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.120.128/26 192.41.177.240 3 90 0 1800 1755 517 ? all prefixes. Note that if you offered ONLY 194.45/16, rather than that AND all the more specifics, things would work fine. Have you done this? What was the problem? Why are you asserting that the problem is with SprintLink? Sean. - -- Network Next Hop Metric LocPrf Weight Path *> 194.45.0.0 192.41.177.245 1 90 0 174 i *> 194.45.0.0/16 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.1.0 192.41.177.245 1 90 0 174 i *> 194.45.2.0 192.41.177.245 1 90 0 174 i *> 194.45.3.0 192.41.177.245 1 90 0 174 i *> 194.45.4.0 192.41.177.245 1 90 0 174 i *> 194.45.5.0 192.41.177.245 1 90 0 174 i *> 194.45.6.0 192.41.177.245 1 90 0 174 i *> 194.45.7.0 192.41.177.245 1 90 0 174 i *> 194.45.8.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.9.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.10.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.11.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.12.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.13.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.14.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.15.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.16.0 192.41.177.181 1 90 0 3561 1220 ? * 192.41.177.181 0 90 0 1800 3561 1220 ? * i 198.32.130.227 1 90 0 3561 1220 ? * i 144.228.103.1 1 90 0 3561 1220 ? * i 192.157.69.11 1 90 0 3561 1220 ? *> 194.45.17.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.18.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.19.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.20.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.21.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.22.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.23.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.24.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.25.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.26.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.27.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.29.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.30.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.31.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.32.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.33.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.35.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.36.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.37.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.38.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.39.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.40.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.40.161/32 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.41.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.42.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.43.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.44.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.45.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.46.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.47.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.48.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.49.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.56.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.58.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.59.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.69.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.70.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.71.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.72.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.73.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.74.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.75.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.76.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.77.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.78.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.79.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.80.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.81.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.82.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.83.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.84.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.85.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.86.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.87.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.92.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.93.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.94.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.95.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.96.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.97.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.98.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.99.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.100.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.101.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.102.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.103.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.104.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.105.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.106.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.107.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.108.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.109.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.110.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.111.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.112.0/21 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.120.0/26 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.120.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.120.64/26 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.120.128/26 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.121.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.122.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.123.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.124.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.126.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.127.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.128.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.129.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.130.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.131.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.132.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.134.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.135.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.136.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.137.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.139.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.140.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.141.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.144.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.145.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.146.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.147.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.148.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.149.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.150.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.151.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.152.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.153.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.154.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.156.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.157.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.158.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.159.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.160.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.161.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.162.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.163.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.164.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.165.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.166.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.167.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.168.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.169.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.170.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.171.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.172.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.173.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.174.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.175.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.176.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.178.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.179.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.180.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.181.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.183.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.184.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.187.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.188.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.189.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.190.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.191.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.192.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.193.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.194.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.196.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.197.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.199.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.200.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.201.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.202.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.203.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.208.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.209.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.210.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.211.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.212.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.213.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.214.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.215.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.216.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.218.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.219.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.220.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.221.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.223.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.224.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.225.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.226.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.227.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.228.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.229.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.230.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.231.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.232.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.233.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.234.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.235.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.236.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.236.64/28 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.236.80/28 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.237.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.238.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.239.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.240.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.241.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.242.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.243.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.244.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.245.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.246.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.247.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.248.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.249.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.250.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.251.0 192.41.177.240 3 90 0 1800 1755 517 ? *> 194.45.255.0 192.41.177.240 3 90 0 1800 1755 517 ?

1 0

Re: CIDR FAQ
by Sean Doran 18 Aug '95

18 Aug '95

| >CIDR doesn't work as it should. We had to inject all of the more specifics | >of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly. | | Can someone explain this a bit more? This sounds like a showstopper | for CIDR. Can someone explain it at all? This is the first *I*'ve heard of this. Sean. (taking a look now though)

1 0