- NANOG - lists.nanog.org

Re: Routing Loops
by Marshall Eubanks 20 Apr '01

20 Apr '01

"Foster, Kristopher" wrote: Well, that might be what they are TRYING to do, but read it carefully : 6259 6295 6259 Is a loop in my book. Marshall > They're just prepending the AS path to influence their upstreams.. > > Kris, > > -----Original Message----- > From: Marshall Eubanks [mailto:tme@21rst-century.com] > Sent: April 20, 2001 2:23 PM > To: Nanog mailing list; hostmaster(a)fnsi.net > Subject: Routing Loops > > Hello; > > I suddenly see a whole bunch of routing loops for paths going through AS > 6259 > > Unicast Autonomous System Routing Loop Detection > > Date of BGP Dump Fri Apr 20 13:57:36 EDT 2001 > > 1 ROUTING LOOPS Detected for ASN 11548 Prefix = 63.69.155.0/24 : PATH > = : 1239 3549 6259 6295 6259 11548 > 1 ROUTING LOOPS Detected for ASN 11548 Prefix = 63.81.238.0/24 : PATH > = : 1239 3549 6259 6295 6259 11548 > 1 ROUTING LOOPS Detected for ASN 13944 Prefix = 64.241.89.0/24 : PATH > = : 1239 3549 6259 6295 6259 13944 > 1 ROUTING LOOPS Detected for ASN 13944 Prefix = : PATH > = : 1239 3549 6259 6295 6259 13944 > 1 ROUTING LOOPS Detected for ASN 14813 Prefix = 66.35.68.0/22 : PATH > = : 1239 3549 6259 6295 6259 13944 14813 > 1 ROUTING LOOPS Detected for ASN 17266 Prefix = 66.35.72.0/23 : PATH > = : 1239 3549 6259 6295 6259 13944 17266 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 138.46.0.0 : PATH > = : 701 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 2015 Prefix = 139.171.0.0/19 : PATH > = : 1239 3549 6259 6295 6259 2015 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 143.61.153.0/24 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 143.61.233.0/24 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 192.84.218.0 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 198.181.242.0 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 204.107.238.0 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 204.238.145.0 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 206.183.224.0/19 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 209.41.192.0/18 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 8142 Prefix = : PATH > = : 1239 3549 6259 6295 6259 8142 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 209.115.0.0/17 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 216.28.0.0/15 : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 14470 Prefix = 216.28.223.0 : PATH > = : 1239 3549 6259 6295 6259 14470 > 1 ROUTING LOOPS Detected for ASN 11325 Prefix = 216.29.50.0 : PATH > = : 1239 3549 6259 6295 6259 11325 > 1 ROUTING LOOPS Detected for ASN 11303 Prefix = 216.52.158.0 : PATH > = : 1239 11853 11303 11301 11303 > 1 ROUTING LOOPS Detected for ASN 11303 Prefix = : PATH > = : 701 11853 11303 11301 11303 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH > = : 1239 3549 6259 6295 6259 > 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH > = : 1239 3549 6259 6295 6259 > > Anyone know a NOC contact for > Fiber Network Solutions, Inc. (ASN-FIBERNET) ? > > Regards > Marshall Eubanks -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme(a)multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/

1 0

Routing Loops
by Marshall Eubanks 20 Apr '01

20 Apr '01

