December 2002 - NANOG - lists.nanog.org

Re: 18.0.0.0/8
by Matt Braun 20 Dec '02

20 Dec '02

A large utility outage followed by failures in secondary systems caused power problems in MIT's POP. My understanding is service has been restored. Matt From: "jcvaraillon" <jcvaraillon(a)dolnet.gr> Date: Fri, 20 Dec 2002 20:02:40 +0200 Errors-To: owner-nanog-outgoing(a)merit.edu Hi, Today the network 18.0.0.0/8 disappeared from the Internet, it is now = reachable. I went to different looking glass (MAE East, LINX, GRnet) and 18.0.0.0/8 = was not in their routing table. Is it related to a major problem? Regards, Christophe

1 0

RE: 18.0.0.0/8
by Charles Youse 20 Dec '02

20 Dec '02

Care to elaborate? -----Original Message----- From: Joe Abley [mailto:jabley@isc.org] Sent: Friday, December 20, 2002 1:12 PM To: jcvaraillon Cc: nanog list Subject: Re: 18.0.0.0/8 On Friday, Dec 20, 2002, at 13:02 Canada/Eastern, jcvaraillon wrote: > 4Today the network 18.0.0.0/8 disappeared from the Internet, it is now > reachable. > > I went to different looking glass (MAE East, LINX, GRnet) and > 18.0.0.0/8 was not in their routing table. > > Is it related to a major problem? Yes. Not enough people understand RFC1918. Joe

1 0

Re: 18.0.0.0/8
by Dave Israel 20 Dec '02

20 Dec '02

On 12/20/2002 at 13:11:56 -0500, Joe Abley said: > > > On Friday, Dec 20, 2002, at 13:02 Canada/Eastern, jcvaraillon wrote: > > > 4Today the network 18.0.0.0/8 disappeared from the Internet, it is now > > reachable. > > > > I went to different looking glass (MAE East, LINX, GRnet) and > > 18.0.0.0/8 was not in their routing table. > > > > Is it related to a major problem? > > Yes. Not enough people understand RFC1918. Including me, apparently, since RFC1918 makes no mention of 18/8. And including MIT, probably, since that's their /8. Unless somebody between MIT and the outside world screwed up something involving RFC1918, and you're just being cryptic?

1 0

RE: Using link congestion to control routing updates
by Ejay Hire 20 Dec '02

20 Dec '02

Finally, I found it. If you diddle the K values for EIGRP, you can make it consider reliability, load, and delay statistics when populating a route to the route table. The default behavior is bandwidth and delay. ---Quote---http://www.cisco.com/warp/customer/103/eigrp1.html EIGRP uses these scaled values to determine the total metric to the network: metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)] Note: These K values should be used after careful planning. Mismatched K values prevent a neighbor relationship from being built, which can cause your network to fail to converge. The default values for K are: K1 = 1 K2 = 0 K3 = 1 K4 = 0 K5 = 0 ---Quote---http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps18 28/products_command_reference_chapter09186a00800ca5a9.html#xtocid14 COMMAND SUMMARY. metric weights (Enhanced IGRP) To allow the tuning of the IGRP or Enhanced IGRP metric calculations, use the metric weights router configuration command. To reset the values to their defaults, use the no form of this command. metric weights tos k1 k2 k3 k4 k5 no metric weights Syntax Description tos Type of service. Currently, it must always be zero. k1-k5 Constants that convert an IGRP or enhanced IGRP metric vector into a scalar quantity. ---End Quotes--- Note: If you are going to do this and you also work with BGP, you need to take measures to prevent route-flapping. One option would be to redistribute from EIGRP to BGP and use Summary-address / aggregate-only / next hop self to force only the summary route to be propagated and sustained in the event of an IGP route change. Here's how that works. Internet---EdgeRouter---InternalRouters. Prefix is 192.168.0.0/16 Edgerouter is configured with Summary-address / aggregate-only / next hop selffor the whole 192.168.0.0/16 netblock. As long as it has any route in that netblock then the summary route will be advertised with edgerouter as the next-hop. Any Changes in the IGP topology will not be echoed externally. Remember the Carpenters rule, Measure twice and cut once. For us that's test twice and then deploy. -Ejay -----Original Message----- From: Anders Lowinger [mailto:anders.lowinger@xelerated.com] Sent: Friday, December 20, 2002 7:58 AM To: Stephen Sprunk Cc: Ejay Hire; David Scott Olverson; nanog(a)merit.edu Subject: Re: Using link congestion to control routing updates Stephen Sprunk wrote: > Opposite problem -- he wants to delay routing updates if the link is full. > EIGRP by default won't use more than 25/50% (I forget) of link bw, for > instance, but I'm not aware of any intentional features in other IGPs to do > this. Both OSPF and ISIS in Cisco's have pacing, ie they will not flood LSAs/LSPs over a certain configurable limit. Not sure about other platforms.. -A

