May 2001 - Test - lists.nanog.org

vBNS MSDP
by Marshall Eubanks 08 May '01

08 May '01

Does anyone have a contact e-mail or number for the vBNS NOC ? Sometime between Tue May 8 16:55:20 EDT and Tue May 8 21:10:13 EDT we stopped getting MSDP SA's from them, and thus from Abilene. There seems to be no indication of problems on our end. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme(a)on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/

1 0

Re: black hat .cn networks
by Roger Marquis 08 May '01

08 May '01

Walter Prue <prue(a)ISI.EDU> wrote: > The folks in the US who counterattack might be well advised to > reconsider doing so. I would imagine that traffic from the US would be > closely monitored. Any new hacking tricks that these counterattacks > might use would then be recorded and analyzed. These techniques could > then be used by them to further attack the US. Does anyone know if these China scares are for real? The probability they are simply Pentagon/Administration propaganda seems too high to discount. I ask because we've seen no increase in the (already substantial) number of scans from CN/KR/HK/... netblocks. Does any hard evidence exist? -- Roger Marquis Roble Systems Consulting http://www.roble.com/

15 16

Re: black hat .cn networks
by Justin Hinderliter 08 May '01

08 May '01

RE: black hat .cn networksNo, and I stated as much in my original post, despite the angst. One of the attacks planted worm shich in turn planted a series of indexes claiming to be part of the Chinese offensive. It affects HTML and ASP files. The original connection attempt on that box came from a Czechoslovakian host, and the tftp host that the worm grabbed the scripts from was actually in Canada. Othere hosts that were attacked in the same timeframe came from Mapquest, rutgers,edu, and a non-DNS-qualified APNIC host. This doesn't "prove" or disprove anything. Could be Czechs, could be Americans, could be Chinese, could be anyone. I'm not necessarily a proponent of blocking netblocks or blackholing them from a routing perspective on a large network, but I am more than happy to block the offending hosts personally from my internal networks, and do. The tftp server that was serving up the scripts for the NT worm was 205.205.117.6 FYI. The linux exploit (different hosts and exploits altogether from the NT hacks, obviously) seemed to have gotten in on htdig package (3.1.5-6mdk), not apache as I originally expected. I haven't found the script/kit yet, but I did find out that something fully opened up UDP port 4265. Since she's unplugged, I can't grok what was listening on that port at the moment. I'm highly tempted to try to hook it back up after some tweaking and let it run as a honeypot for a few days or until I can nail down what is lurking on there and watch how they're doing their work & see if I can grab more goods on who they are and where their backdoor connects to. More in a bit. Justin Hinderliter ----- Original Message ----- From: Paul Lantinga To: 'Justin Hinderliter' Cc: nanog(a)merit.edu Sent: Tuesday, May 08, 2001 12:39 AM Subject: RE: black hat .cn networks >> -----Original Message----- >> From: Justin Hinderliter >> > The past week i've seen attacks increase 5-fold, mostly >> 111/udp attacks >[snip] >Justin, et al, do you have any *proof* that these attacks are coming from Chinese attackers on Chinese >machines? If so, look for commonalities amongst the attacks such as common netblocks etc. If not, the hype >could probably be routed into the round file. Attacks happen all the time to the good and the bad. We still need >good documentation and due diligence. Until then, join "North America Nonblocking Oriental Groups" >-Paul Lantinga >-- >Pretty much guaranteed that these are solely my opinions

1 0

RE: black hat .cn networks
by Dan Hollis 08 May '01

08 May '01

On Tue, 8 May 2001, Wing Wong wrote: > On Mon, 7 May 2001, Dan Hollis wrote: > > On Tue, 8 May 2001, Paul Lantinga wrote: > > > Justin, et al, do you have any *proof* that these attacks are coming from > > > Chinese attackers on Chinese machines? > > We may never know since mainland china admins never respond to abuse mails. > Ever consider the possibility that the admins in question don't understand > English? It'd be like if someone sends you a Big5 or SJIS encoded message > complaining about spam or cracks and all you see is binary jiberish on > your screen. > Even romanized communications would be difficult to understand. I can use babelfish, why can't they? Yes, babelfish is less than perfect, but I can usually grok the gist of an email. And if babelfish isnt good enough, there's others. FWIW I've had a chinese friend in canada send a BIG5 email once and the same -- no response. -Dan

8 10

RE: Instant chats and central servers
by Cerqua, Toby 08 May '01

08 May '01