Hello; I suddenly see a whole bunch of routing loops for paths going through AS 6259 Unicast Autonomous System Routing Loop Detection Date of BGP Dump Fri Apr 20 13:57:36 EDT 2001 1 ROUTING LOOPS Detected for ASN 11548 Prefix = 63.69.155.0/24 : PATH = : 1239 3549 6259 6295 6259 11548 1 ROUTING LOOPS Detected for ASN 11548 Prefix = 63.81.238.0/24 : PATH = : 1239 3549 6259 6295 6259 11548 1 ROUTING LOOPS Detected for ASN 13944 Prefix = 64.241.89.0/24 : PATH = : 1239 3549 6259 6295 6259 13944 1 ROUTING LOOPS Detected for ASN 13944 Prefix = : PATH = : 1239 3549 6259 6295 6259 13944 1 ROUTING LOOPS Detected for ASN 14813 Prefix = 66.35.68.0/22 : PATH = : 1239 3549 6259 6295 6259 13944 14813 1 ROUTING LOOPS Detected for ASN 17266 Prefix = 66.35.72.0/23 : PATH = : 1239 3549 6259 6295 6259 13944 17266 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 138.46.0.0 : PATH = : 701 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 2015 Prefix = 139.171.0.0/19 : PATH = : 1239 3549 6259 6295 6259 2015 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 143.61.153.0/24 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 143.61.233.0/24 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 192.84.218.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 198.181.242.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 204.107.238.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 204.238.145.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 206.183.224.0/19 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 209.41.192.0/18 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 8142 Prefix = : PATH = : 1239 3549 6259 6295 6259 8142 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 209.115.0.0/17 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 216.28.0.0/15 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 14470 Prefix = 216.28.223.0 : PATH = : 1239 3549 6259 6295 6259 14470 1 ROUTING LOOPS Detected for ASN 11325 Prefix = 216.29.50.0 : PATH = : 1239 3549 6259 6295 6259 11325 1 ROUTING LOOPS Detected for ASN 11303 Prefix = 216.52.158.0 : PATH = : 1239 11853 11303 11301 11303 1 ROUTING LOOPS Detected for ASN 11303 Prefix = : PATH = : 701 11853 11303 11301 11303 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH = : 1239 3549 6259 6295 6259 Anyone know a NOC contact for Fiber Network Solutions, Inc. (ASN-FIBERNET) ? Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme(a)multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/

1 0

Re: Routing Loops
by Danny McPherson 20 Apr '01

20 Apr '01

I'm guessing someone fat-fingered their AS prepend policy and instead of "6259 6259" they have "6259 6295". Gotta love that route preference manipulation flexibility of BGP! Interesting timing, considering kc just sent a message to the IRTF-RR list a few days ago discussing another occurrence of this... -danny > 63.69.155.0/24 : PATH = : 1239 3549 6259 6295 6259 11548

1 0

Re: How to game the system (was Re: What does 95th %tile mean?)
by Sean Donelan 20 Apr '01

20 Apr '01

On Thu, 19 April 2001, Greg A. Woods wrote: > This is the Internet -- it's not a circuit-based telephone connection > network, and it's not ATM (though either may be used to transport IP, of > course). It's certainly not equivalent to a power distribution grid > where excess demand starts to look like a short circuit and causes real > damage. The traffic on the Internet is little bunches of packets that > can interleave between each other. Real-world traffic flows on IP > networks are incredibly variable and resilient, partly due to the heroic > efforts of higher level protocols such as TCP. True, there is some buffering in the Internet. And it does make it much more resilant to short term peaks. But as any DDOS attack shows, if you use near peak capacity for even a short term, other traffic is rudely shoved aside. Further, traffic does not return to its original levels for a considerable period of time after each peak capacity event. If you set up conditions just right, not only will you not receive "peak" payment from from the customer gaming the system, you receive lower payments from all your "average" customers too.

3 2

Re: What does 95th %tile mean?
by Toby_Williams＠enron.net 20 Apr '01

20 Apr '01

_95th%ile is not a robust mechanism for billing_ It neither addresses variance nor average use effectively and can be gamed quite easily. It's some kind of best fit system for billing buyers with "normal behaviour". Where in maths class did they ever say that scraping off the highest n percent of a data set in isolation, gives a good indication of anything? Don't you need to look at the mean and 90th percentile together to fairly evaulate distribution. I think the reason it's so popular currently is that it's easy to describe (hence sell) and fits normal use reasonably well, so from a "normal buyer's" perspective is OK. Just as long as everyone is honest. In a thirty day billing period 95th%ile gives you one and a half days of *free bandwidth*. 90th%ile gives you three days of *free bandwidth*. >From the seller's perspective, once this starts getting gamed a little more I can't see it having much of a shelf life, and more sophisticated billing will surface, similar to the power industry Sean sites. I'm quite surprised we're not there already.. has anyone started venturing down this route yet? (other than flat rate) toby

4 3

Re: What does 95th %tile mean?
by richb＠pioneer.ci.net 20 Apr '01

20 Apr '01