2 1

RE: Using link congestion to control routing updates
by Ejay Hire 20 Dec '02

20 Dec '02

IIRC, and I may be wrong, either IS-IS or CLNS (can't remember which) can look at congestion, and EIGRP can look at load if you tweak the K parameters. -Ejay -----Original Message----- From: David Scott Olverson [mailto:olverson@fas.harvard.edu] Sent: Thursday, December 19, 2002 11:10 AM To: nanog(a)merit.edu Subject: Using link congestion to control routing updates Hello all, I was wondering if anyone was aware of a way to use the congestion of a network link to control the routing update. For example if I have a very small link that gets congested, I may want the router to withhold a routing update until link congestion falls below a certain threshold like 60% of bandwidth. Is anyone aware of anything like this available today or a technique that might accomplish something similar? You can contact me off list if this topic isn't germane. Thanks for your help, Dave Olverson

6 5

The Cidr Report
by cidr-report＠potaroo.net 20 Dec '02

20 Dec '02

This report has been generated at Fri Dec 20 21:48:05 2002 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-12-02 116860 84869 14-12-02 117040 84854 15-12-02 117512 84906 16-12-02 117508 84871 17-12-02 117485 84596 18-12-02 116531 84555 19-12-02 116615 84511 20-12-02 116819 84486 AS Summary 14204 Number of ASes in routing system 5600 Number of ASes announcing only one prefix 1622 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73048064 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20Dec02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 116934 84523 32411 27.7% All ASes AS3908 1167 685 482 41.3% SUPERNETASBLK SuperNet, Inc. AS701 1622 1205 417 25.7% ALTERNET-AS UUNET Technologies, Inc. AS7018 1425 1029 396 27.8% ATT-INTERNET4 AT&T WorldNet Services AS18566 393 5 388 98.7% COVAD Covad Communications AS7843 624 279 345 55.3% ADELPHIA-AS Adelphia Corp. AS4323 530 187 343 64.7% TW-COMM Time Warner Communications, Inc. AS1221 1152 835 317 27.5% ASN-TELSTRA Telstra Pty Ltd AS6197 453 149 304 67.1% BATI-ATL BellSouth Network Solutions, Inc AS6347 359 85 274 76.3% DIAMOND SAVVIS Communications Corporation AS1239 948 676 272 28.7% SPRINTLINK Sprint AS4355 403 132 271 67.2% ERMS-EARTHLNK EARTHLINK, INC AS22927 289 22 267 92.4% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS7046 579 313 266 45.9% UUNET-CUSTOMER UUNET Technologies, Inc. AS705 431 192 239 55.5% ASN-ALTERNET UUNET Technologies, Inc. AS4814 249 15 234 94.0% CHINANET-BEIJING-AP China Telecom (Group) AS1 664 441 223 33.6% GNTY-1 Genuity AS6198 421 201 220 52.3% BATI-MIA BellSouth Network Solutions, Inc AS17676 230 29 201 87.4% GIGAINFRA XTAGE CORPORATION AS22291 226 29 197 87.2% CHARTER-LA Charter Communications AS690 513 319 194 37.8% MERIT-AS-27 Merit Network Inc. AS6140 314 121 193 61.5% IMPSAT-USA ImpSat AS4134 293 106 187 63.8% ERX-CHINALINK Data Communications Bureau AS4151 323 141 182 56.3% USDA-1 USDA AS209 519 338 181 34.9% ASN-QWEST Qwest AS852 622 442 180 28.9% ASN852 Telus Advanced Communications AS2048 262 88 174 66.4% LANET-1 State of Louisiana AS6327 184 33 151 82.1% SHAWFIBER Shaw Fiberlink Limited AS2386 370 225 145 39.2% INS-AS AT&T Data Communications Services AS17557 315 173 142 45.1% PKTELECOM-AS-AP Pakistan Telecom AS2686 225 87 138 61.3% AS2686 AT&T Global Network Services - EMEA Total 16105 8582 7523 46.7% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Cisco IOS EIGRP Network DoS
by James-lists 20 Dec '02

20 Dec '02

----- Original Message ----- From: "FX" <fx(a)phenoelit.de> To: <bugtraq(a)securityfocus.com>; <darklab(a)darklab.org> Sent: Thursday, December 19, 2002 10:06 AM Subject: Cisco IOS EIGRP Network DoS Hi there, please find attached an advisory about an issue with the Cisco IOS Enhanced IGRP implementation that can be used to cause a network segment wide denial of service condition. Regards FX -- FX <fx(a)phenoelit.de> Phenoelit (http://www.phenoelit.de) 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564 Attached text moved here: Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 +++-> [ Title ] Cisco Systems IOS EIGRP Network Denial of Service [ Authors ] FX <fx(a)phenoelit.de> Phenoelit Group (http://www.phenoelit.de) Advisory http://www.phenoelit.de/stuff/CiscoEIGRP.txt [ Affected Products ] Cisco IOS Tested on: IOS 11.3 IOS 12.0(19) IOS 12.2 Cisco Bug ID: <not assigned> CERT Vu ID: <not assinged> [ Vendor communication ] 10/08/02 Initial Notification, gaus(a)cisco.com 10/08/02 - 11/14/02 Communication with gaus(a)cisco.com about the issue, fixes and timelines. 12/18/02 Final advisory going public as coordinated release *Note-Initial notification by phenoelit includes a cc to cert(a)cert.org by default [ Overview ] Cisco Systems IOS is vulnerable to a denial-of-service attack using Cisco's proprietary routing protocol Enhanced IGRP (EIGRP). When flooding a Cisco router with spoofed EIGRP neighbor announcements, the router will cause an Address Resultion Protocol (ARP) storm on the network segment while trying to find the MAC addresses for the newly discovered neighbors, effectively using all available bandwidth. [ Description ] EIGRP uses automatic discovery of neighboring routers. An EIGRP router announces it's existence via multicast on the enabled interfaces. If two routers discover each other, they try to exchange information about the current topology in unicast. On Ethernet, both sides need to obtain the MAC address of the other router. When generating EIGRP neighbor announcements with random source IP addresses and flooding a Cisco router (unicast, only possible in 11.x) or an entire network (multicast), all receiving Cisco routers will try to contact the sender(s). The source IP addresses have to be in the subnet(s) enabled via the "network" statement in the config of the victim router. A bug in Cisco IOS causes the router to continiously try to obtain the MAC address of the sender. This process does not time out unless the EIGRP neighbor holdtimer expires. This value is supplied by the sender of the neighbor announcement and has a maximum of over 18 hours. Multiple neighbor announcements with not existing source IP addresses will cause the router to use all available CPU power and bandwidth on the segment for ARP request - creating a segment-wide denial of service condition. The possible use of IP multicast poses a high risk for larger corporate networks using EIGRP. Cisco IOS versions below 12.0 also accept EIGRP neighbor announcements as unicast packets, which makes the attack possible via the Internet. [ Example ] None provided at this time. [ Solution ] Implement EIGRP authentication using MD5 hashes - which should have been done in the first place. Where MD5 can not be implemented, use extended access lists to match expected neighbors. The obvious workaround of using fixed neighbor entries in the configuration does not work due to another bug in IOS that makes it ignore the command (Cisco Bug ID CSCdv19648). [ end of file ($Revision: 1.5 $) ] Cisco comments on Bug traq: -----BEGIN PGP SIGNED MESSAGE----- We can confirm the statement made by FX from Phenoelit in his message "Cisco IOS EIGRP Network DoS" posted on 2002-Dec-19. The EIGRP implementation in all versions of IOS is vulnerable to a denial of service if it receives a flood of neighbor announcements. EIGRP is a Ciscos' extension of IGP routing protocol used to propagate routing information in internal network environments. The workaround for this issue is to apply MD5 authentication that will permit the receipt of EIGRP packets only from authorized hosts. You can find an example of how to configure MD5 authentication for EIGRP at the following URL (possibly wrapped): http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/ np1_c/1cprt1/1ceigrp.htm#xtocid18 If you are using EIGRP in the unicast mode then you can mitigate this issue by placing appropriate ACL which will block all EIGRP packets from illegitimate hosts. In the following example the EIGRP neighbor has IP address of 10.0.0.2 and the local router has address 10.0.0.1. Router#config t Router(config)#access-list 111 permit eigrp host 10.0.0.2 host 10.0.0.1 Router(config)#access-list 111 deny eigrp any host 10.0.0.1 The previous example will permit all EIGRP packet throughout the router and into the rest of the network. If you want to block these packets as well then use the following commands instead of the previous example: Router#config t Router(config)#access-list 111 permit eigrp host 10.0.0.2 host 10.0.0.1 Router(config)#access-list 111 deny eigrp any any An ACL will not be effective if you are using the default multicast mode of EIGRP neighbor discovery. However, multicast packets should not be propagated through the Internet so an attacker must be on the same local network segment as the target router in order to exploit this issue with multicast advertisements. The issue with EIGRP neighbor command FX is referring to is assigned Cisco Bug ID CSCdv19648 and is visible to all registered users through Cisco's Bug Toolkit at http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl. At the time of writing this notice Cisco PSIRT does not have a current estimate on when the fix will be available. Gaus -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.3 iQEVAwUBPgIFTw/VLJ+budTTAQE7yggAiDxmo8MFD9rULZAG1PKcnn0wfHungE1a dMfLN1oUaW7LYaMv+PJYkCvSO4t8oJlmQE9MXV3Q9VgLu9FHQDul3tzpOXMCmRB9 19H0XThGXzj7hDUbOrqgYXgDKQucarXg6yZ0nIuxNhEkl4XsnDohaMIkH7ynV/mY mQ2qIehPw6aus2plvGDKDYZVTbClHk1qjTWhL3AgFqbVH9zkOHppLF47kP/adRlh GeloUfxwMAJP2w4/MXObHMr9ELY+8mku/Fi0IBMfnZtS/VprZQZuvYQQmov7uYMV VkvCoI/mkjkJGlTZyxHGtIbQGelC/eub+r4SiCxtH6APiFWaYWnwVw== =o5+g -----END PGP SIGNATURE----- ============== Damir Rajnovic <psirt(a)cisco.com>, PSIRT Incident Manager, Cisco Systems <http://www.cisco.com/go/psirt> Telephone: +44 7715 546 033 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB ============== There is no insolvable problems. The question is can you accept the solution?

2 1

Using link congestion to control routing updates
by David Scott Olverson 19 Dec '02

19 Dec '02

Hello all, I was wondering if anyone was aware of a way to use the congestion of a network link to control the routing update. For example if I have a very small link that gets congested, I may want the router to withhold a routing update until link congestion falls below a certain threshold like 60% of bandwidth. Is anyone aware of anything like this available today or a technique that might accomplish something similar? You can contact me off list if this topic isn't germane. Thanks for your help, Dave Olverson

3 2

Re: Cogent Thrashing Box: results
by Mike (meuon) Harrison 19 Dec '02

19 Dec '02

On Thu, 19 Dec 2002, ______________ wrote: > On Thu, 19 Dec 2002, Mike (meuon) Harrison wrote: > > > In the middle of all of this talk re: Cogent and such, > > they apparantly spent some $$$ somewhere and made our > > test connection a whole lot better. > > This is "better"? > > 3 so-1-0-0.mp2.NewYork1.Level3.net (212.187.128.153) 73.894 ms 73.798 ms 73.850 ms > 4 gigabitethernet5-2.core1.NewYork1.Level3.net (64.159.17.165) 74.199 ms 75.522 ms 74.397 ms > 5 204.6.134.162 (204.6.134.162) 962.177 ms 959.560 ms 960.519 ms > 6 p5-0.br01.jfk01.atlas.psi.net (154.54.1.197) 3806.177 ms 3814.665 ms 3836.955 ms > 7 p14-0.core01.jfk01.atlas.cogentco.com (154.54.1.21) 3830.980 ms 3813.222 ms 3811.389 ms > 8 p13-0.core02.jfk02.atlas.cogentco.com (66.28.4.121) 3770.229 ms 3815.093 ms 3839.036 ms > 9 p14-0.core01.phl01.atlas.cogentco.com (66.28.4.2) 3814.309 ms 3823.906 ms 3846.192 ms > 10 g0-2.na21.b003003-3.phl01.atlas.cogentco.com (66.250.13.190) 3847.378 ms 3833.999 ms 3817.632 ms > 11 Covista.demarc.cogentco.com (66.28.30.50) 3778.689 ms 3782.988 ms 3820.756 ms > 12 66.18.32.130 (66.18.32.130) 3832.508 ms 3835.835 ms 3851.331 ms > 13 66.28.38.150 (66.28.38.150) 3856.752 ms 3853.476 ms 3856.500 ms It has sure failed under load today. Killing it.. 'Nuff said. Lots of similiar traces on the MTR (matts traceroute) from the system as well. the resulting tests from today are crudely presented at: http://speedy.higherbandwidth.net/resultsall.cgi Click on the IP address to see the trace.. An amazing link is: http://speedy.higherbandwidth.net/results2.cgi?ip=209.244.4.106 Sure.. the web test is not perfect.. but that is a LOT of variety in results. Like this one: http://speedy.higherbandwidth.net/results2.cgi?ip=12.170.34.5 Thanks folks..

1 0

Anyone seeing issue with ATT this morning?
by Flint Barber 19 Dec '02

19 Dec '02

Hearing a lot of complaints this morning from ATT Cable subscribers.. anyone have an info?? -flint

1 0