At 11:58 PM 2/18/00 -0800, Steve Rubin wrote:

On Sat, Feb 19, 2000 at 12:37:32AM -0700, John M. Brown wrote:

...

so I decided to poke around some more...

I really can't see how the argument of ""Route / AS-Path" table bloat is going to break things if ARIN starts doing mico-allocations for providers that need to multi-home, but don't need tons of space.

I really like the /30's, /32's...

[routes deleted]

I take it you get transit from the network formerly known as iMCI as from

what

I can tell, it looks like they don't send these routes to peers. I'd be willing to bet this is a knob they can turn off for you if you don't want to see the routes... Or you can just install some sanity filtering on your inbound peers/transit providers to nuke the /25 and up's.

I have to agree with Steve on the prefixes longer than /24. C&W is probably just leaking internal routes to customers, which you can probably filter without any loss of connectivity. (There is a nice sanity filter on the merit.edu site. :) But John has a point about the /24s in 63.0.0.0/8 (and /20s and ....). You might as well add the entirety of AS7046 as well. (I told Jeff & Vijay and others about this over a *year* ago, but UU still announces hundreds of completely useless routes - which are not even aggregated amongst themselves.) There are more examples, I am sure everyone knows some. Essentially, you are right John, the table is full of litter and chaff. Besides, if all we do is give multi-homed providers "micro allocations", say in the range of /22s or so, we will not even grow the table - those routes already exist in the table under the provider's AS. In fact, we might reduce the table because some of these providers have multiple /24s which cannot be aggregated.

Then again, like Patrick, I have no enable, so what do I know? :-)

Ohhh, good point. I do not have enable, so I cannot be correct. :)

Steve Rubin * ser@tch.org * http://www.tch.org/~ser/

TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (Enable? We dunt need no stinkin' enable!!)

At 01:27 AM 2/19/00 -0700, John M. Brown wrote:

Yes, 3561 is one of our transit. This isn't about what filters we have or don't have. its about the fact that from my view there are some announcements that really shouldn't be on the net in the first place.

The point is, those /27s, /30s and /32s are *not* on the 'Net, they are internal to C&W. You should not condemn the global table because C&W leaks specifics to their customers. Those other routes - like 64/8, AS7046, etc. - *are* on the global table and should be cleaned up. But no one seems to care about that any more. I find it amusing that some people who argue against micro-allocations say nothing about this added waste. Hypocrisy always amuses me. (It has to or it would piss me off.)

Some providers (some of our other transits) provide a cleaner table.

They probably put the same "sanity" filters on their customers that they put on their peers. I used to do that (when I had enable :).

Personally it seems many BGP folks are lazy and don't keep things clean....

That, my friend, is and has been obvious for many years. :)

I thought patrick got enabled? I know if I keep this up, I will loose it :)

Got it, configured a few routers, changed positions, lost it. Now I go around buying other ISPs instead of configuring routers on my own network. Am I automatically wrong because I do not have enable? Many probably think so. Maybe they are right. :) TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (Enable? We dunt need no stinkin' enable!!)

On Tue, 22 Feb 2000, Ulf Zimmermann wrote:

...

The point is, those /27s, /30s and /32s are *not* on the 'Net, they are internal to C&W. You should not condemn the global table because C&W leaks specifics to their customers.

I am not connected directly to C&W, but via Exodus and I see the same routes like 63.84.242.192/26. So they not only inside of C&W and to their customers.

-- Regards, Ulf.

As we see 63.82.242.192: *63.80.0.0/13 Neighbor: 209.115.127.21 Description: FNSI TRANSIT ASPath: 6259 3549 701(IGP) Nexthop: 209.115.127.21 Weight: 0 Localpref: 100 Last update: Tue Feb 22 11:31:39 2000 Sheesh folks. If your upstream isn't filtering at /24, you REALLY can do it yourself. If it bothers you so much, contact whomever is leaking prefixes longer than /24. Don't bitch and whine about it. John Fraizer

With some filtering of say Net-63's /24 bloat and other things, I have reduced my route table by around 4000 routes (71xxx to 67xxx) My point is that if folks like AS 701 would clean up there announcements (and its one of several reasons I don't buy transit from them) then we would have less bloat in the system. Yes, I'd rather see additional routes so that more providers are better connected. Otherwords Micro-Allocations from RIR's would provide: 1. Better connectivity options for the bulk of the providers out there (not big ones) 2. Flexibility to add or change providers for the ISP's 3. Encouragement to multi-home by allowing MA's 4. Less hassles and negative impact on customers from renumbering. (NSI Makes it a real hassle to renumber via updates to host records) But the widespread deagg to /24 doesn't seem to really help improve connectivity On Sat, Feb 19, 2000 at 01:54:33PM -0500, Alex Rubenstein wrote:

