- NANOG - lists.nanog.org

prefix aggregation
by Bernard.Tuy＠urec.fr 05 Feb '97

05 Feb '97

Hi, In many places yet we're discussing prefix aggregation for at least 193/8, 194/8 and 195/8 IP blocks. I was told since a while that some US carriers -such as SprintLink- have decided to filter (id. no more route) prefixes longer than /19. My questions is : - is this impleted yet ? - if yes, who does it, for which class(es) of prefixes of which length ? - if no, when do you intend to have this filtering operational ? As I'm acting as a "consultant" for the french academic network (Renater) I'm interesting in knowing what policy every ISP -specially in the US of A- intend to implement in the near future. Thanks for your help and time, Regards, +Bernard Tuy.

2 1

Re: NAP filters and multicast
by salo＠msc.edu 05 Feb '97

05 Feb '97

> Date: Tue, 4 Feb 1997 21:56:52 -0600 (CST) > From: Sean Donelan <SEAN(a)SDG.DRA.COM> > Subject: NAP filters and multicast > [...] > I haven't looked to closely at > multicast on the ATM NAPs. Are they using ATM's native multicast > capability, or are they using multiple tunnels? ATM's approximation of multicast is still pretty primitive. I would be very surprised if any of the ATM-based NAPs are trying to use ATM multicast to support the MBONE. -tjs

1 0

NAP filters and multicast
by Sean Donelan 05 Feb '97

05 Feb '97

>If full filtering (i.e. everything disallowed) we in place as the default, and each >member had to provide a list of allowed points, and the members of the allowed >points had to agree before the filters were installed, the model would be very >similar to the ATM based NAPs. So far, the ATM based NAP's seem to work >fairly well. *JMO* This varies a lot depending on who is operating the interconnection point. In practice, it often depends on the dedicated work of one or two individuals. If they do a good job, it will work well. If they leave or change jobs, things can get really, really bad. I think Paul Vixie's reaction has a lot to do with the problems dealing with PacBell's SMDS group getting address screening tables configured correctly. It usually takes two or twenty attempts, and you have to check every month, because they have a nasty habit of changing things behind your back. And even then, you may not get the full story, because often the address screen listed on the paperwork in the Pacbell business often doesn't match the address screen configured in the Pacbell SMDS switch. But PacBell won't send you a copy of the actual switch configuration for your port. I do have a question though. How will this effect the efforts to use the native multicast features to carry MBONE traffic. Are we going to end up with multiple tunnels traversing the exchange points carrying identical MBONE packets. Are we going to end up with odd MBONE black holes because multicast packet routing doesn't like NBMA networks. I haven't looked to closely at multicast on the ATM NAPs. Are they using ATM's native multicast capability, or are they using multiple tunnels? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Exchange updates
by Paul Ferguson 05 Feb '97

05 Feb '97

It would *great* if an English version of this page existed. :-/ - paul At 03:43 PM 2/4/97 -0800, bmanning(a)isi.edu wrote: > > Embratel - PIR > GT-ER - PIR [to include the LNCC page]

3 2

Exchange updates
by bmanning＠ISI.EDU 04 Feb '97

04 Feb '97

Hi, Sorry for duplicates. Let me know if this is abusive of these lists and I'll stop sending this kind of data out. New: VIX - Vienna Internet Exchange SNNAP - Seattle Exchange Proposals: Embratel - PIR GT-ER - PIR Baltimore Dead: Cleveland ApricotIX (perhaps to live again!) http://www.isi.edu/div7/ra/naps.html -- --bill

1 0

NANOG Registration CLOSED
by Pam Ciesla 04 Feb '97

04 Feb '97

The attendee list has reached 500. Registration is CLOSED. \ Pam Ciesla

1 0

RE: Alpha test of MAE filtering capability
by Chris A. Icide 04 Feb '97

04 Feb '97

If full filtering (i.e. everything disallowed) we in place as the default, and each member had to provide a list of allowed points, and the members of the allowed points had to agree before the filters were installed, the model would be very similar to the ATM based NAPs. So far, the ATM based NAP's seem to work fairly well. *JMO* >All in all I see this as a huge complication in the underlying structure of the >Mae's. I would be detrimental to the interconnects if ISP's used filtering >as a general practice. It is a great feature to have as a way to stop an >abuse that has been detected and maybe even as a punishment for abusive >ISP's, but lets leave out the extra layer of complication unless it really >adds something to the network > >Scott Blandford >IBM Global Network Chris A. Icide

1 0

Re: Alpha test of MAE filtering capability
by ALAN DORN HETZEL JR 04 Feb '97

04 Feb '97

I don't think filters are a problem for third party routing as long as the third party routing is not done in secret. If I am sending you third party routes for someone, and you know it because I tell you I am and you agree to let me, then you can open your filters to the source port for those routes. Third party routes that are being done without the knowledge of the traffic target are a bad thing and shouldn't be done anyway... -Dorn >It's not that hard to write a script that temporarily points a static route >for an unregistered address at each of the machines at a meet point. By >tracerouting to that address you can detect if someone is pointing default at >you. > >The script does not have to be a very CPU intensive operation, and if it is >run once a day, it ought to provide a fairly good clue as to whether or not >someone is abusing your network. > >I would like to stay away from port filtering except as a last resort. I think >that there are far too many unforeseen problems and complications in debugging. >And for better or worse it would require the removal of all third party >routing which I would guess is pretty common at the Mae's. > >Scott Blandford >IBM Global Network

2 1

Re: ALpha test of MAE filtering capability
by ALAN DORN HETZEL JR 04 Feb '97

04 Feb '97

Certainly this data gives away *some* private information, but having that knowledge is often very useful when one discovers bizarre layer two problems. For instance, being able to ascertain that there is no packet loss from you to all devices on the same switch, and n% packet loss to all devices on another switch, without having to requests that MFS diagnose the apparent L3 problem, is very useful. Perhaps MFS could provide one unfiltered ping-responding device on each switch at a MAE? This would address diagnostic needs without requiring disclosure of other filtering issues. Besides, you can always tell who is reachable with a broadcast ping...

1 0

Re: Internet vs. Telephone company
by William Allen Simpson 04 Feb '97

04 Feb '97

> From: "Paul J. Zawada" <zawada(a)ncsa.uiuc.edu> > There are lots folks in the phone company who have no clue as to how the > Internet works. This is why none of them saw this Internet access thing > coming. (Not that I'm sure they could have done anything about it...) > They now have a network that is underengineered for the way it's being used > and they have to do something about it quick... The only means they know > of is to raise the price. > It's much worse than that. As some folks know, I'm part owner (I provided the hardware out of my spare equipment) of a very small ISP serving northern Mississippi. I don't live in northern Mississippi. There was no Internet service there from anybody else 3 years ago, and the only way we could afford to bring down a line from Chicago to a client was put up modems to share the cost with other local subscribers. Well, we have hundreds of subscribers now (I had no idea there were so many folks scattered about in such a rural area, we get a hundred more each month), and have been paying many thousand $ a year for the lines. You think that in 3 years Bell South might have noticed the need for more infrastructure? Particularly since they highlighted us in their monthly newsletter a year or so back? And that those $ would have been used for upgrading equipment? Well, no. They are still using a _mechanical_ switch, and have no plans to upgrade. They do not have enough lines into the business district for us to add 8 more modems to the pool (it was taking weeks to get existing lines turned on anyway). They refuse to let us co-locate in the CO (they cannot find an official policy, and thus cannot allow it). Giving them more money will not help the problem. And if any of you know someone to talk to in Atlanta to bypass the locals, I'd sure like to know. Thanks in advance! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1