On a partially related topic, I've recently run across a service that tries to put all the instant messenging services together in one package. Check out Jabber.com; it's still under development, but it seems like it may be a good idea in the making. Redundancy in messengers may be useful, but the program's still a teeny bit buggy. On 5/8/2001 at 11:35:27 -0700, Sean Donelan wroteified: > > A question (and a test to see if I'm still subscribed) > > The various instant messenging services, such as AIM, ICQ, Microsoft, > Yahoo, other Messenger uses a central server to manage "presence". > > No central server appears to mean no instant messages, am I correct? > > What does this have to do with NANOG, apparently it is becoming more > common for backbone NOC folks to communicate with their friends in > other NOCs via one of these instant chat programs. I didn't realize > how common it was until I was informed about it last month when AOL/AIM > had difficulties. This month Yahoo Messenger had power difficulties, > which disrupted their central servers. > > If folks are using this these services for real-time communications, > should we be trying to improve their reliability? Or is this just a > "feature" of how presence services work. > > -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

1 0

Re: ISP Filter Policies--Effect is what?
by John Fraizer 08 May '01

08 May '01

Christian, You can be damned skippy that if we had a legacy B, I wouldn't be returning it any time soon. It's the part about NOT paying arin fees that makes it most attractive. If ARIN had a policy like "If you return your legacy B and only need a /19, /18, 17, we'll simply trade -- no fees -- no harm -- no foul" I think that more people would be returning unused address space. As it stands, there is really no tangible incentive and VERY tangible penalties for doing so. --- John Fraizer EnterZone, Inc On Tue, 8 May 2001, Christian Kratzer wrote: > > > > Stephen, you neglected to look at the big picture. The "organization" has > > the /16 but has sites spread out all over the planet and has assigned > > /24's to them. Additionally, they connect into the global net via diverse > > providers. > > why do they have a /16 then ??? > > As good net citicens they should get their /whatever they need at each > location from their respective providers. > > If they can't even afford to buy a decent backbone to connect their > sites they have no need whatsoever for their own /16. > > Please rtfm on rf1918 addressing for internal use > > People like that are polluting the global routing tables with unnecessar > yannouncements.... > > Greetings > Christian > > -- > TopLink Internet Services GmbH ck(a)171.2.195.in-addr.arpa > Christian Kratzer http://www.toplink.net/ > Phone: +49 7032 2701-0 > Fax: +49 7032 2701-19 FreeBSD spoken here! >

1 0

ISP Filter Policies--Effect is what?
by Murphy, Brennan 08 May '01

08 May '01

I'm trying to figure out to what degree the existence of these policies should be accounted for in a BGP design which includes sites around the world. I've read through a few of the threads having to do with Verio's Filtering Policy. And I read the policies listed here: http://www.nanog.org/filter.html Consider the following theoretical scenario: Site BGP Advertisement to ISP Amsterdam 169.61.201.0/24 AMSISP Austin 169.61.111.0/24 Genuity & Internap SanFran 169.61.119.0/24 Genuity & Internap Tokyo 169.61.202.0/24 TOKISP Sydney 169.61.156.0/24 SYDISP 1. Since Verio says they would not accept /24 nets drawn from Class B space, I assume this means that they don't insert a /16 into their tables so that the /24 nets appear to Verio customers as unreachable. In this case, a design that wants to extend connectivity to verio customers (and any other ISP with similar policies) must include a /16 advertisement from at least one of the sites. 2. Suppose a customer of a Verio-like ISP, wishes to go to ftp. foo.org. DNS returns 169.61.201.155 (in amsterdam, see above). Verio passes the traffic to the neighbor it received the /16 advertisement from. At this point, the best thing that could happen is if that neighbor has the /16 and /24 networks in its route table, right? That means, a path exists for that user to the amsterdam server and the only problem with routing to Amsterdam is that Verio possibly handed the traffic to a sub-optimal neighbor. Am I understanding this issue correctly? I'm new to BGP. I've tried to get a handle on this issue on my own and by working with Genuity, Internap and Cisco. No disrespect to those companies but each of them had this vague memory of Verio's policy but couldnt really tell me in plain language how it might affect the above scenario. Obviously, I wasn't talking to chief engineers. Someone from the CCIE mailing list suggested I browse the archives of this list, which I did. But I didnt find a clear enough answer to my questions--perhaps because they are too basic to be discussed here or I'm not good at using this lists archive search engine. Either way, any guidance on the above scenario is greatly appreciated. -BM

7 7

Re: Instant chats and central servers
by Dave Israel 08 May '01

08 May '01

