- Test - lists.nanog.org

MCI outage on 8/29?
by Dan Hollis 31 Aug '98

31 Aug '98

Anyone have details on the MCI outage 8/29? All routing to their seattle POP was down from 8:45a PST - 11:30a PST. More weekend warriors with backhoes? -Dan

1 0

BGP Communities - almost an operational question
by Alex Bligh 31 Aug '98

31 Aug '98

I've been trying to find out any logical reason why Ciscos limit me to 16 communities per route. I'm not asking on cisco-nsp as I want to know whether other routers suffer this limitation. Having read and reread rfc1771 and rfc1997, I think the community attribute list is limited by (a) the message length (not really relevant) and (b) the attribute length. The latter appears to be mainly an issue of whether one can be bothered to use extended-length in lieu of non-extended length. Even without using extended-length you have 255 bytes to play with which my calculation gives you 61 or 62 community attributes to play with. So: a) Have I just read the RFC wrong? b) Does other s/w (GateD. Bay etc.) have the same limitation? c) What happens if I try and feed routes with lots of community attributes to a Cisco, (perhaps I feed routes with less than 16 communities on but have set community additive)? Does it drop some randomly? Given that some people use 666 style filtering to prevent advertisement of routes to peers, could this cause leaks? (yes, I have an application for more than 16 communities per route). -- Alex Bligh GX Networks (formerly Xara Networks)

3 2

Question2
by Tim Wolfe 31 Aug '98

31 Aug '98

I've gotten lot's of responses on my original question, but I'm finding perhaps I didn't ask the correct one. What I really need to know is what is the real world effect of latency on throughput? I know that frame relay has a higher latency than a point to point line, and that a point to point is generally regarded as faster. Would someone mind explaining the specifics of that relationship a little bit? Again, off list please, unless someone thinks it's an appropriate topic for this list.. Thanks again, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

RE: BayNetworks BGP weirdness last night
by Mike McGuire 31 Aug '98

31 Aug '98

Our logs show nothing unusual for 8/30. BCN running 12.20 code. Mike M. -----Original Message----- From: Scott Gifford [SMTP:sgifford@tir.com] Sent: Monday, August 31, 1998 4:44 PM To: nanog(a)merit.edu Subject: BayNetworks BGP weirdness last night Anybody else with a Bay Networks router using BGP see weirdness last night? Our router started shutting down BGP links saying "AS Loop Detected", but turning on BGP debugging didn't find anything that looked like a loop to me. Eventually I had to turn off loop detection. I was wondering if our router was being weird on its own, or if a route made it into the global routing tables yesterday that Bay's software misconstrued... Thanks, ------Scott.

1 0

Question
by Tim Wolfe 31 Aug '98

31 Aug '98

Anyone have a nice layman's terms explanation of the throughput/latency differences between a 56k modem, a 56k leased line, and a 56k frame relay circuit? This is assuming a "perfect" lab enviroment, ie. the modem connects and sustains at maximum capability, the frame cloud is not overloaded etc.. Please reply off list. Thanks, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

BayNetworks BGP weirdness last night
by Scott Gifford 31 Aug '98

31 Aug '98

Anybody else with a Bay Networks router using BGP see weirdness last night? Our router started shutting down BGP links saying "AS Loop Detected", but turning on BGP debugging didn't find anything that looked like a loop to me. Eventually I had to turn off loop detection. I was wondering if our router was being weird on its own, or if a route made it into the global routing tables yesterday that Bay's software misconstrued... Thanks, ------Scott.

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: BBN /GTEI)
by Brett_Watson＠enron.net 31 Aug '98

31 Aug '98

