March 1998 - Test - lists.nanog.org

RE: BGP Confederation config problem...
by Richard Parker 09 Mar '98

09 Mar '98

Andy, > We have a 4-memberAS confederation, each with two IBGP peers. The > arrangement looks sort of like an octagon. the "r" is AS3 is an > internal hop, not a BGP peer. > > _______ ______ > | R-----R---r | > | / | | | | > |AS2 R | |AS3 R | > ----|-- ----|- > | | > ____|__ ____|_ > |AS4 R | |AS1 R | > | \ | | / | > | R-------R | > ------- ------ > > The problem is this: How do you get BGP to choose the shortest > "AS PATH", since internal AS paths are ignored in selecting BGP > routes? Right now, to top router in AS4 will always choose a > route through (2 3 1) instead of (1), because it prefers > "external" routes (even external confederation routes) over > internal routes. > > So, when given a choice, the router on the distant side of the AS > will ALWAYS prefer the three-AS-hop path, because it is external. > Is there a way around this?!? Perhaps I'm misunderstanding your question, but I thought BGP considered AS_path length before considering whether the path was an external path or an internal path. According to the Cisco documentation, BGP uses the following criteria to select a path for a destination: 1. If the path specifies a next hop that is inaccessible, drop the update. 2. Prefer the path with the largest weight. 3. If the weights are the same, prefer the path with the largest local preference. 4. If the local preferences are the same, prefer the path that was originated by BGP running on this router. 5. If no route was originated, prefer the route that has the shortest AS_path. 6. If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is lower than EGP, and EGP is lower than Incomplete). 7. If the origin codes are the same, prefer the path with the lowest MED attribute. 8. If the paths have the same MED, prefer the external path over the internal path. 9. If the paths are still the same, prefer the path through the closest IGP neighbor. 10. Prefer the path with the lowest IP address, as specified by the BGP router ID. So, I'm going to make the following assumptions: A. Your BGP configuration is correct, i.e. the routes to AS1 via AS2 don't have a larger weight or local preference. B. You don't have any connectivity problems, i.e. the BGP table in the top router in AS4 contains routes that follow both the (2 3 1) path and the (1) path to the networks in AS1. C. AS4 only originates routes to networks in AS4, not the entire BGP confederation, i.e. no explicit "network" statements for the networks in AS1 and no redistribution of IGP routes to AS1's networks into AS4's BGP table. If this is all true, then perhaps your problem is a "next hop" problem. A next hop problem can occur when the next hop for a BGP entry is unreachable via the IGP. In your example the direct routes to AS1 in the top router in AS4 would have as their next hop the external interface of the bottom router in AS4. So, are you running an IGP on the external interface of the bottom router in AS4? If you are not running an IGP on the external interface, then BGP is not selecting the direct routes to AS1 because they're being rejected due to rule 1 in the above table. If this is indeed the problem, make sure that when you go to fix the problem that you run the IGP on the external interface in "passive" mode so that the peer doesn't hear your IGP updates. -Richard ------------------------------------------------------------ Richard Parker Third Point Systems <richard_parker(a)thirdpoint.com> 2400 Broadway Ave. #D230 +1 (310) 829-5949 Santa Monica, CA 90404

2 1

RE: BGP Confederation config problem...
by Dave Van Allen 09 Mar '98

09 Mar '98

>Avi Freedman suggested using a +1 metric when leaving each member-AS. (Thanks Avi!) But it doesn't seem to help - perhaps I didn't do it right. Did our friend Avi also suggest that you need to add: ! bgp always-compare-med ! ?? Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions -----Original Message----- From: Andy McConnell [mailto:andym@nttlabs.com] Sent: Friday, March 06, 1998 1:02 PM To: nanog(a)merit.edu Subject: BGP Confederation config problem... I have a problem I cannot solve. If anyone is running confederations like mine, I would appreciate some help :-) We have a 4-memberAS confederation, each with two IBGP peers. The arrangement looks sort of like an octagon. the "r" is AS3 is an internal hop, not a BGP peer. _______ ______ | R-----R---r | | / | | | | |AS2 R | |AS3 R | ----|-- ----|- | | ____|__ ____|_ |AS4 R | |AS1 R | | \ | | / | | R-------R | ------- ------ The problem is this: How do you get BGP to choose the shortest "AS PATH", since internal AS paths are ignored in selecting BGP routes? Right now, to top router in AS4 will always choose a route through (2 3 1) instead of (1), because it prefers "external" routes (even external confederation routes) over internal routes. So, when given a choice, the router on the distant side of the AS will ALWAYS prefer the three-AS-hop path, because it is external. Is there a way around this?!? Avi Freedman suggested using a +1 metric when leaving each member-AS. (Thanks Avi!) But it doesn't seem to help - perhaps I didn't do it right. In fact, it doesn't look like the metrics are adjusted more than 1. for example, from AS2, the lower router sees every route outside of AS2 as having only metric 1! The top router in AS3 does not add 1 to the metrics it readvertises to AS2. I've been stewing over this problem for some time... I believe there is some clue that I've missed. Any help would be greatly appreciated! -Andy -- Andy McConnell fAf"fffB f}fbfRflf< Network Architect, NTT Multimedia Communications Laboratories Writing about music is like dancing about architecture.

