Re: Upstream BGP community support
i would rather earn it by designing things, not by cleaning up messes made by kiddies needing to show off. For those who try their best, given your comment, what in the fsck is one to do? [ i prefer to speak in the first person, not tell you what you should do. ] i try to use as few tricks, knobs, and clever things as possible and still get my job done. i try to be extremely conscious of, and minimal, when what i am doing effects or is visible to my neighbors and/or the global net. i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. i prefer to be seen as an old and lazy minimalist, not a clever person. clever was a pejorative where/when i was brought up. randy
Re: Upstream BGP community support
On Mon, Nov 02, 2009 at 05:19:32AM -0500, Randy Bush wrote: i try to use as few tricks, knobs, and clever things as possible and still get my job done. i try to be extremely conscious of, and minimal, when what i am doing effects or is visible to my neighbors and/or the global net. i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. i prefer to be seen as an old and lazy minimalist, not a clever person. clever was a pejorative where/when i was brought up. Translation: randybush You damn kids! Get off my lawn! But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. Obviously you can take it too far, I'm sure we've all seen examples of absurdly over-complicated designs which existed only for the edification of someone's ego, but I have never seen a intelligent and well thought out BGP community system do anything other than make everyone's life easier. I don't know who these people are who you claim are busy breaking things with communities, but I've never seen them. Being clever is a good thing when it helps you find new ways to do more with less, and those who can't innovate in this industry are dooming themselves to obsolescence. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
On Mon, Nov 2, 2009 at 11:56 AM, Richard A Steenbergen r...@e-gerbil.net wrote: But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. Obviously you can take it too far, I'm sure we've all seen examples of absurdly over-complicated designs which existed only for the edification of someone's ego, but I have never seen a intelligent and well thought out BGP community system do anything other than make everyone's life easier. I don't know who these people are who you claim are busy breaking things with communities, but I've never seen them. Being clever is a good thing when it helps you find new ways to do more with less, and those who can't innovate in this industry are dooming themselves to obsolescence. That being said, how can we (me, my company, nanog, ...) possibly do to convince someone like HE, who wants to be a global player, to support BGP communities? I'm not that good at baking cakes, but HE seems to be doing pretty well at that. I know that some engineers from HE are in this list; maybe they can give us some insight as to why they believe communities are worthless. Andy
Re: Upstream BGP community support
Richard A Steenbergen wrote: On Mon, Nov 02, 2009 at 05:19:32AM -0500, Randy Bush wrote: i try to use as few tricks, knobs, and clever things as possible and still get my job done. i try to be extremely conscious of, and minimal, when what i am doing effects or is visible to my neighbors and/or the global net. i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. i prefer to be seen as an old and lazy minimalist, not a clever person. clever was a pejorative where/when i was brought up. Translation: randybush You damn kids! Get off my lawn! bullshit But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. and they need not be cute, clever, or complex. unless we did not get enough strokes as a kid. randy
Re: Small guys with BGP issues
Friends don't let friends drink and reply-all. I'm just sayin. -j --Original Message-- From: Richard A Steenbergen To: Steve Bertrand Cc: NANOG list Subject: Re: Small guys with BGP issues Sent: Nov 1, 2009 11:07 PM On Sun, Nov 01, 2009 at 11:54:07PM -0500, Steve Bertrand wrote: I'm not a political person. Take it for what it is worth. I personally know people who do both: - practice but not preach - preach but don't practice ... however you take my point, I don't care. I just wanted it to be known that the 'guys' who do practice it should 'God willing' come out and preach it. And this is not the big boy list. This is for all Operators in North America, and many who are not, regardless of size. (Well, I guess we'll exclude the guy who buys are cable/DSL link and provides to his mother father with a LinkSys.) eh, -stevieb has much respect for all those who read this list, and when he posts, feels that the big guys are looking down upon him... hopefully with approval. Ok so, without getting into debates over being political, practicing vs preaching, BCP38, or big guys vs little guys, can you please explain in clear english what in the name of holy hell you're talking about? What is the issue here, that your DSL provider won't speak BGP with you no matter how many times you've asked, so you're complaining to NANOG about it because you don't have the ability or authority to change providers? Please correct me if I'm reading this wrong, but the emails so far haven't been very clear and this isn't making a lot of sense. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the existence of said peering: g2 is raising the cost of gaining info. you can not prevent it absolutely. randy
Re: Upstream BGP community support
On Nov 2, 2009, at 6:46 AM, Randy Bush wrote: But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. and they need not be cute, clever, or complex. unless we did not get enough strokes as a kid. I think you two are speaking ever so slightly past each other. Specifically, you are using the term 'clever' in different ways. Also, Randy, complexity is not always bad. More transistors on a chip can absolutely make it more complex, but it can be useful if you know where to put them and how they interact. Complexity is not the enemy. Poorly understood complexity, complexity for the sake of complexity, complexity with no goal, these are bad. Saying complexity itself is bad is just as silly as adding complexity for no gain. You want to lower opex. A fine goal. Richard claims implementing a community-signaling product on his network lowers his opex. You say breaking things in ways that hurt your neighbors is bad. Richard has years of running his network in this way without harming his neighbors. Etc., etc. It sounds to me like you two agree. So why don't you shake hands and go back to your corners? Unless you'd rather talk past each other and argue semantics in front of 10K+ of your not-so-closest friends? -- TTFN, patrick
Re: Upstream BGP community support
On Mon, Nov 2, 2009 at 6:36 AM, Randy Bush ra...@psg.com wrote: As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the existence of said peering: g2 is raising the cost of gaining info. you can not prevent it absolutely. No kidding--the traffic backlog on it this morning was horrible; must have cost at least twice as much gas as normal![1] (it actually took a bit of digging for me to find a working definition of G2 that made sense in this context; is this a commonly used term that I've just managed to remain ignorant of, or is it really as archaic and esoteric as the lack of definitions in search engines would seem to indicate? Is there a commonly-referred-to network glossary where people go to look up random acronyms and terms like this, or does everybody just do their own digging when terms are tossed out like this with no definition associated with it?) randy Thanks! Matt [1]http://en.wikipedia.org/wiki/County_Route_G2_%28California%29
some discussion on one vendor's (juniper) silicon...
The juniper pr event at the nyse actually contained some not unreasonable information on their new silicon. starts about 25 minutes in (silly registration required)... http://www.thenewnetworkishere.com/simulcast.html
Re: Upstream BGP community support
So this questions we have approached from time to time. Is there some worth to be had in finding some consensus (assuming such a thing is possible) on a subset of the features that people use communities for that could be standardized? particularly in the context of source based remote triggered blackholing this seemed a like a worthwhile effort. A standardized set means it can be cooked into documentation, training, and potentially even products. it doesn't mean that everyone will enable it, but if they do it would be nice to agree on some basi grounds rules. it should also be understood that many if not most localized community signaling uses would remain localized in terms of their documentation and use. joel jim deleskie wrote: Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) -jim On Sat, Oct 31, 2009 at 9:25 PM, Randy Bush ra...@psg.com wrote: while i can understand folk's wanting to signal upstream using communities, and i know it's all the rage. one issue needs to be raised. bgp is a brilliant information hiding protocol. policy is horribly opaque. complexity abounds. and it has unfun consequences, e.g. see tim on wedgies etc. and this just adds to the complexity and opacity. so i ain't sayin' don't do it. after all, who would deny you the ability to show off your bgp macho? just try to minimize its use to only when you *really* need it. randy
Re: Upstream BGP community support
Joel Jaeggli wrote: A standardized set means it can be cooked into documentation, training, and potentially even products. Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities. The nature of communities, and the different levels of support and traffic engineering capabilities makes it difficult for it to be standardized. It would take even longer for anyone to adopt such a standard due to the sheer volume of routers and customers who would have to adapt from long term established policies. Jack Bates
Re: Upstream BGP community support
Jack Bates wrote: Joel Jaeggli wrote: A standardized set means it can be cooked into documentation, training, and potentially even products. Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities. The nature of communities, and the different levels of support and traffic engineering capabilities makes it difficult for it to be standardized. It would take even longer for anyone to adopt such a standard due to the sheer volume of routers and customers who would have to adapt from long term established policies. You're not going to get any argument from me about the diversity of implmentations or the needs arising out of network specific optimization. That said, our previous conclusion was also that we couldn't reasonably do this for a subset of them so I don't have to go very far to be convinced. That said standardization would likely make some features more accessible and therefore more likely to be used, I don't think traffic engineering is something I particularly want to encourage to excess but RTBH is a know that more people need access to quite frankly. joel Jack Bates
Re: Upstream BGP community support
Joel Jaeggli wrote: more accessible and therefore more likely to be used, I don't think traffic engineering is something I particularly want to encourage to excess but RTBH is a know that more people need access to quite frankly. I think creating a standard or at least a template might push more people to adopt communities support and to use them. There are definitely times it is useful to redirect traffic 2 ASN's away through a longer route. In some cases (like my small self, I try to adopt policies that allow communities to me to also be rewritten to the corresponding peers communities to alter things as far as 3 ASN's away from my customer. Jack
Re: Upstream BGP community support
On Mon, Nov 02, 2009 at 01:38:00PM -0600, Jack Bates wrote: Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities. Even the standardized ones aren't guaranteed to be useful. For example RFC3765 defines a NOPEER community, i.e. a standardized way to say do not export this route to peers (in the settlement free bilateral sense of the word). But there is no possible way for the router to know what is or isn't a peer, so it's up to the operator to implement the matching for this supposedly standard community. But guess what, most people don't, and those that do implement the functionality end up writing their own network specific version anyways (either because they want to keep it secret, or because they need to implement far more powerful version anyways). If we want to turn this into a discussion on useful things to do with communities (to try and recover some value from this otherwise brain rotting thread), how about this one. We as network operators are currently facing a problem with BGP communities, and that problem is called 32 bit ASNs. Quite simply, 32 bit ASNs don't fit into the existing 16:16 scheme. There are new 64 bit communities (extended communities) out there, but they aren't a 1:1 mapping of the way communities work today. Rather than simply double the size and break it up into 32:32, the designers reserved the top 16 bits for type and subtype attributes, leaving you only 48 bits to work with. Clearly the only suitable mapping for support of 32-bit ASNs on the Internet is 32:16, leaving us with exactly the same range of data values that we have today. So why do I bring this up? Because of those top 16 bits for type and subtype. Two of the type fields that are newly introduced in extended communities are target and origin, which specifically mean this tag is trying to tell $ASN something, vs this $ASN is trying to tell you something. This actually has the benefit of addressing one of the most common problems with communities today, namespace collision between folks trying to both send instructions and receive data within the same ASN:x tag. Since we're all going to need to start updating our routing policies to support 32 bit ASNs soon anyways (unless you want to tell people getting them that they aren't allowed to use communities :P), now is a good time to start thinking about taking advantage of these new features to resolve age-old problems in your new community design. Another feature I think would be beneficial for router vendors to consider implementing is a way to map between regular and extended communities. For example, I might be able to apply a policy at the edge of my network which imports regular communities from my neighbor, and turns them into origin: tags of extended communities. I might then be able to update my internal network to work on extended communities, and translate them back again to regular for backwards compatibility at the edge. Also, now is a good time to find out if your router vendor ACTUALLY supports extended communities in all of their features (for example, regexp support), or if they only exist for l3vpn support and are not actually prepared to use them to work with 32-bit ASNs. Hint: Some vendors still fall into this category last I looked. Apologies if this post contained too much clever and made Randy's head explode. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Upstream BGP community support
(Apologies for top-replying, but hey, it makes it easier to ignore stuff you've already read.) I think the main things to consider in identifying what things belong in a standardized community are: - is it something that is really global, and not local, in behaviour and scope? - is it something that is mostly a signalling-of-intent flag, and not a modification of path-selection? -- (because) It should not require universal adoption to be useful - if it is ignored by A, and passed to B, will it still be useful/semantically correct? - is it something that will either be applied by the originator to all instances of a given prefix (i.e. sending X to neighbour A and neighbour B, with community M); - or something that will be applied by the originator to some instances of a given prefix (i.e. sending X to A with N, and X to B without N) - is the intent being signalled easily understood, ideally in an absolute sense? The two things I can think of, which would benefit from such a community, and where nearly-universal adoption would be of significant benefit, are: (1) Blackhole this prefix, and; (2) Use this prefix as a last resort only. (Please add to this list if you think of any other cases meeting the above criteria). Comments on particular proposed-standard-community cases follows... I bring up (2) because it is otherwise *very* difficult to signal (or achieve), and often leads to potential wedgies. The existing mechanisms to achieve (2) are often indistinguishable from Traffic Engineering - but this is very much not TE. TE is reduce load on this instance. (2) is Don't use this for traffic unless you have no paths not marked with this community. TE will typically be observed with small numbers of AS-prepending. (2) will be observed with large numbers of AS-prepending. And, my guess would be, 80% of the prepending would not be needed if (2) were standardized and in use. It might even reduce significantly the observed instances of wedgies and/or persistent oscillations in the wild. Brian -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: November-02-09 4:03 PM To: Joel Jaeggli Cc: nanog@nanog.org Subject: Re: Upstream BGP community support Joel Jaeggli wrote: more accessible and therefore more likely to be used, I don't think traffic engineering is something I particularly want to encourage to excess but RTBH is a know that more people need access to quite frankly. I think creating a standard or at least a template might push more people to adopt communities support and to use them. There are definitely times it is useful to redirect traffic 2 ASN's away through a longer route. In some cases (like my small self, I try to adopt policies that allow communities to me to also be rewritten to the corresponding peers communities to alter things as far as 3 ASN's away from my customer. Jack
Speed Testing and Throughput testing
Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? Thanks, Mark Urbach PinPoint Communications, Inc. 100 N. 12th St Suite 500 Lincoln, NE 68508 402-438-6211 ext 1923 Office 402-660-7982 Cell mark.urb...@pnpt.com [cid:image003.jpg@01CA5BD5.1A5CEE20] inline: image003.jpg
Re: Speed Testing and Throughput testing
iperf is fairly standard and supports some handy features - http://en.wikipedia.org/wiki/Iperf -Jack Carrozzo On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach mark.urb...@pnpt.com wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? Thanks, Mark Urbach PinPoint Communications, Inc. 100 N. 12th St Suite 500 Lincoln, NE 68508 402-438-6211 ext 1923 Office 402-660-7982 Cell mark.urb...@pnpt.com [cid:image003.jpg@01CA5BD5.1A5CEE20]
Re: Speed Testing and Throughput testing
On 3/11/2009, at 10:56 AM, Mark Urbach wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? If you want accuracy, you want to buy a packet generator/router tester unit. I just built a tool for a customer (a last-mile network provider) that runs a series of iperf tests over several days, and generates a report. iperf works well enough, but it seems to be much better when driven by humans, vs. driven by scripts. I'm not aware of any free tools that do just ethernet frames. Do you have a server/software that customer can test too? Not sure what you're after here - do you want to host your own speedtest.net-like service so your customers can self-test their access links? Does this mean much, or should they be testing against a server outside your network? Also, if you host your own service and you're talking about 10/100/1000mbit connections, you might want to put something in place that prevents several people testing at once. -- Nathan Ward
Re: Speed Testing and Throughput testing
perfsonar livecd offers npad service that remote hosts can connect and see the performance and results. http://www.internet2.edu/performance/toolkit/index.html TcpOptimizer helps tunning the tcp/ip for windows systems. http://www.speedguide.net/downloads.php nuttcp is good to generate packets/sec. -Azher Nathan Ward wrote: On 3/11/2009, at 10:56 AM, Mark Urbach wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? If you want accuracy, you want to buy a packet generator/router tester unit. I just built a tool for a customer (a last-mile network provider) that runs a series of iperf tests over several days, and generates a report. iperf works well enough, but it seems to be much better when driven by humans, vs. driven by scripts. I'm not aware of any free tools that do just ethernet frames. Do you have a server/software that customer can test too? Not sure what you're after here - do you want to host your own speedtest.net-like service so your customers can self-test their access links? Does this mean much, or should they be testing against a server outside your network?Also, if you host your own service and you're talking about 10/100/1000mbit connections, you might want to put something in place that prevents several people testing at once. -- Nathan Ward -Azher
Re: Speed Testing and Throughput testing
I use iperf with packet capture on both sides, then analyze the packet capture for per-second throughput and re-transmits. I usually do 10 TCP streams for 30 seconds. Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is needed to deal with the bandwidth delay product. It is also possible that Ethernet drivers will have an effect. Local testing of the pair of test machines should be done if you can't get to about 980 Mbps on a Gig link (keeping in mind the comment about TCP tuning as latency increases). Jon On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach mark.urb...@pnpt.com wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? Thanks, Mark Urbach PinPoint Communications, Inc. 100 N. 12th St Suite 500 Lincoln, NE 68508 402-438-6211 ext 1923 Office 402-660-7982 Cell mark.urb...@pnpt.com [cid:image003.jpg@01CA5BD5.1A5CEE20]
Re: Speed Testing and Throughput testing
Nathan Ward wrote: On 3/11/2009, at 10:56 AM, Mark Urbach wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? An NDT server?... such as: http://ndt.anl.gov:7123/
Re: Speed Testing and Throughput testing
On Mon, Nov 02, 2009 at 01:30:18PM -1000, Michael Painter wrote: Nathan Ward wrote: On 3/11/2009, at 10:56 AM, Mark Urbach wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? An NDT server?... such as: http://ndt.anl.gov:7123/ I just tested that server, and couldn't get any results which were even vaguely close to accurate. Of course it probably didn't help that the only routes I could find to the test server were either Chicago - Palo Alto - Chicago or Chicago - Ashburn - Chicago, but this doesn't seem like it would ever be useful for testing gigabit anything. For end user testing, I've actually seen reasonable results from speedtest.net. http://www.speedtest.net/result/610596179.png for example, better than ndt.anl.gov at any rate. :P For quick and dirty high speed Internet testing up to a gigabit, this is my favorite standby (it often helps to eliminate your local disk from the equation by writing the downloaded file to /dev/null too): fetch -o /dev/null http://cachefly.cachefly.net/100mb.test /dev/null 100% of 100 MB 102 MBps But the best (and conveniently enough the most commonly used) tool for in-depth high speed testing was already mentioned, iperf. Another useful tool if you're trying to troubleshoot tcp issues is http://www.tcptrace.org/. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Level3 90+% Packet Loss in New York
Anyone know anything? Has happened twice today, right now, and between 12:22pm and 12:49pm (at least same symptoms as this issue) Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 208.72.185.1770.0% 7850.3 0.3 0.2 20.4 1.1 2. 208.72.184.2450.0% 7850.6 0.4 0.2 78.7 2.9 3. ge-6-7.car3.NewYork1.Level3.net 0.0% 7850.6 11.7 0.4 316.3 37.7 4. vlan69.csw1.NewYork1.Level3.net 96.4% 7848.2 5.4 0.6 13.5 4.2 5. ae-64-64.ebr4.NewYork1.Level3.net97.1% 7843.6 11.1 1.7 25.2 6.4 6. ae-6-6.ebr2.NewYork2.Level3.net 95.5% 7849.0 5.5 1.0 13.7 4.1 7. ae-2-2.ebr1.Chicago1.Level3.net 94.9% 784 39.1 31.2 22.0 41.6 6.5 8. ae-1-53.edge3.Chicago3.Level3.net96.3% 784 33.4 29.9 21.6 83.6 12.8 9. BANDCON.edge3.Chicago3.Level3.net95.7% 784 26.8 32.4 22.3 150.1 23.2 10. po2.core3.chi01.steadfast.net96.3% 784 33.0 30.1 22.2 93.0 13.0 11. ip76.216-86-150.static.steadfast.net 96.3% 777 33.5 28.4 22.6 35.4 4.5 --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ ---
Re: Speed Testing and Throughput testing
On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach mark.urb...@pnpt.com wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? One wonders how netnod does this... I believe they put in some servers specifically so their local users could verify that bw bought was bw received... Maybe someone from netnod even wrote up their methods/procedures/process/utilities/tools? :) (Maybe one would even give a talk about it at an upcoming meeting?) -Chris
Re: Level3 90+% Packet Loss in New York
Only thing I know is that as I was walking home, I saw a Level 3 van with an open manhole cover outside the front of the Tribeca Grand (a block from 32 Ave of A).. On Mon, Nov 2, 2009 at 7:39 PM, Peter Beckman beck...@angryox.com wrote: Anyone know anything? Has happened twice today, right now, and between 12:22pm and 12:49pm (at least same symptoms as this issue) -- --- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com ---
