Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: On Mon, Feb 21, 2011 at 19:08, Dan Wing dw...@cisco.com wrote: Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as broken as others have claimed, and sub-optimal might be acceptable if it's the only alternative. Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. Cheers, -Benson
Re: raw bgp traffic
Hope this helps http://packetlife.net/captures/category/routing-protocols/ Regards On Mon, 2011-02-21 at 17:58 -0800, Javier Godinez wrote: Deal NANOG, Does anyone know where I can get real/raw BGP traffic, maybe in pcap format? I just need maybe a few days of raw data for an inline analysis tool I am developing. Thank you, Javier
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
[ arin cesspool removed from cc: as i can not post there anyway ] There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! randy
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 12:29 AM, Benson Schliesser wrote: On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: On Mon, Feb 21, 2011 at 19:08, Dan Wing dw...@cisco.com wrote: Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). I would point out to them that the fact that their technology choice isn't NAT 444 does not mean that they don't have the same problems, merely that their technology wasn't part of the testing documented in the draft. I think the draft is perfectly clear and that humans, even intelligent humans often have problems with this level of logic. If A is a subset of B, it does not mean that A is not a subset of C. Therefore, a draft that states that technology B has problem A is not and cannot be logically construed as a statement that technology C does not have problem A, no matter how common it is for seemingly intelligent humans to make the mistake of doing so. More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. I don't think anyone has said that IPv6 is the only address family that matters. What I think people, myself included, have been saying is that IPv6 is the only way forward that does not involve many of these problems. (See my earlier Titanic post). As to whether or not it matters that people misinterpred draft-donly..., I'm not sure whether it actually does or not. There is no flavor of NAT that is particularly desirable. It's a matter of choosing the one that is least damaging to your environment where least damage may boil down to a choice between 5% and 3% remaining functionality. On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as broken as others have claimed, and sub-optimal might be acceptable if it's the only alternative. I don't think anyone is saying IPv4 no longer matters. I think we are saying that effort spent attempting to make the deteriorating IPv4 situation deteriorate less is both futile and better spent on making the IPv6 deployment situation better. Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. Only if you expect that you can rely on a supply side in such a market. I am unconvinced that such will be reliable, especially after about 6 months of trading. This also presumes that more sensitive users can be defined in terms of what those users are willing (or able) to pay. Owen (who is very glad he has provider-independent addresses in both families as we approach this iceberg)
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
-Original Message- From: Chris Grundemann [mailto:cgrundem...@gmail.com] Sent: Monday, February 21, 2011 8:17 PM To: Dan Wing Cc: Owen DeLong; Benson Schliesser; NANOG list; ARIN-PPML List Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) On Mon, Feb 21, 2011 at 19:08, Dan Wing dw...@cisco.com wrote: Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. More importantly, I am unsure the point of this argument. My point is that: NAT breaks things, but NAT444 is /not/ the only case where breakage occurs. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). Vendor test results don't carry much value. The authors of draft-donley-nat444-impacts did testing, and I sincerely hope will publish results that split the impacts of access bandwidth starvation from home NAT from CGN from NAT444. -d Cheers, ~Chris -d -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
Re: BGP Failover Question
We are recieving full routes from both providers. ---Chris On Feb 21, 2011, at 6:36 PM, Charles Gucker wrote: On Mon, Feb 21, 2011 at 4:10 PM, Chris Wallace li...@iamchriswallace.com wrote: This isn't the first time we have seen this issue with our various providers, how can I prevent issues like this from happening in the future? Quick question, are you running with a default route from your provider? If so, you're better off either finding another provider, or upgrading the router (if necessary) to carry a full table. If they do something to partition their network, you will see the decrease in routes learned from them, provided you see those routes and not the default route as asked above. charles
Re: BGP Failover Question
As Max stated, you can set triggers based on thresholds that are monitered via multiple methods in Cisco IOS. That way you could force the route down dynamically. There's always a risk when letting the machines do the thinking but this would help in situations like this. Can't speak for other vendors but I'm sure the features are similar. -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 11:17 AM, Chris Wallace li...@iamchriswallace.comwrote: We are recieving full routes from both providers. ---Chris On Feb 21, 2011, at 6:36 PM, Charles Gucker wrote: On Mon, Feb 21, 2011 at 4:10 PM, Chris Wallace li...@iamchriswallace.com wrote: This isn't the first time we have seen this issue with our various providers, how can I prevent issues like this from happening in the future? Quick question, are you running with a default route from your provider? If so, you're better off either finding another provider, or upgrading the router (if necessary) to carry a full table. If they do something to partition their network, you will see the decrease in routes learned from them, provided you see those routes and not the default route as asked above. charles
RE: Contact for APEWS.org?
APEWS is braindead in execution, if not in fact. They list about half of all IPv4 space, and one might reasonably state that anyone using them deserves their own self-inflicted SMTP intranet. http://www.dnsbl.com/2007/08/apews-news-and-commentary-roundup.html Andrew The link Andrew sent over contains some great advice - make sure to read through to: http://www.dnsbl.com/2007/08/what-to-do-if-you-are-listed-on-apews.html
Re: BGP Failover Question
On 02/22/2011 12:23 PM, Hammer wrote: As Max stated, you can set triggers based on thresholds that are monitered via multiple methods in Cisco IOS. That way you could force the route down dynamically. There's always a risk when letting the machines do the thinking but this would help in situations like this. Can't speak for other vendors but I'm sure the features are similar. Well as someone else stated, if an upstream provider can't provide BGP reliably then it's time to give them the boot. Once in a year, okay, but beyond that, then it's time to read riot act with that provider. Bret
Re: BGP Failover Question
I'm not argueing that at all. But it wasn't relevent to the question at hand. And depending on the scale of your business dumping providers is not something done on a whim. It's not like your fed up with DSL and want to convert to Cable. -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark bcl...@spectraaccess.comwrote: On 02/22/2011 12:23 PM, Hammer wrote: As Max stated, you can set triggers based on thresholds that are monitered via multiple methods in Cisco IOS. That way you could force the route down dynamically. There's always a risk when letting the machines do the thinking but this would help in situations like this. Can't speak for other vendors but I'm sure the features are similar. Well as someone else stated, if an upstream provider can't provide BGP reliably then it's time to give them the boot. Once in a year, okay, but beyond that, then it's time to read riot act with that provider. Bret
Re: BGP Failover Question
Assuming that he has provider independent space (why run full BGP feeds if you are not multihomed?), then, actually it's about on par and less disruptive in general. Add new provider, wait a day or two, then disconnect old provider. If he's using provider assigned space, then, the big hurdle is switching to provider independent (requires a renumber), but, that's a good idea for a variety of reasons. I would hardly call the type and frequency of outages described a whim when using that as a reason to change providers. Sounds like he is suffering severe impact to his business. Owen On Feb 22, 2011, at 10:15 AM, Hammer wrote: I'm not argueing that at all. But it wasn't relevent to the question at hand. And depending on the scale of your business dumping providers is not something done on a whim. It's not like your fed up with DSL and want to convert to Cable. -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark bcl...@spectraaccess.comwrote: On 02/22/2011 12:23 PM, Hammer wrote: As Max stated, you can set triggers based on thresholds that are monitered via multiple methods in Cisco IOS. That way you could force the route down dynamically. There's always a risk when letting the machines do the thinking but this would help in situations like this. Can't speak for other vendors but I'm sure the features are similar. Well as someone else stated, if an upstream provider can't provide BGP reliably then it's time to give them the boot. Once in a year, okay, but beyond that, then it's time to read riot act with that provider. Bret
admin-c/tech-c deny responsibility/ownership of netblock
Is there a process to revoke netblocks from entities which deny ownership? http://www.db.ripe.net/whois?searchtext=77.223.129.43 The admin-c, tech-c deny any responsibility for this netblock. -Dan
Re: BGP Failover Question
On Feb 22, 2011, at 10:52 AM, Hammer wrote: I agree. But swapping providers is not the default answer in some environments. I work in an enterprise with multiple GE circuits from multiple providers to the Internet. The lead time on calling up a different carrier and saying I need a gigabit connection to the Internet would probably be 90-120 days. And then you get to go thru the contracts/negotiations and MSAs. You don't just flip. In smaller operations I understand. But I was simply saying that it's not always that easy. If I went to my boss and said one of our carriers sucks and we should dump them he would just laugh and throw me out. That depends on where you are. If you have a router in one or more of the many carrier hotels around the world, you can usually order a new Gig-E cross-connect with service in less than a week. If you need to have a circuit engineered, then, 30-90 days is probably about right. If you need to have facilities installed to provide said circuit, it can be as much as 180 days. However, I don't think the point was disconnect them tomorrow. I think the point was If the impact is that severe, the sooner you start the new provider process, the sooner you get relief. 1. What are the SLAs with the carrier in question? Do you have them clearly defined? Are they out of SLA? If so, what compensation is entitled based on violation of said SLA? 99.99% of all SLAs are a pittance of money refunded IF you jump through extreme hoops to collect. They are rarely sufficient to resolve or even compensate for outages. 2. What trending are you doing to document the failures in SLA of the carrier in question? Do we have a documented pattern of poor performence by using that trending? 3. What are our contractual or legal options based on items 1 and 2? 4. Don't forget about the Layer8 (political) factor. If your telco manager is buddies with the carrier then you have to double your documentation against them. Some companies spend tens of millions a month on circuits. You better be ready to justify yourself. Yeah, this is usually the biggest problem. Owen -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 12:38 PM, Owen DeLong o...@delong.com wrote: Assuming that he has provider independent space (why run full BGP feeds if you are not multihomed?), then, actually it's about on par and less disruptive in general. Add new provider, wait a day or two, then disconnect old provider. If he's using provider assigned space, then, the big hurdle is switching to provider independent (requires a renumber), but, that's a good idea for a variety of reasons. I would hardly call the type and frequency of outages described a whim when using that as a reason to change providers. Sounds like he is suffering severe impact to his business. Owen On Feb 22, 2011, at 10:15 AM, Hammer wrote: I'm not argueing that at all. But it wasn't relevent to the question at hand. And depending on the scale of your business dumping providers is not something done on a whim. It's not like your fed up with DSL and want to convert to Cable. -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark bcl...@spectraaccess.comwrote: On 02/22/2011 12:23 PM, Hammer wrote: As Max stated, you can set triggers based on thresholds that are monitered via multiple methods in Cisco IOS. That way you could force the route down dynamically. There's always a risk when letting the machines do the thinking but this would help in situations like this. Can't speak for other vendors but I'm sure the features are similar. Well as someone else stated, if an upstream provider can't provide BGP reliably then it's time to give them the boot. Once in a year, okay, but beyond that, then it's time to read riot act with that provider. Bret
Re: admin-c/tech-c deny responsibility/ownership of netblock
On 22 feb 2011, at 20:44, goe...@anime.net wrote: The admin-c, tech-c deny any responsibility for this netblock. Have you talked to RIPE?
[OT] Internet connectivity options in Afghanistan?
I'm looking for cheap/slow internet connectivity options in Kabul, Jalalabad, and Herat. The connections will be used by AFCECO orphanages, so speed isn't as much of an issue as cost. I'm guessing that satellite might be the only game in town, but if any of you fine folks know of connectivity options, I'd appreciate an email.
Re: BGP Failover Question
Uncle! -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 1:20 PM, Owen DeLong o...@delong.com wrote: On Feb 22, 2011, at 10:52 AM, Hammer wrote: I agree. But swapping providers is not the default answer in some environments. I work in an enterprise with multiple GE circuits from multiple providers to the Internet. The lead time on calling up a different carrier and saying I need a gigabit connection to the Internet would probably be 90-120 days. And then you get to go thru the contracts/negotiations and MSAs. You don't just flip. In smaller operations I understand. But I was simply saying that it's not always that easy. If I went to my boss and said one of our carriers sucks and we should dump them he would just laugh and throw me out. That depends on where you are. If you have a router in one or more of the many carrier hotels around the world, you can usually order a new Gig-E cross-connect with service in less than a week. If you need to have a circuit engineered, then, 30-90 days is probably about right. If you need to have facilities installed to provide said circuit, it can be as much as 180 days. However, I don't think the point was disconnect them tomorrow. I think the point was If the impact is that severe, the sooner you start the new provider process, the sooner you get relief. 1. What are the SLAs with the carrier in question? Do you have them clearly defined? Are they out of SLA? If so, what compensation is entitled based on violation of said SLA? 99.99% of all SLAs are a pittance of money refunded IF you jump through extreme hoops to collect. They are rarely sufficient to resolve or even compensate for outages. 2. What trending are you doing to document the failures in SLA of the carrier in question? Do we have a documented pattern of poor performence by using that trending? 3. What are our contractual or legal options based on items 1 and 2? 4. Don't forget about the Layer8 (political) factor. If your telco manager is buddies with the carrier then you have to double your documentation against them. Some companies spend tens of millions a month on circuits. You better be ready to justify yourself. Yeah, this is usually the biggest problem. Owen -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 12:38 PM, Owen DeLong o...@delong.com wrote: Assuming that he has provider independent space (why run full BGP feeds if you are not multihomed?), then, actually it's about on par and less disruptive in general. Add new provider, wait a day or two, then disconnect old provider. If he's using provider assigned space, then, the big hurdle is switching to provider independent (requires a renumber), but, that's a good idea for a variety of reasons. I would hardly call the type and frequency of outages described a whim when using that as a reason to change providers. Sounds like he is suffering severe impact to his business. Owen On Feb 22, 2011, at 10:15 AM, Hammer wrote: I'm not argueing that at all. But it wasn't relevent to the question at hand. And depending on the scale of your business dumping providers is not something done on a whim. It's not like your fed up with DSL and want to convert to Cable. -Hammer- I was a normal American nerd. -Jack Herer On Tue, Feb 22, 2011 at 12:11 PM, Bret Clark bcl...@spectraaccess.com wrote: On 02/22/2011 12:23 PM, Hammer wrote: As Max stated, you can set triggers based on thresholds that are monitered via multiple methods in Cisco IOS. That way you could force the route down dynamically. There's always a risk when letting the machines do the thinking but this would help in situations like this. Can't speak for other vendors but I'm sure the features are similar. Well as someone else stated, if an upstream provider can't provide BGP reliably then it's time to give them the boot. Once in a year, okay, but beyond that, then it's time to read riot act with that provider. Bret
Re: [OT] Internet connectivity options in Afghanistan?
On Tue, Feb 22, 2011 at 3:26 PM, Janet Sullivan netg...@bgp4.net wrote: I'm looking for cheap/slow internet connectivity options in Kabul, Jalalabad, and Herat. The connections will be used by AFCECO orphanages, so speed isn't as much of an issue as cost. I'm guessing that satellite might be the only game in town, but if any of you fine folks know of connectivity options, I'd appreciate an email. You can get expensive and slow, not so sure about cheap and slow. Bentley Walker and ts2.pl is what basically everyone is using out there, and it's all 100% garbage. Our company had a contract to provide 6 Mbps of connectivity to a NATO base, so I can share notes with anyone who is interested. -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators with the opinion that 'IPv4 doesn't matter' represent the minority. Of course, it also depends on how you define doesn't matter. I think that ongoing operation matters, especially when ongoing means a continued expectation of both existing and new customers. It's easy to say, burn the IPv4 bridge so we're forced to migrate to IPv6. But it's another thing to actually do it, when you're competing for customers that want IPv4 connectivity. That said, we're not forced to choose only one: IPv4 vs. IPv6. We should migrate to IPv6 because it makes sense - IPv4 is going to become more expensive and painful (to use and support). That doesn't preclude us from patching IPv4 together long enough to cross the bridge first. Thoughts? Cheers, -Benson
Howto for BGP black holing/null routing
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. Thanks, David
Re: Howto for BGP black holing/null routing
On 2011-02-22 22:42, David Hubbard wrote: I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. Take a look here for starters: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf Searching through NANOG archives will return a couple of sessions that went through the other vendor configs for such functionality. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net
Re: Howto for BGP black holing/null routing
Maybe I read your question wrong, but null-routing things at your border is often not very useful if the traffic is flooding your transit links. Most transits publish their community lists - you just need to tag the prefix you want to blackhole with the right community. See example from HE: http://www.he.net/adm/blackhole.html http://www.he.net/adm/blackhole.html-Jack Carrozzo On Tue, Feb 22, 2011 at 4:42 PM, David Hubbard dhubb...@dino.hostasaurus.com wrote: I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. Thanks, David
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. most pronounced from people not involved in operating production networks that are way behind the planning curve for IPv6 deployment. There, fixed that for you. (Full disclosure - yesterday's MRTG graphs show our border routers averaging 4Gbit/sec of IPv4 traffic and 150 Mbits/sec of IPv6 - so 4% or so of our production off-campus traffic is already IPv6) pgpxDmfB4FE37.pgp Description: PGP signature
Re: Howto for BGP black holing/null routing
Also: http://docs.as701.net/tmp/CustomerBlackhole.txt Remember to set eBGP multihop on sessions for the next-hop rewrite capability :) - Jared On Feb 22, 2011, at 4:54 PM, Łukasz Bromirski wrote: On 2011-02-22 22:42, David Hubbard wrote: I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. Take a look here for starters: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf Searching through NANOG archives will return a couple of sessions that went through the other vendor configs for such functionality. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net
Re: Howto for BGP black holing/null routing
2011/2/22 Jared Mauch ja...@puck.nether.net: Also: http://docs.as701.net/tmp/CustomerBlackhole.txt Remember to set eBGP multihop on sessions for the next-hop rewrite capability :) oh hey, I was looking for that! :) (I'll try to re-setup the www.secsup.org links tonight) ... this is a 'how to setup so a customer can blackhole', which you should be able to easily hack to 'make my quagga server a customer, make him be able to blackhole all of 0/0 by /32s' keep in mind also that somethings do not react well to k's of /32's ... - Jared On Feb 22, 2011, at 4:54 PM, Łukasz Bromirski wrote: On 2011-02-22 22:42, David Hubbard wrote: I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. Take a look here for starters: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf Searching through NANOG archives will return a couple of sessions that went through the other vendor configs for such functionality. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann | http://lukasz.bromirski.net
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 3:54 PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. most pronounced from people not involved in operating production networks that are way behind the planning curve for IPv6 deployment. There, fixed that for you. My original text remains true, because I tend to hear IPv6-only advocacy from vendors and policy folks more than operators - even more so versus operators of commercial ISP networks. But I take your point, that operators ahead of the IPv6 deployment curve are most likely to stand up with that opinion. Of course, the network effect being what it is... Your network being 100% IPv6 doesn't solve the overall problem of reachability. I think your example of 4% traffic from VT is applicable - you will have to worry about IPv4 connectivity, in one form or another, until it diminishes significantly. It's a bit like a tragedy of the commons. Cheers, -Benson
RE: SmartNet Alternatives
I've used them as well and they have been pretty good with gear that's common place. Just be careful if you get off the beaten path and are using gear like an IAD-2431-16FXS. They can help you with the hardware side on that kind of stuff but not so much with the software. Richey -Original Message- From: Neil J. McRae [mailto:n...@domino.org] Sent: Wednesday, February 16, 2011 4:56 AM To: gbon...@seven.com; tbran...@gmail.com Cc: nanog@nanog.org Subject: Re: SmartNet Alternatives I've used NHR for a number of deployments over the past couple of years and they are a fantastic organisation to work with. I've used them for maintenance support in the US for replacement of parts - highly recommended. - Original Message - From: tbran...@gmail.com Sent: Tue, February 15, 2011, 11:04 PM Subject: Re: SmartNet Alternatives I know NHR has a alternative that looks to be comparable. http://www.networkhardware.com/Maintenance/ -tb
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 4:42 PM, Tony Hain wrote: Seriously, some people will not move until the path they are on is already burning, which is why they did nothing over the last 5 years despite knowing that the IANA pool was exhausting much faster than they had wanted to believe. It took getting within months of exhausting the IANA pool before the crowd woke up and noticed the path was on fire. Now you want 'just a little more'... after which it will be 'just a little more'. This won't go on forever. The price of IPv4 has been kept artificially low for the past decade, through a RIR-based system of rationing. There was never an immediate incentive to migrate. If we really wanted to motivate people before they reached the precipice, we should have increasingly raised the cost of an IPv4 address. Now, IPv4 exhaustion has effectively raised that cost for us, and people are motivated to migrate to IPv6. But since we didn't force this situation sooner, we now also have to deal with the effects of exhaustion. That's all I'm talking about. IPv4 hacks will not be better or cheaper than IPv6, and they're nothing to fear in terms of IPv6 adoption. Cheers, -Benson
Re: Howto for BGP black holing/null routing
On Feb 23, 2011, at 5:42 AM, David Hubbard wrote: I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. https://files.me.com/roland.dobbins/dweagy --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Internet Issues in Europe Tonight?
Does anyone have some detailed information about the internet issues going on in Sweden and other parts of Europe right now? I've read some reports about a large Telia outage in Sweden indicating a fault somewhere in Frankfurt or London as the cause. http://www.aftonbladet.se/nyheter/article8609308.ab http://www.dn.se/nyheter/sverige/stort-internetfel-i-europa
Re: Internet Issues in Europe Tonight?
On 02/23/2011 12:59 AM, Ryan Gelobter wrote: Does anyone have some detailed information about the internet issues going on in Sweden and other parts of Europe right now? I've read some reports about a large Telia outage in Sweden indicating a fault somewhere in Frankfurt or London as the cause. Telia has a major outage in Frankfurt, but they are claiming, that they have build a temporary solution. I didn't get any more specific from the customer care... My traffic dropped from 1.2gbit/s to 0.2 gbit/s, then I shutdown the link to telia. -tim
Re: Internet Issues in Europe Tonight?
on 23.02.2011 00:59 Ryan Gelobter wrote: Does anyone have some detailed information about the internet issues going on in Sweden and other parts of Europe right now? I've read some reports about a large Telia outage in Sweden indicating a fault somewhere in Frankfurt or London as the cause. A partner network just reported about Telia having problems with a router in Frankfurt. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
Re: Internet Issues in Europe Tonight?
Confirmed here. It's solved with a temporary solution. The ticket is still open with in Telia. -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Feb 23, 2011, at 1:15 AM, Arnold Nipper wrote: on 23.02.2011 00:59 Ryan Gelobter wrote: Does anyone have some detailed information about the internet issues going on in Sweden and other parts of Europe right now? I've read some reports about a large Telia outage in Sweden indicating a fault somewhere in Frankfurt or London as the cause. A partner network just reported about Telia having problems with a router in Frankfurt. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators benson, vendors saying what operators want went *seriously* out of fashion a couple of years back. we can speak for ourselves, tyvm. randy
Re: Howto for BGP black holing/null routing
On Tue, 22 Feb 2011, David Hubbard wrote: I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. I actually did a blog entry just a couple weeks ago about this with relatively step by step [cisco] instructions. http://jonsblog.lewis.org/2011/02/05#blackhole I'm curious what others think of the setup. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 6:29 PM, Randy Bush wrote: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators benson, vendors saying what operators want went *seriously* out of fashion a couple of years back. we can speak for ourselves, tyvm. I agree completely. I'm responding to what I've heard from operators. Cheers, -Benson
atdn.net issues
Anyone know who to contact for issues with atdn.net? Their website is not exactly a well of information. All connections from my network to anything at atdn (AOL, etc.) are dying at atdn's edge. Traceroutes go out through xo.net. I have verified that both of my upstream providers can get there fine (via the same path), so it appears to be a problem specifically with our net blocks (74.115.180.0/22 and 74.219.82.0/24) or ASN (15088) If anyone has any visibility from the other side of atdn.net, and can give me any info, I would appreciate it. thanks, -Randy
Re: atdn.net issues
On 2/22/2011 11:39 PM, Randy Carpenter wrote: Anyone know who to contact for issues with atdn.net? Their website is not exactly a well of information. All connections from my network to anything at atdn (AOL, etc.) are dying at atdn's edge. Traceroutes go out through xo.net. I have verified that both of my upstream providers can get there fine (via the same path), so it appears to be a problem specifically with our net blocks (74.115.180.0/22 and 74.219.82.0/24) or ASN (15088) If anyone has any visibility from the other side of atdn.net, and can give me any info, I would appreciate it. thanks, -Randy Did you try this: Technical Vikas Mehta +703-265-2011 vikas.me...@corp.aol.com NOC NOC +703-265-4662 opt 4 n...@atdn.net NOC Maintenance Notification+703-265-4662 opt 4 ma...@atdn.net On the side, a traceroute to AOL from my location in New York sent me from Chicago to Vienna, Austria, and then back to AOL... :) -- Ben
Re: Christchurch New Zealand
The other CERT: Community Emergency Response Team. Kind of off-topic for NANOG but I know that most of us are concerned with disaster recovery. This is the first local line. For US folks, there should be a CERT for you city or county, if not ask why. For Canadians, check with PEP. The CERT program trains you what to do when the offal hits the fan and the first responders are overloaded. https://www.citizencorps.gov/cert/about.shtm The Community Emergency Response Team (CERT) Program educates people about disaster preparedness for hazards that may impact their area and trains them in basic disaster response skills, such as fire safety, light search and rescue, team organization, and disaster medical operations. Using the training learned in the classroom and during exercises, CERT members can assist others in their neighborhood or workplace following an event when professional responders are not immediately available to help. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