Sean, There's a bunch of machines for AIM, spread out across the AOLosphere... there is no one server that will take down the service. (That's for the Oscar stuff; the TOC stuff, which the open messengers use, is also clustered in the back end, but there is that One Server You Must Talk To(tm).) I imagine the other services are similar. -Dave On 5/8/2001 at 11:35:27 -0700, Sean Donelan said: > > A question (and a test to see if I'm still subscribed) > > The various instant messenging services, such as AIM, ICQ, Microsoft, > Yahoo, other Messenger uses a central server to manage "presence". > > No central server appears to mean no instant messages, am I correct? > > What does this have to do with NANOG, apparently it is becoming more > common for backbone NOC folks to communicate with their friends in > other NOCs via one of these instant chat programs. I didn't realize > how common it was until I was informed about it last month when AOL/AIM > had difficulties. This month Yahoo Messenger had power difficulties, > which disrupted their central servers. > > If folks are using this these services for real-time communications, > should we be trying to improve their reliability? Or is this just a > "feature" of how presence services work. > > -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

1 0

RE: Cisco DS3 performance specifications
by David Sinn 08 May '01

08 May '01

Any multiport cards on the GSR can have a port blocking problem if one port is oversubscribed. This is regardless of engine, or memory on that card (though memory gives you more breathing room). By default there are no queue limits for a given port on a multiport GSR card. So if you have a port that is in a consistent state of over subscription, and thus packets are backing up in the local TX buffer, that port can eat all of the memory and starve the other ports off. It does not matter what processor is doing the switching (and regardless, the processor *for the most part* does not touch any of the traffic in the outbound direction anyways). One should be cognizant that E0's have around 400kpps of forwarding performance, E1 ~700, E2 up to 4Mpps, and E4 up to 25Mpps, which is shared among the ports on the card, so plan accordingly for the traffic patterns you are expecting to se). The most simple fix for this is to set a hard TX queue limit for each port. Thus any one port can only buffer x number of packets, and not starve off the other ports (things can be less then optimal picking x since there are at least four pools for a packet to sit in, and you don't get to define a number for each, just a sum). This also insures you aren't holding packet too terribly long (TCP should be doing it's job anyways...). WRED is another manner, and it is arguable if it is any more intelligent then setting a hard limit to WHAT packet gets dropped. WRED requires more configuration, and is a little more graceful since it will start dropping sooner. Hopefully this will make your traffic curve closer to line rate then the saw-tooth you would expect to see with TX queue limits. David -----Original Message----- From: Neil J. McRae [mailto:neil@DOMINO.ORG] Sent: Tuesday, May 08, 2001 8:45 AM To: Bill Thomas Cc: nanog(a)merit.edu Subject: Re: Cisco DS3 performance specifications The cards are engine 0 and there is no hardware switching - I've seen issues on this card - one port has heavy load and the other ports start dropping packets, WRED helped with this but not by much. I'd be interested in your tests. Regards, Neil. > > To any and all in earshot, > > I am engaged in setting up a sytems level test lab for the purposes of > measuring > among other items, DS3 performance and interoperability between Cisco 12000 > series > and several new and emerging edge switch devices. > > In order to set a baseline for performance expectations, I am attempting to > gather > historical data on earlier testing. > > The nasty rumor I am hearing is that Cisco DS3 interfaces at best deliver 50 > - 60 % throughput. > This is supposedly attributed to the way they apply their Traffic Shaping > and Policing at the port level. > > I need to obtain documentation that either validates this, or presents the > correct information. > > Many of the edge devices involved in the testing, support high levels of > throughput > even at the channelized subrate. An increased need to buffer the data, to > compensate > for a potential mismatch in bandwidth capabilities, would just add to the > latency > and sour the testing. > > Any and all information is valued and appreciated. > > > > > > > > >

1 0

RE: ISP Filter Policies--Effect is what?
by Murphy, Brennan 08 May '01

08 May '01

>> Stephen, you neglected to look at the big picture. The "organization" has >>the /16 but has sites spread out all over the planet and has assigned >> /24's to them. Additionally, they connect into the global net via diverse >> providers. >Ah, I got -snip- happy there :) in that case I would question the logic of >being given a large address block only to break it into pieces all over >the world. >I'd wonder why they dont take address space from a regional provider - if >its only /24 it cant be that mission critical for bgp and multihoming... The /16 was acquired way back when. Until now, its been used primarily for internal addressing (ie, no NAT). But now the internet presence is growing and the distributed nature of the sites plus the multiple providers forces us to use /24s. Making use of a regional provider's address space may be best for us in Europe and Asia. The North American sites all have the same providers... ...so, we could advertise /24 to these providers and have them advertise /16. Then the regional providers could give us some Class C /24s and our Distributed Director could match a particular user with the nearest server farm. I think this is probably the best approach.

1 0