I was among the first to get into a dispute with Exodus over the in+out billing policy. I prevailed in the dispute because there was inconsistent language in the service agreement. We had a DS3 and the agreement was capped at a certain monthly obligation based on 45 megabits of usage (actually, I think we paid the maximum at 25 or 30 megabits). But the in+out calculation produces a maximum usage level, for a DS3, of 90 megabits. Rather than change their billing policy, Exodus resolved the dispute by altering our per-meg transit price. Transit is a commodity exchanged in a system of free enterprise. So as long as you ask the vendor to put the usage calculation method in writing _before_ the contract is signed (preferably, disclosed at the time the first price quote is rendered), then there isn't room for disagreement. Roughly speaking, an in+out price quote should carry about half (maybe up to 70%) the per-meg transit price of a max(in,out) price quote. If you know your usage patterns ahead of time, or can readily speculate based on the app (all my users are running Napster, or I'm serving porn to Latin America, or whatever), then you can readily compare price quotes so long as you know how the usage calculatoin works. -rich

1 0

The ultimate routing loop?
by Sean Donelan 20 Apr '01

20 Apr '01

I'm in washington this week, and as usual, some of the strangest ideas come up. Suppose I wanted the best chance for my packet to get through, no matter what tier 1, 2, 3 network was still operating between points A and B. I designate a "special" IP address block, and arrange for the top 10 providers to accept announcements for the block both directly, and transit through any of the other 10 providers. This would allow transit via a third-party network to restore connectivity across a partioned AS. For this network block, other than BGP loop detection, it would bypass the normal peer/transit/peer filters. If a AS was partioned, you might see a route cross two or three primary backbones, and even the same backbone twice. But if the packet went through, its worth it. The questions is: Are more available paths really better? Or does it just create more instability?

2 1

Re: How to game the system (was Re: What does 95th %tile mean?)
by Sean Donelan 20 Apr '01

20 Apr '01

On Thu, 19 April 2001, Greg A. Woods wrote: > From the provider's perspective this doesn't really matter a whole lot > and they can reduce the effect of your bursts on their other customers > by simply narrowing their window. There's no need to do silly sliding > windows, multiple windows, etc. -- the averages are just fine. >From a provider's perspective it does matter. The most costly part of any network is the last 1% because most of the fixed cost of the network is based on the peak capacity, not average capacity. Billing based on average usage works best if you have a large population and excess capacity. Generally its the largest of the large customers who have the most to gain by gaming the system. A few T1 customers gaming the system is just noise. But you might have an OC48 customer who pegs their link requiring you to add more peak capacity to your network. But times their traffic, so their average usage never exceeds an OC24, and pays the average price. This is the type of customer which nailed the electric companies. If you can save tens of thousands dollars by starting an electric smelter at 30 minutes past the hour instead of exactly on the hour, its noticable. The electric companies reserve their fanciest meters for large power consumers like smelters and colo providers :-) This was fine in the past, when we were doubling the Internet's capacity every X days. I have a feeling providers will start managing/reducing the excess capacity headroom in their networks. And will start looking at ways to wring more money out of their current customers. Some rocket science accountant somewhere should be working on a way to maximize the chargable usage by just shifting the window bins back and forth until he finds the maximum. Is there any commercial provider not trying to maximize billable usage? By carefully choosing window bins, a provider could generate 1%, 25%, 50% more revenue across all his usage-based customers. And if you got this idea from me, I expect 5% of the take....

3 2

Re: Governments CERT plans to sell early warnings on Web threats
by Sean Donelan 20 Apr '01

20 Apr '01

Finally, the CERT is actually getting some money for their stuff. Usually, some "security" company (A.K.A. large accounting firm/professional consulting firm) charges a large sum of money claiming they will scour all the secret hacker lairs. But all you get are re-packaged CERT messages. However, are there any "real humans" involved in this effort. The alliance's web site seems purposely designed to obscure all information about the people behind the alliance. No executive direct is listed, no members or listed, only generic roll accounts are listed for e-mail. On Thu, 19 April 2001, Eric Germann wrote: > > http://www.msnbc.com/news/561513.asp?0nm=N14O

1 0

RE: Government?s CERT plans to sell early warnings on Web threat s
by Paul Lantinga 20 Apr '01

20 Apr '01

This is not such a great deal. As many people have mentioned on various news websites, CERT is often *really* slow at getting out warnings - sometimes months or weeks after they have been posted on bugtraq. Buyer beware, that is, unless you enjoy paying for regurgitated warnings that are mostly available elsewhere. -Paul LANtinga Opinions are my own, who else? > -----Original Message----- > From: Eric Germann [mailto:ekgermann@cctec.com] > Sent: Thursday, April 19, 2001 11:16 AM > To: nanog(a)merit.edu > Subject: Government?s CERT plans to sell early warnings on Web threats > > > http://www.msnbc.com/news/561513.asp?0nm=N14O >

1 0