2 1

Sprint outage 980309
by Joe Provo - Network Architect 09 Mar '98

09 Mar '98

Anyone from Sprint care to publicly shed light on the 4 hour outage this morning? -- Joe Provo, Network Architect 508.229.8400 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

2 1

Ed Kern's NAT talk from the Feb NANOG notes are now on line
by sob＠academ.com 08 Mar '98

08 Mar '98

There have been some questions to me about when this would be available. The answer is now! http://www.academ.com/nanog/feb1998/nat.html Enjoy. [Note: The rest of them are coming shortly. Hopefully, you will find them all there by 12 noon CST tomorrow.]

1 0

WorldCom Fiber Cut
by Steve Noble 08 Mar '98

08 Mar '98

WorldCom is reporting a fibercut in Atlanta affecting multiple DS3's no ETA at this time, crew's should be onsite now or soon.

1 0

BGP Confederation config problem...
by Andy McConnell 07 Mar '98

07 Mar '98

I have a problem I cannot solve. If anyone is running confederations like mine, I would appreciate some help :-) We have a 4-memberAS confederation, each with two IBGP peers. The arrangement looks sort of like an octagon. the "r" is AS3 is an internal hop, not a BGP peer. _______ ______ | R-----R---r | | / | | | | |AS2 R | |AS3 R | ----|-- ----|- | | ____|__ ____|_ |AS4 R | |AS1 R | | \ | | / | | R-------R | ------- ------ The problem is this: How do you get BGP to choose the shortest "AS PATH", since internal AS paths are ignored in selecting BGP routes? Right now, to top router in AS4 will always choose a route through (2 3 1) instead of (1), because it prefers "external" routes (even external confederation routes) over internal routes. So, when given a choice, the router on the distant side of the AS will ALWAYS prefer the three-AS-hop path, because it is external. Is there a way around this?!? Avi Freedman suggested using a +1 metric when leaving each member-AS. (Thanks Avi!) But it doesn't seem to help - perhaps I didn't do it right. In fact, it doesn't look like the metrics are adjusted more than 1. for example, from AS2, the lower router sees every route outside of AS2 as having only metric 1! The top router in AS3 does not add 1 to the metrics it readvertises to AS2. I've been stewing over this problem for some time... I believe there is some clue that I've missed. Any help would be greatly appreciated! -Andy -- Andy McConnell アンディマッコネル Network Architect, NTT Multimedia Communications Laboratories Writing about music is like dancing about architecture.

2 2

Re: DoS ATTACK IN PROGRESS
by Jim Warner 07 Mar '98

07 Mar '98

Alex Rubenstein wrote: networks being used to facilitate the smurk (i.e. COME ON PEOPLE, TAME YOUR GODDAMN ROUTERS) I am real sympathetic. But NANOG is just a mailing list. The folks that read it by and large have already tamed their routers. If you want to have an impact on this problem, you'll have to grab your telephone and start contacting specific sites and the follow up with email. I know this is a lot of work because that's what we did with the netflow data we got from our smurf attack. In our efforts we found generally: 1. It is pretty easy to get sites to fix this once you get their attention. Our success rate with a telephone was about 80 percent. You are in a real good position to get their attention when you can say 'Your site is attacking my network and it hurts.' 2. Federal networks are the most trouble. NASA is not very well organized. After many calls, we got attention at NASA-ames and JPL, but we could not figure out who at NASA-Goddard to talk to. Ragging on this list is probably within its charter. That's not the problem. It is simply not going to be effective. -jim warner, UC Santa Cruz

1 0

Re: DoS ATTACK IN PROGRESS
by Alex Rubenstein 07 Mar '98

07 Mar '98

http://www.quadrunner.com/~chuegen/smurf/ On Fri, 6 Mar 1998, Tom T. Thai wrote: > recomendations regarding configuring routers to prevent these? I only > have a set of rules and am not sure if it's effective. What do you use? > > On Fri, 6 Mar 1998, Alex Rubenstein wrote: > > > > > We are currently under a Smurf attack. > >

1 0

DoS ATTACK IN PROGRESS
by Alex Rubenstein 06 Mar '98

06 Mar '98

