- Test - lists.nanog.org

Re: Downstream Usage-BGP Communites
by Nick Olsen 10 May '11

10 May '11

Ah, Sorry for the confusion. We have a mutual agreement with AS100 (call it transit or peering) we send them full routes, They send us full routes. AS100 is a transit customer of AS4323. I understand I would be at the mercy of how people have things setup. I do know for a fact I'm not filtered by AS100 as I've already tested it. Thanks to everyone for the info so far. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Richard A Steenbergen" <ras(a)e-gerbil.net> Sent: Tuesday, May 10, 2011 6:27 PM To: "Nick Olsen" <nick(a)flhsi.com> Subject: Re: Downstream Usage-BGP Communites On Tue, May 10, 2011 at 05:52:39PM -0400, Nick Olsen wrote: > Greetings NANOG, > Was hoping to gain some insight into common practice with using BGP > Communities downstream. > > For instance: > We peer with AS100 (example) > AS100 peers with TW Telecom (AS4323). > Since I happen to know that AS100 doesn't sanitize the communities I send > with my routes. I can take advantage of TW Telecom's BGP communities for > traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this > be something that is generally frowned upon? Still under the assumption > that the communities aren't scrubbed off my routes. Could I do this with > other AS's beyond TW Telecom? Such as TW's peering with Global Crossing > (AS3549)? Well first off, if you're using the words "peers with" in the normal sense, your routes would never propagate to AS4323 in the first place. Assuming what you actually mean is that at least one of those sessions is a transit feed, essentially all (non-stupid) networks will filter their own TE communities from their transits/peers, so the odds of this working are almost non-existant. You also have about a 50/50 shot of AS100 stripping your communities before they even make it to AS4323 (or any other network). Personally my belief is that this is a bad thing, and you should only filter communities in your own name-space (i.e. $YOURASN:*), but this doesn't stop a large number of obnoxious networks from doing it anyways. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

2 1

Removal from mailing list
by Mitchell Manning 10 May '11

10 May '11

Can I please get taken off all nanog mailing list. Thanks, Mitch

4 4

Downstream Usage-BGP Communites
by Nick Olsen 10 May '11

10 May '11

Greetings NANOG, Was hoping to gain some insight into common practice with using BGP Communities downstream. For instance: We peer with AS100 (example) AS100 peers with TW Telecom (AS4323). Since I happen to know that AS100 doesn't sanitize the communities I send with my routes. I can take advantage of TW Telecom's BGP communities for traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this be something that is generally frowned upon? Still under the assumption that the communities aren't scrubbed off my routes. Could I do this with other AS's beyond TW Telecom? Such as TW's peering with Global Crossing (AS3549)? Nick Olsen Network Operations (855) FLSPEED x106

4 3

Gas Company?
by Santino Codispoti 10 May '11

10 May '11

I know this is a bit of an odd request but does anyone on the list work at a Gas company such has BP or Mobile?

1 0

Re: VPN tunnels between US and China dropping/slow
by Thomas York 10 May '11

10 May '11

Yes. Every day at roughly 2AM EDT the latency climbs to 700ms+ with about 25% packet loss and fluctuates until about 6-7AM. -- Thomas York Joel Jaeggli <joelja(a)bogus.com> wrote: >On 5/10/11 10:10 AM, Adam Rothschild wrote: >> Realize also that China Telecom is congested both internally and on >> certain peering interfaces. >> >> While DPI is a likely culprit, be sure to not overlook a good >> old-fashioned inability to manage capacity, combined with certain >> hashing algorithms... > >if you're measuring the end-to-end path you'll likely see evidenced of >the latency climbing on a near daily cycle. > >my median rtt from the us east coast is 268ms sometimes it's north of >370 with essentially the same loss properties. > >> -a >> >

1 0

Re: VPN tunnels between US and China dropping/slow
by Thomas York 10 May '11

10 May '11

I tried to tell my bosses that and I got a blank stare. -- Thomas York Adam Rothschild <asr(a)latency.net> wrote: >Realize also that China Telecom is congested both internally and on >certain peering interfaces. > >While DPI is a likely culprit, be sure to not overlook a good >old-fashioned inability to manage capacity, combined with certain >hashing algorithms... > >-a

1 0

VPN tunnels between US and China dropping/slow
by Thomas York 10 May '11

10 May '11

At my current place of business, we have several manufacturing plants in China as well as the United States. All of the plants have an OVPN tunnel to a datacenter here in Indianapolis which connect all of the plants. Our China plants pay for the basic 3mbit/3mbit fiber internet connections. I've had a hell of a time keeping their tunnels up. They're running on port 443 over TCP now, but every month or so the tunnel degrades so badly I have to switch the port. I've recently tried tunneling OVPN (UDP) over a GRE tunnel and that has worked for a few months..but even now is degrading. The interesting thing is that ONLY the tunnel traffic gets degraded. I've replaced all of the equipment on both ends of all of the VPN tunnels, which changed nothing. Currently, we're talking to Time Warner and some of our customers who have plants in China to see what solutions they're using to get around this kind of issue. One thing we are hearing quite often is that they're using a MPLS based connection to Hong Kong, then going to the USA from there. We're happy to try this, but due to cost issues we're (management mostly) considering this a last resort option. Are there any other options maybe some of you have to fixing this issue? Thanks Thomas York

6 5

L3 ECMP over links with different RTT
by Dikkema, Michael (Business Technology) 10 May '11

10 May '11

Hi, Is it foolish to build a L3 ECMP connection between 2 iBGP routers with one of the links having a 50% longer RTT? We're building fiber between 2 locations with the option of going both north and south around the great lakes. One link will have a 20ms RTT and one with around 35ms. The majority of our peering and transit will be on one side, with the enterprise datacenter on the other. The design right now would use OSPF as an IGP over these links with iBGP peering on loopbacks. Both links are 1G. Any thoughts on doing this different/better would be appreciated. Thanks.

3 2

Re: Cent OS migration
by Jay Ashworth 10 May '11

10 May '11

----- Original Message ----- > From: "Walter Vaughan" <wvaughan(a)steelerubber.com> > You most definately will want to make sure your user id's are > identical between the two systems, otherwise stuff like @CB will have wrong information. Excellent point. > Also, do you have any expertise maintaing a linux box? If you want > something closer > to SCO in mentality, FreeBSD and SCO have the same grandparents. Linux > is like > the cute girl that moved into town. Stuff isn't always where you > expect > to find it, > and you may get a surprise if you reach into the wrong place. Oh, don't *even* send him to BSD. CentOS and SuSE 11 are the only rational free Linuces for business use. *Any* of the BSDs are so much less well supported that they'll drive you straight up a wall. Cheers, -- jra

9 8

Suspecious anycast prefixes
by Yaoqing(Joey) Liu 10 May '11

10 May '11

Hi all, I found the following prefixes are often originated by many ASNs more than five, wonder if they provide global anycast service, if so what specific service they provide? 12.64.255.0/24 70.37.135.0/24 198.32.176.0/24 199.7.49.0/24 199.7.80.0/24 199.16.93.0/24 199.16.94.0/24 199.16.95.0/24 206.223.115.0/24 Thanks, Yaoqing

11 32