...

If people really started doing there part on cleaning up their announcements I bet we could reduce the total routes back down to some nice number........

Hello, John,

What is some 'nice' number? Are your routers suffering from the added amount of routes?

(that's not rhetorical, but a true question; no disrespect meant).

I think that I'd rather see some additional routes in the BGP tree if it meant smarter (as smart as smart can be in regards to BGP) routing information.

...

*> 63.84.242.192/26 166.48.176.25 0 3561 14510 i *> 128.88.250.0/27 166.48.176.25 0 3561 2516 2915 2915 2915 2915 151 i *> 128.88.250.32/29 166.48.176.25 0 3561 2516 2915 2915 2915 2915 151 i *> 137.39.250.20/30 166.48.176.25 0 3561 i *> 158.205.225.40/29 166.48.176.25 0 3561 4694 ? *> 166.32.131.160/27 166.48.176.25 0 3561 i *> 166.35.174.160/27 166.48.176.25 0 3561 i *> 206.98.105.48/28 166.48.176.25 0 3561 4293 i *> 206.141.223.224/27 166.48.176.25 0 3561 6081 7053 7053 7053 7053 i *> 206.142.63.0/28 166.48.176.25 0 3561 i *> 206.151.223.0/26 166.48.176.25 0 3561 4293 i *> 206.151.223.64/28 166.48.176.25 0 3561 4293 i *> 206.151.223.80/28 166.48.176.25 0 3561 4293 i *> 206.151.223.96/27 166.48.176.25 0 3561 4293 i *> 206.151.223.128/27 166.48.176.25 0 3561 4293 i *> 206.151.223.160/28 166.48.176.25 0 3561 4293 i *> 206.151.223.180/30 166.48.176.25 0 3561 4293 i *> 206.151.223.184/30 166.48.176.25 0 3561 4293 i *> 206.151.223.188/30 166.48.176.25 0 3561 4293 i *> 206.151.223.192/27 166.48.176.25 0 3561 4293 i *> 206.152.253.0/27 166.48.176.25 0 3561 4293 i *> 206.157.77.40/30 166.48.176.25 0 3561 i *> 206.157.77.56/30 166.48.176.25 0 3561 i *> 206.157.77.96/30 166.48.176.25 0 3561 i *> 206.157.77.108/30 166.48.176.25 0 3561 i *> 206.157.77.152/30 166.48.176.25 0 3561 i *> 206.157.77.200/30 166.48.176.25 0 3561 i *> 206.157.77.208/30 166.48.176.25 0 3561 i *> 206.171.94.0/26 166.48.176.25 0 3561 3549 13405 i *> 206.218.185.192/26 166.48.176.25 0 3561 3549 i *> 207.49.17.192/28 166.48.176.25 0 3561 4293 i *> 207.51.164.128/26 166.48.176.25 0 3561 11192 i

Hello All, I have been unable to flash a C2501 running this (very old) version of IOS & the IOS even appears to be in-apropriate for the device . But it is for the correct cpu . PS: please point me at the Cisco maillist . I'd rather post this there . But seeing as how little I have been able to get out of Cisco on (some) matters I thought it better to ask those whom probably have run IOS code such as this . Tia, JimL I have attempted : Silverdale#copy tftp flash Copy aborted. Flash address space cannot be written to. Full copy of the startup messages & some other info that may / mat not help . System Bootstrap, Version (3.3), SOFTWARE Copyright (c) 1986-1993 by cisco Systems 2500 processor with 4096 Kbytes of main memory Illegal Novell address Unable to parse map address Booting igs-bfpx.914-4.fc3 from Flash address space F3: 2220004+72336+271172 at 0x3000060 ...snip... 3000 Software (IGS-BFPX), Version 9.14(4) fc3, RELEASE SOFTWARE Copyright (c) 1986-1993 by cisco Systems, Inc. Compiled Mon 13-Dec-93 17:20 by chansen cisco 3000 (68030) processor (revision A) with 4096K/2048K bytes of memory. Processor board serial number 01065926 DDN X.25 software, Version 2.0, NET2 and BFE compliant. Bridging software. SuperLAT software (copyright 1990 by Meridian Technology Corp). 1 Ethernet/IEEE 802.3 interface. 2 Serial network interfaces. 32K bytes of non-volatile configuration memory. 4096K bytes of Flash address space sized on CPU board.  Press RETURN to get started! %SYS-5-CONFIG_I: Configured from memory by console () %SYS-5-RESTART: System restarted %LINK-5-CHANGED: Interface Ethernet0, changed state to up %LINK-5-CHANGED: Interface Serial0, changed state to administratively down %LINK-5-CHANGED: Interface Serial1, changed state to administratively down Silverdale>en Password: Silverdale#show flash 4096K bytes of Flash address space sized on CPU board. Memory type is Flash. File name/status 0 igs-bfpx.914-4.fc3 [1901868/4194304 bytes free/total] Silverdale#show flash ? 4096K bytes of Flash address space sized on CPU board. Memory type is Flash. File name/status 0 igs-bfpx.914-4.fc3 [1901868/4194304 bytes free/total] Silverdale#copy tftp flash Copy aborted. Flash address space cannot be written to. Silverdale#show version 3000 Software (IGS-BFPX), Version 9.14(4) fc3, RELEASE SOFTWARE Copyright (c) 1986-1993 by cisco Systems, Inc. Compiled Mon 13-Dec-93 17:20 by chansen System Bootstrap, Version (3.3), SOFTWARE Silverdale uptime is 3 minutes System restarted by power-on System image file is "igs-bfpx.914-4.fc3", booted via flash cisco 3000 (68030) processor (revision A) with 4096K/2048K bytes of memory. Processor board serial number 01065926 DDN X.25 software, Version 2.0, NET2 and BFE compliant. Bridging software. SuperLAT software (copyright 1990 by Meridian Technology Corp). 1 Ethernet/IEEE 802.3 interface. 2 Serial network interfaces. 32K bytes of non-volatile configuration memory. 4096K bytes of Flash address space sized on CPU board. Configuration register is 0x2102 Silverdale#show controller LANCE unit 0, idb 0x59508, ds 0x5AC80, regaddr = 0x2130000, reset_mask 0x2 IB at 0x40D674: mode=0x0000, mcfilter 0000/0101/0000/4040 station address 0000.0c06.9c63 default station address 0000.0c06.9c63 buffer size 1524 RX ring with 16 entries at 0x40D6B8 Rxhead = 0x40D6B8 (0), Rxp = 0x5AC9C (0) 00 pak=0x40D824 ds=0x40D96E status=0x80 max_size=1524 pak_size=0 01 pak=0x40DFA8 ds=0x40E0F2 status=0x80 max_size=1524 pak_size=0 02 pak=0x40E72C ds=0x40E876 status=0x80 max_size=1524 pak_size=0 03 pak=0x40EEB0 ds=0x40EFFA status=0x80 max_size=1524 pak_size=0 04 pak=0x40F634 ds=0x40F77E status=0x80 max_size=1524 pak_size=0 05 pak=0x40FDB8 ds=0x40FF02 status=0x80 max_size=1524 pak_size=0 06 pak=0x41053C ds=0x410686 status=0x80 max_size=1524 pak_size=0 07 pak=0x410CC0 ds=0x410E0A status=0x80 max_size=1524 pak_size=0 08 pak=0x411444 ds=0x41158E status=0x80 max_size=1524 pak_size=0 09 pak=0x411BC8 ds=0x411D12 status=0x80 max_size=1524 pak_size=0 10 pak=0x41234C ds=0x412496 status=0x80 max_size=1524 pak_size=0 11 pak=0x412AD0 ds=0x412C1A status=0x80 max_size=1524 pak_size=0 12 pak=0x413254 ds=0x41339E status=0x80 max_size=1524 pak_size=0 13 pak=0x4139D8 ds=0x413B22 status=0x80 max_size=1524 pak_size=0 14 pak=0x41415C ds=0x4142A6 status=0x80 max_size=1524 pak_size=0 15 pak=0x4148E0 ds=0x414A2A status=0x80 max_size=1524 pak_size=0 TX ring with 4 entries at 0x40D770, tx_count = 0 tx_head = 0x40D778 (1), head_txp = 0x5ACF4 (1) tx_tail = 0x40D778 (1), tail_txp = 0x5ACF4 (1) 00 pak=0x000000 ds=0x40D3CE status=0x43 status2=0x0000 pak_size=118 01 pak=0x000000 ds=0x40D3CE status=0x43 status2=0x0000 pak_size=118 02 pak=0x000000 ds=0x40D3CE status=0x43 status2=0x0000 pak_size=118 03 pak=0x000000 ds=0x40D3CE status=0x43 status2=0x0000 pak_size=118 0 missed datagrams, 0 overruns, 0 late collisions, 37 lost carrier events 0 transmitter underruns, 0 excessive collisions, 0 babbles 0 memory errors, 0 spurious initialization done interrupts Lance csr0 = 0x73 HD unit 0, idb 0x5B570, ds 0x5CCE8 buffer size 1524 No DCE cable cpb = 0x41, eda = 0xE850, cda = 0xE710 RX ring with 16 entries at 0x41E710 00 bd_ptr=0xE710 pak=0x41DF30 ds=0x41E084 status=80 pak_size=0 01 bd_ptr=0xE724 pak=0x41D7AC ds=0x41D900 status=80 pak_size=0 02 bd_ptr=0xE738 pak=0x41D028 ds=0x41D17C status=80 pak_size=0 03 bd_ptr=0xE74C pak=0x41C8A4 ds=0x41C9F8 status=80 pak_size=0 04 bd_ptr=0xE760 pak=0x41C120 ds=0x41C274 status=80 pak_size=0 05 bd_ptr=0xE774 pak=0x41B99C ds=0x41BAF0 status=80 pak_size=0 06 bd_ptr=0xE788 pak=0x41B218 ds=0x41B36C status=80 pak_size=0 07 bd_ptr=0xE79C pak=0x41AA94 ds=0x41ABE8 status=80 pak_size=0 08 bd_ptr=0xE7B0 pak=0x41A310 ds=0x41A464 status=80 pak_size=0 09 bd_ptr=0xE7C4 pak=0x419B8C ds=0x419CE0 status=80 pak_size=0 10 bd_ptr=0xE7D8 pak=0x419408 ds=0x41955C status=80 pak_size=0 11 bd_ptr=0xE7EC pak=0x418C84 ds=0x418DD8 status=80 pak_size=0 12 bd_ptr=0xE800 pak=0x418500 ds=0x418654 status=80 pak_size=0 13 bd_ptr=0xE814 pak=0x417D7C ds=0x417ED0 status=80 pak_size=0 14 bd_ptr=0xE828 pak=0x4175F8 ds=0x41774C status=80 pak_size=0 15 bd_ptr=0xE83C pak=0x416E74 ds=0x416FC8 status=80 pak_size=0 16 bd_ptr=0xE850 pak=0x4166F0 ds=0x416844 status=80 pak_size=0 cpb = 0x41, eda = 0xE9D8, cda = 0xE9D8 TX ring with 4 entries at 0x41E9D8 00 bd_ptr=0xE9D8 pak=0x000000 ds=0x000000 status=81 pak_size=0 01 bd_ptr=0xE9EC pak=0x000000 ds=0x000000 status=81 pak_size=0 02 bd_ptr=0xEA00 pak=0x000000 ds=0x000000 status=81 pak_size=0 03 bd_ptr=0xEA14 pak=0x000000 ds=0x000000 status=81 pak_size=0 04 bd_ptr=0xEA28 pak=0x000000 ds=0x000000 status=81 pak_size=0 0 missed datagrams, 0 overruns, 0 bad frame addresses 0 bad datagram encapsulations, 0 memory errors 0 transmitter underruns HD unit 1, idb 0x5CD7C, ds 0x5E4F0 buffer size 1524 No DCE cable cpb = 0x41, eda = 0xEDE0, cda = 0xECA0 RX ring with 16 entries at 0x41ECA0 00 bd_ptr=0xECA0 pak=0x415F6C ds=0x4160C0 status=80 pak_size=0 01 bd_ptr=0xECB4 pak=0x4157E8 ds=0x41593C status=80 pak_size=0 02 bd_ptr=0xECC8 pak=0x415064 ds=0x4151B8 status=80 pak_size=0 03 bd_ptr=0xECDC pak=0x406BF8 ds=0x406D4C status=80 pak_size=0 04 bd_ptr=0xECF0 pak=0x40737C ds=0x4074D0 status=80 pak_size=0 05 bd_ptr=0xED04 pak=0x407B00 ds=0x407C54 status=80 pak_size=0 06 bd_ptr=0xED18 pak=0x408284 ds=0x4083D8 status=80 pak_size=0 07 bd_ptr=0xED2C pak=0x408A08 ds=0x408B5C status=80 pak_size=0 08 bd_ptr=0xED40 pak=0x425BA8 ds=0x425CFC status=80 pak_size=0 09 bd_ptr=0xED54 pak=0x425424 ds=0x425578 status=80 pak_size=0 10 bd_ptr=0xED68 pak=0x424CA0 ds=0x424DF4 status=80 pak_size=0 11 bd_ptr=0xED7C pak=0x42451C ds=0x424670 status=80 pak_size=0 12 bd_ptr=0xED90 pak=0x423D98 ds=0x423EEC status=80 pak_size=0 13 bd_ptr=0xEDA4 pak=0x423614 ds=0x423768 status=80 pak_size=0 14 bd_ptr=0xEDB8 pak=0x422E90 ds=0x422FE4 status=80 pak_size=0 15 bd_ptr=0xEDCC pak=0x42270C ds=0x422860 status=80 pak_size=0 16 bd_ptr=0xEDE0 pak=0x421F88 ds=0x4220DC status=80 pak_size=0 cpb = 0x41, eda = 0xEF68, cda = 0xEF68 TX ring with 4 entries at 0x41EF68 00 bd_ptr=0xEF68 pak=0x000000 ds=0x000000 status=81 pak_size=0 01 bd_ptr=0xEF7C pak=0x000000 ds=0x000000 status=81 pak_size=0 02 bd_ptr=0xEF90 pak=0x000000 ds=0x000000 status=81 pak_size=0 03 bd_ptr=0xEFA4 pak=0x000000 ds=0x000000 status=81 pak_size=0 04 bd_ptr=0xEFB8 pak=0x000000 ds=0x000000 status=81 pak_size=0 0 missed datagrams, 0 overruns, 0 bad frame addresses 0 bad datagram encapsulations, 0 memory errors 0 transmitter underruns Silverdale#show env Silverdale#show stacks Minimum process stacks: Free/Size Name 670/1000 Init 962/1000 MOP Protocols Interrupt level stacks: Level Called Free/Size Name 3 0 1000/1000 Serial interface state change interrupt 4 39 922/1000 Network interfaces 5 10050 952/1000 Console Uart Silverdale#exit +----------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | 25416 22nd So | Give me Linux | | babydr@baby-dragons.com | DesMoines WA 98198 | only on AXP | +----------------------------------------------------------------+

At 12:14 AM 2/21/00 -0500, jmalcolm@uraeus.com wrote:

701 per se is not the problem, as proportionally it's quite a bit better than most of the other large ASes. It only appears on the list because it is large in absolute numbers.

Perhaps 701 is not a problem, but I see at least three separate UUNET ASes on the CIDR report.

Now 7046, which is UUNET customers announcing routes themselves, is pretty bad, and is a slightly harder problem to solve, although not impossible by any means.

AS7046 was given to each of those customers by UUNET. It is used (at least in the cases I have seen) by networks with two or more connections to UUNET, for BGP load balancing. Please note these are networks which have no other upstream, nor their own AS. So, even though they have multiple links to UUNET, they are still "single-homed" as far as the rest of the 'Net is concerned. The overwhelming majority of prefixes in AS7046 are useless, as they are deaggregates of UUNET CIDR blocks, and not visible anywhere but through UUNET. (There are some /16s which are not part of a larger CIDR sourced from AS701, so you cannot just filter AS7046 from your table without causing some disconnectivity.) UUNET has had *over* a year (I notified them in November of 1998 - who knows how long they knew about it before that) to clean up/filter *one AS*, and has not done it. Please note I tried to inform UUNET politely and privately about this, and waited quite a while for them to fix it. After repeated attempts to get them to do something, a UUNET engineer told me I am not smart enough to understand how hard it is to filter an AS in a network as big as UUNET. (Interesting way to treat a customers, wouldn't you say?) As I am obviously not qualified to comment, the rest of you are welcome to draw your own conclusions on whether 16 months is enough time for even UUNET to filter one AS. Another amusing part is that AS7046 shows up in the CIDR report every week (usually #2). Then again, if AS7046 were counted as part of AS701 (which it essentially is), AS701 would regularly be #1 in the CIDR report. (Maybe Tony should make a change to the report?) Lastly, please note AS7046 is *growing*, not shrinking.

...

Yes, I'd rather see additional routes so that more providers are better connected. Otherwords Micro-Allocations from RIR's would provide:

1. Better connectivity options for the bulk of the providers out there (not big ones) 2. Flexibility to add or change providers for the ISP's 3. Encouragement to multi-home by allowing MA's 4. Less hassles and negative impact on customers from renumbering. (NSI Makes it a real hassle to renumber via updates to host records)

This is not compatible with the goal of holding steady the number of routes.

If these micro allocations were made to multi-homed networks, it would not grow the table, as multi-homed networks already have an AS and appear in the table. It might even shrink the table as people with multiple non-aggregateable /24s were given, say, a /22.

...

But the widespread deagg to /24 doesn't seem to really help improve connectivity

I suspect a lot of it is not intentional.

Does that make it okay? TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (Enable? We dunt need no stinkin' enable!!)