- NANOG - lists.nanog.org

CAR
by Ken Yeo 19 Apr '02

19 Apr '02

Hi Nanog, Scenario: Transits -----(router A)Backbone(router B)----- Customers We applied Cisco CAR at the edge routers (B) in the Backbone to rate limit inbound and outbound traffics to/from Customers. If transmission rate is higher than the rate limit threshold, IP packets are being dropped by router B. How do we prevent the excess IP packets to consume the transit links and the Backbone? Here is my understanding: -For TCP traffics (HTTP, FTP), TCP senders will stop sending packets when the TCP windows threshold is reached. -For UDP based audio/video trafffics, if the applications use RTSP and H.323, RTCP/H.245 will signal the sender to slowdown the transmission if the receiver lost packets. Did I miss anything? How about UDP traffics that are not using RTSP/H.323? Thanks. Suan "Ken" Yeo Network Engineer Aurum Technology ken.yeo(a)aurumtechnology.com

3 6

Links between cabinets at commercial datacentre
by Andy Rabagliati 18 Apr '02

18 Apr '02

Folks, Wishing to set up an alternative peering point in our fair city, we have run into a problem with the data center administration. The data center prohibits direct cabling between clients cabinets, even if the clients agree. Our peering point is not in the data center, but is in the same building, and will necessitate data center clients separately running fibre to our room, and paying not only for installation but also monthly fees proportional to bandwidth carried. We are in South Africa, the monthly fees are related to wireline costs, even though the monopoly wireline provider, Telkom, is not involved. Without this rule, we would run one fibre between the datacenter and the peering point, and have peers in the datacenter hop on that fibre. While acknowledging that a data center may make any rules it likes, I am asking nanog how common this practice is. If people mail me offlist, I would be willing to summarise if there is enough interest. Cheers, Andy!

9 12

XO problems?
by Joe Blanchard 18 Apr '02

18 Apr '02

Anyone seeing issues with XO routing? /root# traceroute www.cisco.com traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets 1 132.237.9.3 (132.237.9.3) 3.510 ms 0.448 ms 0.443 ms 2 132.237.245.1 (132.237.245.1) 0.739 ms 0.791 ms 0.790 ms 3 67.104.110.113 (67.104.110.113) 1.826 ms 2.091 ms 1.860 ms 4 p4-3-0.MAR1.Fremont-CA.us.xo.net (207.88.80.9) 2.044 ms 2.088 ms 2.112 ms 5 p5-1-0-0.RAR1.SanJose-CA.us.xo.net (65.106.5.141) 2.438 ms 2.371 ms 2.368 ms 6 p1-0-0.RAR1.Washington-DC.us.xo.net (65.106.0.37) 82.448 ms 87.242 ms 82. 110 ms 7 p6-0-0.RAR2.NYC-NY.us.xo.net (65.106.0.1) 86.110 ms 86.055 ms 86.090 ms 8 ge5-0.dist1.hud-ny.us.xo.net (64.220.3.65) 86.688 ms 86.560 ms 86.586 ms 9 ge6-0.edge1.hud-ny.us.xo.net (64.220.3.83) 86.734 ms 86.715 ms 86.835 ms 10 * * * 11 * * agr1-loopback.NewYork.cw.net (206.24.194.101) 3100.552 ms 12 * * *

6 5

Re: BGP community settings in the real world
by Eric Oosting 18 Apr '02

18 Apr '02

On Thu, 18 Apr 2002, Adam Atkinson wrote: > > To what extent does setting communities on BGP routes work in the real > world? > > I can't help suspecting that in reality, routes would get aggregated, > or communities would be dropped or replaced, somewhere between source > and destination. Most of the utility of communities comes from either what your own policy does with them or what your providers policy does with them. For internally significant communities, they are are very useful for setting up simple but effective export policies ... An ISP might use different communities for routes they learned from a Customer vs. a peer vs. a transit provider vs. Internal, then set up a rule to send routes marked with customer, peer, transit, and internal communities to their customers, but only customer, and internal routes are sent to peers and transit providers. Communities are also useful if you have a service provider that has implemented a rich policy regarding acceptance of communities from customers. For instance, some providers have implemented communities that adjust the local pref the provider sets on the route, or determines if and how the route will be sent outside of the providers network at all to its peers, customers and/or transit providers. For example provider 1234 could use community 1234:120 to mean routes sent from customers to them should be accepted with local pref of 120, instead of the default 100, or that 1234:666 means to send the routes learned with community to customers of the provider only and not to send it to any peers or transit providers. In addition to this, your provider may be sending communities to you that will help you make better routing decisions ... for instance they may be marking routes that originated in a specific region (Say US:SouthEast) with a community that allows you to treat this route differently in your Atlanta, GA Data Center then in your Palo Alto, CA Data Center. The communities a provider accepts and or sends will vary from provider to provider so obviously check with yours for more information about this. So you are correct that there is a possibility of communities being removed or the route aggregated or whatever, but that is OK because the meaning of a community is usually targeted at a specific application where you can be sure your community is in effect, like within your own network or between you and your provider or customer. Eric Eric Oosting eoosting(a)sockeye.com office:781-693-7041 Network Engineer Network Eng and Operations Sockeye Networks

