- Test - lists.nanog.org

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

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

08 May '01

On Tue, May 08, 2001, Stephen J. Wilcox wrote: > >if you have a /16 why would it be broken down to /24? i would assume the >> only reason you advertise /24 is because that is the size of your >> assignment from the NIC, in which case you cannot advertise the /16. > if you do own the /16 then yes of course you can advertise it. >Not necessarily. I've been in a position where I've had $LARGEBLOCK >and I've had to break it into smaller chunks for per-POP customers. >The trick there is trying to handle your network being split down >the middle and still have traffic flowing to each POP right. >The only real way to do that is to split the /16 up into smaller >per-POP chunks and announce them seperately. >Yes, then you run into provider filtering blackholing you. >So, the comprimise is to announce the /16 and the /24s that make >it up, and bite the bullet. I think this is the essence of the issue for this sitation. The desire is to have the traffic routed properly to the intl POPs. The /24s would be spread out geographically....all over. Furthermore, different providers are involved....one in Europe, one in Asia, etc. The address space I provided was theoretical...although in the real world example, the full /16 is owned by us. I am still reading through the responses but wanted to clarify the above. Also, one of the options being discussed is to use provider supplied Class C /24 space from providers in Europe and Asia and let our DNS algorithim take care of sending users to the right place. Basically, I've been told that the scenario would be far easier to work with if only 1 provider was supplying circuits at all of the locations around the world. Then they could advertise the full /16 and we would advertise the appropriate /24s from the particular site hosting them. Thanks for everyone's responses...most helpful!

1 0

Sorry
by Omachonu Ogali 08 May '01

08 May '01

Er, sorry, last e-mail was a mistake, ignore. -- Omachonu Ogali missnglnk(a)informationwave.net http://www.informationwave.net

1 0

RE: NYC Colo
by Omachonu Ogali 08 May '01

08 May '01

Yeah, no problem, I can secure two racks for you, either you or Nancy can give me a call later on today and I can schedule a tour, also when you have free time, check out: http://www.forked.com/test/pc.html. -- Omachonu Ogali missnglnk(a)informationwave.net http://www.informationwave.net

1 0

RE: black hat .cn networks
by Roeland Meyer 08 May '01

08 May '01

Thank you Franklin, for clarifying many things. Language is indeed a big issue for non-indo-europeans. Basically, anyone that uses a non-romance script (cyrillic, chinese, hiragana/katakana, arabic, cuniform, etc). The problem is that most folks don't realize that this goes both ways. We all face the same barriers in the other direction. Information gets distorted both ways. Add to this, the normal human tendency to speculate [negatively] in the absence of data and there is a huge potential for misunderstandings and myth-creation. The real problem is that we have to tame/banish these crackers on all sides. Hardening our own systems is not enough. We have to banish the vandals as well. Destroying someone else's property/hard work, simply because the opportunity presents itself, is/should be considered highly unacceptable/uncivilized behavior and punished accordingly, by every civilized person. -- ROELAND M.J. MEYER Managing Director Morgan Hill Software Company, Inc. TEL: +001 925 373 3954 FAX: +001 925 373 9781 http://www.mhsc.com mailto: rmeyer(a)mhsc.com > From: Franklin Lian [mailto:Franklin.Lian@globalone.net] > Sent: Tuesday, May 08, 2001 9:28 AM > > I found a myth on this list that hacking a computer system is a > death sentence. I really don't know where and when this mythin is > spreading on the Internet. > > I guess the myth came from a case that a hacker was executed, maybe > two years ago, and he was the first hacker sent on trial. I read > that news couple of years ago both in English and Chinese. The > hacker actually was executed for stealing millions of dollars from > a bank he used work for, NOT for HACKING. According to Chinese law, > any criminal commited to crime that evolves more than $100,000 > (the exact number might be wrong) can be sentenced to death. > > However, nobody noticed the crime behind of hacking but only hacking > itself.

1 0

RE: black hat .cn networks
by Rowland, Alan D 08 May '01

08 May '01

Haven't seen it brought up yet but since hacking is alleged to be a capital crime in China perhaps the non-response is the self-protection gene kicking in. :O Just my 2¢. -Al -----Original Message----- From: David Lesher [mailto:wb8foz@nrk.com] Sent: Tuesday, May 08, 2001 7:12 AM To: nanog(a)merit.edu Subject: Re: black hat .cn networks Unnamed Administration sources reported that Paul Lantinga said: > > > Why not decide on a workable message and have it translated by a competent > Chinese translator first? I'm sorry, but from my admittedly limited experience in that part of the world, I find it hard to believe messages are discarded unread for that reason. Too many people there read and speak English, especially those educated enough to be sysadms. They may not do so well enough to anchor the BBC World Service broadcast, but... I welcome enlightenment on this from people with more direct knowledge. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0