January 2001 - Test - lists.nanog.org

RE: How does one make not playing nice with each other scale? (Wa s: net.terrorism)
by Roeland Meyer 13 Jan '01

13 Jan '01

The consent comes from signing the service agreement and is built into the SLA. Yes, such anti-routing would need to be mentioned ... that is all. I am quite comfortable with AboveNet transit policies, as currently implemented. I have a number of clients, in AboveNet co-lo, that would be greatly inconvenienced were those policies (WRT ORBS) to change significantly. In fact, they are not yet secure enough to withstand the cracker attack wave that usually follows an ORBS listing. I know others, that are NOT clients, in the same shape. But, they are getting there. However, it takes time. -----Original Message----- From: Mathew Butler [mailto:mbutler@tonbu.com] Sent: Saturday, January 13, 2001 2:27 PM To: 'Mark Mentovai'; Paul Vixie Cc: nanog(a)merit.edu Subject: RE: How does one make not playing nice with each other scale? (Wa s: net.terrorism) I'll point out that someone banning a site for AUP violations should only be able to affect their own network, since policies are supposed to be organization-level. (Thus, inflicting your policy decision on someone else is a very gray area, legally and ethically.) The reason why MAPS-RBL works (and is legally protected) is because everyone who uses it must -consent- to using it, and take positive action on their end to configure it. This means that each organization generates and enforces their own policy, though with assistance from an outside consultancy. However, in this case, AboveNet is inflicting policy decisions on transit routes =without consent=. (It's obvious this is without consent, otherwise this thread would never have come up.) It brings up an interesting point, but the law has held in the past that boycotts are only effective and legal if they're voluntary, and if coercion is involved then it become "intimidation tactics" of "organized crime". I can't for the life of me imagine how the Internet is any different -- maybe if you tried to apply turnpike or private highway rules to it, but those rules are generally based on consent, as well. Just some thoughts... -Mat Butler -----Original Message----- From: Mark Mentovai [mailto:mark-list@mentovai.com] Sent: Saturday, January 13, 2001 10:26 AM To: Paul Vixie Cc: nanog(a)merit.edu Subject: Re: How does one make not playing nice with each other scale? (Was: net.terrorism) There are a few things that would stand in the way of adoption of something like this: first, each anti-route would require manual configuration, and that comes with its own set of problems. Another potential issue (this is purely theoretical, I'm not referring to any past, present, or future situation in particular) is that providers trying to blackhole a certain site for AUP violations may want to negatively impact reachability as much as possible, rather than purely keeping the offending traffic off their network. These folks wouldn't want to advertise anti-routes because the resulting blackhole avoidance would encourage others to take working alternate paths, which does less harm to the site in question. Still, this may be a beneficial, even if little-used, addition. Thoughts? Mark

2 1

Re: How does one make not playing nice with each other scale? (Was: net.terrorism)
by Paul Vixie 13 Jan '01

13 Jan '01

marcel(a)our.domaintje.com (Anne Marcel) writes: > There is no need to deaggregate the /16 that contain nullrouted /32's. > This information is (in this case) already available from AS7777 as a > multihop eBGP feed. Nope. No part of ORBS is listed in AS7777. The block which inspired this thread is completely private to AS6461 and has to do with that network's AUG.

5 5

RE: Online BGP study material for newbies
by Irwin Lazar 13 Jan '01

13 Jan '01

Hi, Please see www.itprc.com/routing.htm for several BGP materials. Also, the book "Internet Routing Architectures" by Basam Halabi is well worth reading. Irwin > -----Original Message----- > From: Lionel Lauer [mailto:longword@newsguy.com] > Sent: Friday, January 12, 2001 9:07 AM > To: nanog(a)merit.edu > Subject: Online BGP study material for newbies > > > > Per the subject line, could anyone recommend online sources of > information that would be helpful for a newbie (approx. CCNA level) > learning BGP? > Material that covers both common & best practices in a > Real-World-compatible manner would be especially helpful. > > -- > W > . | ,. w , "Some people are alive only because > \|/ \|/ it is illegal to kill them." Perna condita > delenda est > ---^----^----------------------------------------------------- > ---------- >

1 0

BGP Filtering
by Jon Stanley 13 Jan '01

13 Jan '01

I was assiting a customer the other day who was attempting to act as transit to us (we were filtering it thank goodness). Now my question is why the AS_PATH list that I gave him did not work. His AS is (let's say) 65000, and he has a transit AS 65001. He is multi-homed with AS1 and AS6347. Here is what I gave him: ip as-path access-list 20 deny ^.*(_6347).*$ ip as-path access-list 20 deny ^.*(_1).*$ ip as-path access-list 20 permit .* and I then applied it as a filter-list outbound on the neighbor. This worked great at filtering out the routes that he was originating. As for the routes that HIS transit customer was advertising, it didn't work at all - they weren't getting advertised. I thought that the access-list may have been defective, so i changed the second line to ^.*(_1_).*$ but that didn't help either. What I wound up doing as a bandaid was putting in ip as-path access-list 20 permit ^65001$ between the second deny and the permit .*. Now I may not understand Cisco regular expressions, but the first access-list the desired effect was to deny everything with AS1 or AS6347 in the as-path and permit everything else. Why didn't this work as intended? AS numbers changed to protect the innocent :).

3 2

net.terrorism
by Sabri Berisha 13 Jan '01

13 Jan '01

Hi, My name is Sabri. I'm just another dude involved in internetworking and I work for a small isp in The Netherlands. I am concerned. Concerned about people and companies who think they are in the position to be net.gods and for political reasons destroy the free character of the internet. In the history of the internet, people have been trusting each other. On the lower technical levels, great things like peering have been developed. At the various IX'es, commercial and non-profit companies exchange information about each others routes using BGP4 and various other routing protocols. In my opinion, announcing a netblock using BGP4 is making a promise to carry traffic to a destination within that netblock. If you feel that parts of that network are against your ethics or AUP, you should not be announcing such a netblock. If you do so, you will make a promise which you do not forfill. That is not a nice thing to do in a world which is based on trust and agreements between parties. I was shocked to find out that one of the larger transit providers (which the company I work for buys transit from) is actively violating the trust it has been given by the internetworld. Above.net is blocking a host in UUnet IP space. After finding out about this we notified Above.net in The Netherlands and asked what it was about and requested them to stop announcing the netblock if they would continue to nullroute the host involved. After various contacts about this matter, Above.net answered with the following statements (according to the salesdroid it came from Paul Vixie himself): > 194.178.232.55/32. --> this tester is part of a /16 belonging to > uunet, and sends traffic which is in violation of our AUG. we > complained to uunet without any effect. if we have blocked access > from this /32 to our backbone, we are within our rights. After this mail, we contacted Above.net again. They basically told us it was for our own protection because that traffic from that host does not comply to their AUP. We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response. More information and logs on http://www.bit.nl/~sabri/above/ -- /* Sabri Berisha * * CCNA, BOFH, Systems admin Linux/FreeBSD */

20 35

Cogent?
by Timothy Brown 12 Jan '01

12 Jan '01

I seem to remember reading some stuff about Cogent on NANOG a short while back, but I can't find it in cctec's archive. So my question is this: Cogent is advertising 100M for $1000 a month by bringing their own fiber into facilities. Does anyone have experience with Cogent? Can anyone tell me things like do they meet their install deadlines, is there anything peculiar about their network, etc. Thanks, Tim

2 1

RE: BGP keepalive/holdtime at GigE exchange
by Lane Patterson 12 Jan '01

12 Jan '01

No, I'm not thinking of cases of gracefully closed sessions, only the behavior of non-gracefully closed sessions. I think the lack of argument here means it's by and large not an important issue, since folks shut down sessions gracefully before doing a maintenance, right? But the answer that "it needs to be at 180 seconds holdtime to maintain routing stability" doesn't seem to hold water since no one's claiming instability caused on private peering links and iBGP sessions due to 10 second interface keepalives ;-) I think the answer is that it just hasn't been important enough to ever change the defaults. > From: Sean Donelan [mailto:sean@donelan.com] > > On Fri, 12 January 2001, Lane Patterson wrote: > > Hmm, I know there are a lot of overburdened BR's out there, but > > since this is set on a per-neighbor basis, there should at least > > be room for some selective optimization. It seems a bit crazy > > to think that each time there's a BR maintenance/reboot at an IXP, > > peers will continue to send to the bit bucket in the sky for 180+ > > seconds. > > What kind of failure modes are you protecting against. The most > common reasons for ending a BGP session will usually include a > TCP CLOSE. There is no problem with a "normal" shutdown because > BGP will immediately withdraw the routes. The timers are for > aborts, such as someone unplugged the neighbor. > > The reason I see for lowering the BGP timer is enabling an upper layer > protocol to ride through the storm. Does Vern Paxson have any data on > how long typical TCP streams survive during periods of > routing instability? > > If a TCP application lasts 180 seconds, and it takes 150 > seconds to recompute > the route table, wouldn't you set the timeout to 30 seconds? > (all numbers > fictional) > > >

1 0

RE: BGP keepalive/holdtime at GigE exchange
by Sean Donelan 12 Jan '01

12 Jan '01

On Fri, 12 January 2001, Lane Patterson wrote: > Hmm, I know there are a lot of overburdened BR's out there, but > since this is set on a per-neighbor basis, there should at least > be room for some selective optimization. It seems a bit crazy > to think that each time there's a BR maintenance/reboot at an IXP, > peers will continue to send to the bit bucket in the sky for 180+ > seconds. What kind of failure modes are you protecting against. The most common reasons for ending a BGP session will usually include a TCP CLOSE. There is no problem with a "normal" shutdown because BGP will immediately withdraw the routes. The timers are for aborts, such as someone unplugged the neighbor. The reason I see for lowering the BGP timer is enabling an upper layer protocol to ride through the storm. Does Vern Paxson have any data on how long typical TCP streams survive during periods of routing instability? If a TCP application lasts 180 seconds, and it takes 150 seconds to recompute the route table, wouldn't you set the timeout to 30 seconds? (all numbers fictional)

1 0

route reflectors
by Tony Mumm 12 Jan '01

12 Jan '01

-----BEGIN PGP SIGNED MESSAGE----- Nanog: I am looking back into researching the many flavors of route reflectors, and would like everyone's opinions on what to use. I believe we have hashed through this in the past, but as these things move quickly, it might help to discuss the latest. I would like to consider both sides of the equation, using router based platforms, as well as PC or workstation type reflectors. I'm sure we all have pros and cons to either method. I'm trying to consider the entire range of reflectors, all at varying levels of cost. The gauntlet runs from free software that is entirely unsupported up to support contracts where a software developer will live with you. Just to add my thoughts: I'm leaning towards PC/Unix based reflectors just due to the cost of hardware, especially memory. It is much easier to have parallel and redundant workstations, than it is to have a carrier class router. Thanks for any help, Tony -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQB1AwUBOl9PVpdSAaybdldZAQFZeAL+Jolh40KSPTKaroJi7BH8VEbfdrU3O7w5 pedJqbIe7kQuPSDD4XL0QgXYAKV3AJnKsJfvDYURxs/73ng0phzOVzIgRd0fTy2F MFbfyQIF9IGM2s150WZpC2bdSo17L/AL =j2cB -----END PGP SIGNATURE-----

3 2

Online BGP study material for newbies
by Lionel Lauer 12 Jan '01

12 Jan '01

Per the subject line, could anyone recommend online sources of information that would be helpful for a newbie (approx. CCNA level) learning BGP? Material that covers both common & best practices in a Real-World-compatible manner would be especially helpful. -- W . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^---------------------------------------------------------------

2 1