1 0

Réf. : anyone using teleglobe?
by Marc Rapoport 18 Apr '02

18 Apr '02

We have been using their transit for 2 years in France. We are currently upgrading from a DS3 to an OC3 port. Their connectivity is really good generally speaking, the main weakness (in Europe) being E-Bone connectivity. (That might solve when KPN & E-Bone will merge their networks soon,though). Another issue, they do not implement communities for BGP TE yet. Remembering the recent Genuity thread about having to manually register your prefixes , you don't have this kind of hassle with them, they use IRR information to build their filters. To comment a previous answer, they are a subsidiary of the incumbent Bell Canada, so an imminent bankruptcy is very unlikely. Marc. -------------------------------------------------------------------- Date: Tue, 16 Apr 2002 11:50:51 -0700 From: "matthew zeier" <matthew(a)velvet.org> Subject: anyone using teleglobe? I have a gigE from teleglobe due in any day. Is anyone using them for connectivity? Any comments? What's their routing look like? What should I expect if I'm dumping ~300Mbps at them? I'm trying to pre-determine if I'll run into any problems from my more "sensitive" customers. Thanks.

1 0

BGP community settings in the real world
by Adam Atkinson 18 Apr '02

18 Apr '02

To what extent does setting communities on BGP routes work in the real world? I can't help suspecting that in reality, routes would get aggregated, or communities would be dropped or replaced, somewhere between source and destination. -- Adam Atkinson, Damovo UK

2 1

Re: Links between cabinets at commercial datacentre
by Adam Herscher 18 Apr '02

18 Apr '02

On 17 Apr 2002, Paul Vixie wrote: > someone like exodus or qwest or at&t or uunet or abovenet would be very > likely to prevent their customers from directly cross-connecting. > mae-west (55 s market) won't allow it either. paix, equinix, switch and > data, and other "neutral colos" won't allow it to occur without a fee > but the fees are reasonable (unlike, say, the cross connect fees at > mae-west.) UUNet's never put up any roadblocks for me in crossconnecting between cabinets in their datacenters (2 cabinets belonging to different UUNet customers). They've done it quickly too -- here's the response from a UUNet engineer from the last time I asked: > > If this is NOT an Out-of-Band cross connect (POTS, ISDN, whatever) > > contacting your sales person will not be necessary. Are you simply > > attempting to join cabinets [X] and [Y] via a Cat5 connection??? If > > this is the case let me know what ports in the patch panels you want > > the cross connect terminated to and I can send the request to have > > this done today. Their quote for bringing in outside bandwidth (having a circuit punched down at the datacenter + crossconnected to a cabinet) was relatively little too -- something to the tune of $50/month iirc. At my request, they even allowed me to have a circuit run directly through their datacenter bypassing their equipment altogether. I flipped the bill for the UUNet-contracted outside vendor to do the cabling. >From what I've heard, Exodus is a bit more hell-bent on forcing customers to use Exodus (err cw) bandwidth, but even they obviously make exceptions for their larger customers (and perhaps those that threaten to walk?). > there's no answer to the question, as posed. "can you be more specific?" > I think the poster was inquiring as to common practice. ISPs will do whatever they can to make a buck. In some cases this could be forcing customers to use their own bandwidth by preventing crossconnecting within their datacenter. In other cases, it could be realizing that some customers require/value/will pay for such services. In cases where there is little or no competition, it certainly seems like the former would be more profitable (however disappointing). Regards, Adam

3 2

More on Telco/ISP practices in Africa..
by Adam Herscher 17 Apr '02

17 Apr '02

The recent thread related to an exchange point in South Africa reminded me of something I stumbled upon yesterday.. "The great African internet robbery" http://news.bbc.co.uk/hi/english/world/africa/newsid_1931000/1931120.stm I feel it's a rather ignorant article, primarily because it is written from a financial/social equality standpoint with no regard for anything technical. Nonetheless, it seems to have received quite the hype (thanks a lot /.): http://slashdot.org/articles/02/04/16/1235211.shtml?tid=95 I'm curious as to what the consensus is among US network operators..

1 0

references on non-central authority network protocols
by Patrick Thomas 17 Apr '02

17 Apr '02

Hello, I am looking for any and all research (and perhaps your comments), references, etc. regarding replacements for the TCP/IP protocol that do not require centralized authority structures (central authority to assign network numbers). Any links, comments, etc., appreciated. --PT

12 16

OT: Looking for BSTDX-9000 Cards and Chassis
by Alexander Kiwerski 17 Apr '02

17 Apr '02

Is there anyone on NANOG that has, or know of anyone that has any BSTDX-9000 Chassis, Processor or Line Cards? Please reply off-list. Thanks in advance, Alexander Kiwerski

1 0