On 08/28/98 01:14:36 PM owen wrote: > >> >> >> >NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > >Please NOT that!!! I've spent the last 6 months trying to get my >home phone bill straightened out with MCI and PacBell has been >overbilling me for PVC's on my Frame Relay for 18 months. > >Please, let's not drop the internet to the level of service we all >complain about from the Telcos. well alright, they're not perfect but i seriously doubt that if an isp customer (anyone's customer) disputed pulling down a 1.5M .zip file sometime last month as part of their overall usage sensative bill that said isp could show the customer proof in the log files or captured packet traces. my only point was that we have a long way to go on the isp side. and if i'm wrong, i'd appreciate pointers to any rock-solid billing software out there. -brett

2 1

Re: Transaction Based Settlements Encourage Waste (was Re: BBN /GTEI)
by owen＠DeLong.SJ.CA.US 31 Aug '98

31 Aug '98

Well, the telco can't really show me proof of half the things they're billing me for either, since they don't exist. In fact, I've confirmed with the guys running the switches that I only have the number of PVCs I thought I had. The telco is still billing me for n+2 PVCs. I agree with you that ISPs are nowhere near ready to do rock-solid usage billing. My point was that the Telcos aren't either. Let's not drag ISP service down to the level of customer service that is provided by Telcos, PLEASE. Owen > On 08/28/98 01:14:36 PM owen wrote: > > > >> > >> > >> > >NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > >Please NOT that!!! I've spent the last 6 months trying to get my > >home phone bill straightened out with MCI and PacBell has been > >overbilling me for PVC's on my Frame Relay for 18 months. > > > >Please, let's not drop the internet to the level of service we all > >complain about from the Telcos. > > well alright, they're not perfect but i seriously doubt that if an isp > customer (anyone's customer) disputed pulling down a 1.5M .zip file > sometime last month as part of their overall usage sensative bill that said > isp could show the customer proof in the log files or captured packet > traces. my only point was that we have a long way to go on the isp side. > > and if i'm wrong, i'd appreciate pointers to any rock-solid billing > software out there. > > -brett > > >

1 0

http://www.isi.edu/div7/people/bmanning.home/in-addr-audit.html
by bmanning＠ISI.EDU 30 Aug '98

30 Aug '98

The rest of the data will get added tonight for the /8 detail -- --bill

1 0

Re: BBN/GTEI
by Paul Vixie 29 Aug '98

29 Aug '98

> [...], even if someone is NOT doing "best exit" (or there is only one > exit) that doesn't change the fact that the transit customers on the other > network paid in part so they could get there! I keep hearing this and I keep not understanding it. Let's define this in terms of sessions, where "session" means a bunch of related packets (i.e., packets with the same or symmetrical source/destination addresses and which are related to the same real-world action or end-user goal. Could be a TCP session, could be a sh*tload of DNS queries while processing a log file, could be a RealAudio(tm) stream, could be an MBONE broadcast of Grateful Dead. The quoted point is only controversial if the endpoints of a "session" are served/connected by different providers, since if there's only one provider there is no "exit" no "peering" and no problem. "Served" in this context means "carry stuff to/from this end point from/to where it's coming/going." In the current non-market economy used to fund the Internet, it's extremely rare for someone to actually pay by the bit-mile for the costs their service provider undergoes on their behalf. Billing strategies I'm familiar with are all in terms of maximum or average or peak or whatever, per unit time (like for example, T1 by the month.) In a non-market economy where costs don't determine price, costs have to be avoided rather than recovered. People who run big networks can't recover their bit-mile-related costs from their own customers, so they avoid these costs -- usually by requiring that anyone they exchange packets with at no cost be able to exchange those packets "locally" which means, at the greatest cost to the _sender's_ provider and the least cost to the _receiver's_ provider. Closest-exit routing doesn't do this. The biggest packets of the session are being carried by the person who isn't getting paid any money by the sender and is not being paid by the bit-mile by the receiver. We don't have a micropayment facility, and won't for some years yet, that can turn this into a free market where costs can be recovered rather than avoided. So you'll see folks avoiding them. And, getting back to the text I quoted to give this message context: NO. "No, the transit customers on the other network did NOT pay the costs of this traffic." Deaggregation and MEDs aren't a scalable solution to this problem. At the moment, negotiated transit or private peering are the only ways to get the costs of these bit-miles to be spread out among the people who benefit from them. This situation bears striking resemblence to the way the NBA and NFL do revenue sharing among large market and small market teams. That's not a market economy either, but we lack the technology for a market economy. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

4 8