- NANOG - lists.nanog.org

Survey on IBGP persistent route oscillation problem
by Susan Hares 21 Mar '02

21 Mar '02

IBGP and Persistent Route Oscillation The Draft BGP Persistent Route Oscillation draft describes route oscillation occurring in networks today. This draft can be obtained at: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-01.txt In order to evaluate how significant a problem the route oscillation is, I would like to get input from network operators. If you could take a few moments and fill out this survey, it would help in determining the severity of the problems. Any information solicited by this survey will remain private. Summaries of this information will be sent to this list and the IDR working list. Sue Hares IDR co-chair ---------------------------------------- 1) Contact information: Name: Company: Position/Responsibility: Email address: Phone number: 2 What type of network do you run (select one of the choices)? a) Enterprise network b) Service provider Tier 1 c) Service provider Tier 2 d) Service provider - other e) Exchange point f) Specialized service provider g) Other (please specify) 3) Have you seen persistent route oscillation in your network? What type of route oscillation? a) Experiencing Type I MED churn with Route Reflectors? b) Experiencing Type I MED churn with AS Confederations c) Experiencing Type II MED churn with 2 Tiers of Route Reflectors? d) Experiencing Type II MED church with AS Confederations? What steps have you taken to fix this problem? 4) If you run IBGP, please answer the questions below. (If you don't run IBGP, then the whole survey is irrelevant to you) a) How many IBGP peers in your network? How many of routes are carried in IBGP? b) Do you use MED? Are you transit for other Ass? c) Do you use Router Reflectors? How many levels? d) Do you use AS confederations? How many AS in confederations? 5) If you run EBGP, How many EBGP peers do you have? How many other Autonomous Systems (ASs) do you peer with? Do you use MED or AS Confederations? [If you don't run EBGP, then the whole survey is irrelevant to you)

2 2

csu /dsu
by c johnson 21 Mar '02

21 Mar '02

what are the primary functions of a csu / dsu? thanks. _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

2 2

Re: csu /dsu
by rs＠seastrom.com 21 Mar '02

21 Mar '02

"c johnson" <cucme61(a)hotmail.com> writes: > what are the primary functions of a csu / dsu? http://www.tscnet.com/faq/internet/internetfaq006.html ---rob

1 0

RE: csu /dsu
by Jeff Harper 21 Mar '02

21 Mar '02

http://www.commweb.com/article/COM20010807S0013/2 > -----Original Message----- > From: c johnson [mailto:cucme61@hotmail.com] > Sent: Thursday, March 21, 2002 7:46 AM > To: nanog(a)merit.edu > Subject: csu /dsu > > > > what are the primary functions of a csu / dsu? > > thanks. > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com >

1 0

ICMP filters again
by Christopher E. Brown 21 Mar '02

21 Mar '02

Is it just me, or are the Tripod member sited filtering type 3 ICMP again? (Think < 1500 octet MTU links and DF/FN)

4 3

Re: CEOlink
by Eric Brandwine 21 Mar '02

21 Mar '02

>>>>> "b" == batz <batsy(a)vapour.net> writes: b> This is a complicated issue. Maybe I'm off base, but Nanog is actually b> really good. Combined with Bugtraq, Incidents, and a virus alert service, b> Nanog plays a vital role. Their only limitation is that they are on the b> Internet. :) Exactly! That's why we need control plane separation. Run SNMP, SSH, telnet, and SNTP (Simple NANOG Transport Protocol) across the management network, so we're sure we have them when we need them. Actually, NANOG does great. Especially during Sept 11, information was disseminated, help was offered and accepted, and except for a couple of idiotic flames, the SNR was high. ARPA designed the thing to withstand nuclear blasts, and while this was not nuclear, it stood up well. ericb -- Eric Brandwine | Apart from hydrogen, the most common thing in the UUNetwork Security | universe is stupidity. ericb(a)uu.net | +1 703 886 6038 | - Harlan Ellison Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

6 6

gTLD Informational Message
by Verd, Brad 20 Mar '02

20 Mar '02

This is an Informational Message to the internet community: VeriSign Global Registry Services will be changing the IP address for M.gtld-servers.net in the authoritative NS set for com/net/org. The change will be reflected in zone serial # 2002032100 The new set of servers authoritative for these TLDs will be: A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 J.GTLD-SERVERS.NET. 2D IN A 210.132.100.101 K.GTLD-SERVERS.NET. 2D IN A 213.177.194.5 E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 This will not require any change to root.cache file and both the new and old m.gtld-servers.net will provide answers for com, net, and org in parallel to accommodate the zones TTL's. -------------------------------------- Brad Verd Operations Manager Resolution Systems VeriSign Global Registry Services Email - bverd(a)verisign.com ---------------------------------------

1 0

gTLD Informational Message
by Brad Verd 20 Mar '02

20 Mar '02

This is an Informational Message to the internet community: VeriSign Global Registry Services will be changing the IP address for M.gtld-servers.net in the authoritative NS set for com/net/org. The change will be reflected in zone serial # 2002032100 The new set of servers authoritative for these TLDs will be: A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 J.GTLD-SERVERS.NET. 2D IN A 210.132.100.101 K.GTLD-SERVERS.NET. 2D IN A 213.177.194.5 E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 This will not require any change to root.cache file and both the new and old m.gtld-servers.net will provide answers for com, net, and org in parallel to accommodate the zones TTL's. -------------------------------------- Brad Verd Operations Manager Resolution Systems VeriSign Global Registry Services Email - bverd(a)verisign.com ---------------------------------------

1 0

Slash/Nanog Vote Results
by Allan Liska 20 Mar '02

20 Mar '02

Hello, This is a follow up with the results of the off-list votes that were sent to me about the level of interest in creating a slashdot style board to accompany the nanog list. 11 Votes total +8 -3 allan -- allan allan(a)allan.org http://www.allan.org

1 0

Re: Question re. SSH
by Eric Brandwine 20 Mar '02

20 Mar '02

>>>>> "ss" == Steve Sobol <sjsobol(a)JustThe.net> writes: ss> Apologies in advance for any operational content this may contain. ss> I have a customer who wants to get a static ip with his dialup. He ss> uses SSH extensively and plans to do X11 forwarding, and if he ss> gets disconnected and redials and gets another IP the previous ss> sessions would be inaccessible. ss> I can do static IP but I want to try to save the guy a couple ss> bucks. :) ss> Would a static IP be required to make sure he doesn't lose those ss> X11 sessions after a disconnect? Required, but not sufficient. The TCP stack on each side must remain up continuously. If his TCP stack resets and he redials, the first packet he gets from the far end will be met with an RST, and tear down the connection. The easiest way to do this is to put the modem on a system different from the SSH endpoint (router, NAT, FW, whatever). If you are using a NAT or FW in between, it's critical that the state/translation tables not be flushed when the dial interface goes down/up. Of course, if you're running TCP or ssh keepalives (or ssh2 rekeying), and that happens when the link is down, your connection will go away anyway. The proper way to do this is with an X analog of screen. VNC is one possibility. VNC is free, and this would not require a static IP. Then again, we're talking dialup here. Your customer should do this a couple of times before he gets dead set on it. Even with LBX and compression on the SSH session, X over dialup is unpleasant. ericb -- Eric Brandwine | The Windows NT philosophy always chooses ease - both UUNetwork Security | ease of use and ease of development - over security. ericb(a)uu.net | +1 703 886 6038 | - Bruce Schneier Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

1 0