We are currently under a Smurf attack. The ip address being attack is 207.99.6.75 (a static ip user on my network) Any help would be appreciated networks being used to facilitate the smurk (ie: COME ON PEOPLE; TAME YOUR GODDAMN ROUTERS) SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts B/Pk Et1/3 129.52.30.254 Hs2/0 207.99.6.75 01 0000 0000 25K 76 Et1/3 129.52.35.3 Se3/2 207.99.6.75 01 0000 0000 38K 76 Et1/3 129.52.35.4 Se3/2 207.99.6.75 01 0000 0000 38K 76 Et1/3 129.52.35.58 Se3/2 207.99.6.75 01 0000 0000 38K 76 Et1/3 129.52.35.92 Se3/2 207.99.6.75 01 0000 0000 33K 76 Et1/3 129.52.35.75 Se3/2 207.99.6.75 01 0000 0000 41K 76 Et1/3 129.52.35.241 Se3/2 207.99.6.75 01 0000 0000 34K 76 Et1/3 129.52.35.245 Se3/2 207.99.6.75 01 0000 0000 18K 76 Et1/3 129.52.35.232 Se3/2 207.99.6.75 01 0000 0000 40K 76 Et1/3 129.52.35.235 Se3/2 207.99.6.75 01 0000 0000 41K 76 Et1/3 129.52.35.238 Se3/2 207.99.6.75 01 0000 0000 42K 76 Et1/3 129.52.35.230 Se3/2 207.99.6.75 01 0000 0000 41K 76 Et1/3 129.52.34.81 Se3/2 207.99.6.75 01 0000 0000 31K 76 Et1/3 129.52.34.80 Se3/2 207.99.6.75 01 0000 0000 29K 76 Et1/3 129.52.34.79 Se3/2 207.99.6.75 01 0000 0000 26K 76 Et1/3 129.52.34.78 Se3/2 207.99.6.75 01 0000 0000 31K 76 Et1/3 38.1.53.236 Se3/0 207.99.6.75 01 0000 0000 3823 76 Et1/3 38.1.53.237 Se3/0 207.99.6.75 01 0000 0000 3813 76 Et1/3 38.1.53.238 Se3/0 207.99.6.75 01 0000 0000 3833 76 Et1/3 38.1.53.239 Se3/0 207.99.6.75 01 0000 0000 3801 76 Et1/3 38.1.53.233 Se3/0 207.99.6.75 01 0000 0000 3793 76 Et1/3 38.1.53.234 Se3/0 207.99.6.75 01 0000 0000 3827 76 Et1/3 38.1.53.235 Se3/0 207.99.6.75 01 0000 0000 3825 76 Et1/3 38.1.53.228 Se3/0 207.99.6.75 01 0000 0000 6414 76 Et1/3 38.1.53.229 Se3/0 207.99.6.75 01 0000 0000 4064 76 Et1/3 38.1.53.230 Se3/0 207.99.6.75 01 0000 0000 4130 76 Et1/3 38.1.53.231 Se3/0 207.99.6.75 01 0000 0000 3827 76 Et1/3 129.37.202.46 Se3/2 207.99.77.23 06 0502 0050 7 140 Et1/3 129.37.202.46 Se3/2 207.99.77.23 06 0503 0050 5 184 Et1/3 129.37.202.46 Se3/2 207.99.77.23 06 0500 0050 11 136 Et1/3 129.37.202.46 Se3/2 207.99.77.23 06 0501 0050 8 128 Et1/3 129.37.202.46 Se3/2 207.99.77.23 06 0504 0050 4 131

1 0

The Cidr Report
by Tony Bates 06 Mar '98

06 Mar '98

This is an auto-generated mail on Fri Mar 6 12:00:01 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 06Mar98 0) General Status Table History ------------- Date Prefixes 270298 49830 280298 49218 010398 49211 020398 49301 030398 49206 040398 49095 050398 49430 060398 49432 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3301 Number of ASes announcing only one prefix: 1558 (805 cidr, 753 classful) Largest number of cidr routes: 430 announced by AS3561 Largest number of classful routes: 1012 announced by AS701 1) Gains by aggregating at the origin AS level --- 06Mar98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 583 360 223 38.3% iSTAR Internet, Inc. AS4293 431 222 209 48.5% IMCI AS816 615 440 175 28.5% UUNET Canada (ASN-UUNETCA-AS4) AS174 800 639 161 20.1% Performance Systems International AS3602 460 307 153 33.3% Sprint Canada Inc. AS3749 216 66 150 69.4% TECNET AS701 1012 863 149 14.7% Alternet AS8505 150 36 114 76.0% Middle East Technical University AS3751 125 48 77 61.6% SNET-AS AS5668 110 38 72 65.5% Century Telephone Inc. AS4151 122 56 66 54.1% USDA Internet Access Network AS3804 206 143 63 30.6% Bell Solutions AS3221 94 34 60 63.8% EENet Autonomous System AS1239 579 520 59 10.2% SprintLink Backbone AS271 112 56 56 50.0% BCnet Backbone AS10928 94 40 54 57.4% UNKNOWN AS3464 118 65 53 44.9% Alabama Research and Education Ne AS549 211 162 49 23.2% ONet Backbone AS4755 82 33 49 59.8% Videsh Sanchar Nigam Ltd. India AS72 84 36 48 57.1% Schlumberger Information Network AS1221 266 218 48 18.0% AARNET-AS AS4763 124 78 46 37.1% Telstra New Zealand AS7046 138 94 44 31.9% UUNET-CUSTOMER AS6181 67 23 44 65.7% FUSE-NET AS6335 64 22 42 65.6% NTRNET AS3561 888 846 42 4.7% MCI AS2711 97 55 42 43.3% SUNBELT-AS AS10722 73 31 42 57.5% Aluminum Co. of America AS4740 348 307 41 11.8% ASN-OZEMAIL (Ozemail Pty Ltd) AS852 154 115 39 25.3% AGT Advance Communication For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0