Re: Colocation providers and ACL requests
On Tue, Nov 1, 2011 at 8:00 PM, Jimmy Hess mysi...@gmail.com wrote: On Tue, Nov 1, 2011 at 1:22 PM, Kevin Loch kl...@kl.net wrote: We have always accommodated temporary ACL's for active DDOS attacks. I think that is fairly standard across the ISP/hosting industry. Indeed. We'll do it; ditto every reputable hosting, collocation, or IP transit shop I've come into contact with. And it's reasonable to accomodate the customer that asks, and reasonable for a customer to ask for a temporary ACL in such situations. However, it's also reasonable for the provider to refuse, and there's nothing wrong with that, unless the provider agreed that they would be willing to do that [...] Disagree. Furthermore, I think providers refusing to implement temporary ACLs should be called out on fora such as NANOG, to aid others in the vendor selection process. This is not to say it's sustainable as a repeat or permanent configuration -- possible up-sell and business drivers aside, TCAM exhaustion, performance implications, and man-hours required for ACL maintenance are all very real concerns -- but denying your customers this type of emergency response is bad for the Internet, and goes against basic tenets of customer service. -a
RE: BGP conf
This is a perfect example of why it is crucial that inbound route filters be scrupulously maintained in upstream BGP providers. Who knows who is out there. -Original Message- From: McCall, Gabriel [mailto:gabriel.mcc...@thyssenkrupp.com] Sent: Tuesday, November 01, 2011 7:29 PM To: Edward avanti; nanog@nanog.org Subject: Re: BGP conf Google for team cymru secure bgp template for a good starting point. -Original message- From: Edward avanti edward.ava...@gmail.com To: nanog@nanog.org nanog@nanog.org Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 Subject: BGP conf Halo, First, I accept this might not really right list for request, have use nsp cisco list but only first post to was succeed, sent several other for past 4 day and none appear (verified by list archive) so please excuse request. I am in need of a cisco config for BGP setup, we have a require to include IX peering at new location as well as our Verizon link, we like to take full bgp from Verizon and send to IX what they send us, I spend days reading google, and so many conflict web site example, so many example seem insecure no prefix list so on. end result to date is only sore eyes, would someone who do same (not need be Verizon) be kind to send us off list working running config (yes without your password heh) or at least how to apply to BGP router including access/prefix list and interfaces so we have an idea on what do, if you take two full BGP feed from two transit carrierin load share and IX, that good, because that our stage three plan, but I can work without two transit. I am not ignorant with cisco 7201, but am total newby to BGP. Best Thanks Edwardo This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: Mexico?
LACNIC http://lacnic.net/en/index.html On Thu, Oct 27, 2011 at 11:24:54PM -0400, Ryan Finnesey wrote: If I want to get a block of IP's issued for a network within Mexico who do I talk with? I have been told arin does not cover Mexico. It was my understand arin covers North America. Cheers Ryan -- true liberty is the right to be wrong
Performance Issues - PTR Records
I work for a regional ISP and very recently there has been an influx of calls reporting slowness when accessing certain websites (i.e google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the session, I have been able to pinpoint the latency at the application layer. After the tcp session has been established, it takes up to 15-20 seconds before the application begins sending data. The root of the problem was that the PTR record for our customer(s) address does not exist. As soon as the record is created, latency from the application is eliminated. This is analogous to latency when accessing a server over SSH when no PTR is available. A seperate packet capture from another customer exhibiting similar performance behavior showed many TCP retransmissions. At first glance, I assumed this was network related however this correlates with the application not responding and inducing retransmissions at the TCP layer (different symptoms, same problem). Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? Hope this is helpful as well -- -Matt Chung
Re: Performance Issues - PTR Records
On 11/2/2011 2:57 PM, Matt Chung wrote: snip! Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? HTTP has no requirement that the connecting client have reverse DNS setup. Some servers have reverse lookups enabled, and some of those undoubtedly block until the record has been retrieved or all avenues of discovery have been exhausted... and this is likely where the issue exists. As to why the server or the script/application its running needs the record, you'd have to ask the developer. -- Jeff Walter Network Engineer Hurricane Electric, AS6939 attachment: jeffw.vcf
IPV6 6to4 and 6In4 Lab
Hello folks, i'm posting this Message to both nanog and afnog lists preferably if i can get one from afnog to work with me a bit for routing IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like) i want to anounce my /48 optained from a friend as number) and 2002::/16 (6to4 prefixs=) at least for 10min to see real IPV6 traffic. if someone want to help me, please contact me thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (2002) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
RE: Performance Issues - PTR Records
From: Matt Chung [mailto:itsmemattch...@gmail.com] Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example. Well, once you choose to block by resolved name, now that site has to do a dns lookup for every incoming request to see if it resolves to a name that should be blocked. Just one example, but I'm sure there are countless others that also impede performance for IP addresses without a PTR record. David
Re: IPV6 6to4 and 6In4 Lab
Why don't you use just a tunnelbroker? I would take just a few minutes to setup a tunnel. From there, you can do a lot of stuff inside your network. My 2 cents /as On 1 Nov 2011, at 18:36, Meftah Tayeb wrote: Hello folks, i'm posting this Message to both nanog and afnog lists preferably if i can get one from afnog to work with me a bit for routing IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like) i want to anounce my /48 optained from a friend as number) and 2002::/16 (6to4 prefixs=) at least for 10min to see real IPV6 traffic. if someone want to help me, please contact me thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (2002) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: IPV6 6to4 and 6In4 Lab
like i say, no routing HE.Nett won accept me cause i don't have a AS number - Original Message - From: Arturo Servin arturo.ser...@gmail.com To: Meftah Tayeb tayeb.mef...@gmail.com Cc: nanog@nanog.org; af...@afnog.org Sent: Thursday, November 03, 2011 12:37 AM Subject: Re: IPV6 6to4 and 6In4 Lab Why don't you use just a tunnelbroker? I would take just a few minutes to setup a tunnel. From there, you can do a lot of stuff inside your network. My 2 cents /as On 1 Nov 2011, at 18:36, Meftah Tayeb wrote: Hello folks, i'm posting this Message to both nanog and afnog lists preferably if i can get one from afnog to work with me a bit for routing IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like) i want to anounce my /48 optained from a friend as number) and 2002::/16 (6to4 prefixs=) at least for 10min to see real IPV6 traffic. if someone want to help me, please contact me thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (2002) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (2002) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (2002) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Performance Issues - PTR Records
On Wed, Nov 02, 2011 at 06:12:21PM -0400, David Hubbard wrote: From: Matt Chung [mailto:itsmemattch...@gmail.com] Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example. That's even less effective than you'd naively expect, given that Indonesia's TLD is .id... - Matt
RE: Performance Issues - PTR Records
From: Matthew Palmer [mailto:mpal...@hezmatt.org] That's even less effective than you'd naively expect, given that Indonesia's TLD is .id... Umm yeah, simple typo, but I appreciate the help.
RE: Performance Issues - PTR Records
As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example. Well, once you choose to block by resolved name, now that site has to do a dns lookup for every incoming request to see if it resolves to a name that should be blocked. Another practical problem with this approach is that .IN is India but hey, at least it blocks something :-) -- -Barry Shein, that'd be .ID for Indonesia The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: Performance Issues - PTR Records
On Nov 2, 2011, at 5:57 PM, Matt Chung wrote: I work for a regional ISP and very recently there has been an influx of calls reporting slowness when accessing certain websites (i.e google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the session, I have been able to pinpoint the latency at the application layer. After the tcp session has been established, it takes up to 15-20 seconds before the application begins sending data. The root of the problem was that the PTR record for our customer(s) address does not exist. As soon as the record is created, latency from the application is eliminated. This is analogous to latency when accessing a server over SSH when no PTR is available. A seperate packet capture from another customer exhibiting similar performance behavior showed many TCP retransmissions. At first glance, I assumed this was network related however this correlates with the application not responding and inducing retransmissions at the TCP layer (different symptoms, same problem). Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? You're returning NXDOMAIN, right? If they're doing a reverse lookup and you return NXDOMAIN it should fail quickly, or else the application is even more horribly broken than just doing reverse lookups would imply. On the other hand, if you're not responding to the PTR request then that could be causing the timeout. -Ben
Re: BGP conf
Halo, sorry, my english not so perfect, at no time I mean send to IX what Verizon send me, I'm not THAT stupid hehe I mean if destination/origin is via IX, then send THAT traffic only by IX and not Verizon. On Thu, Nov 3, 2011 at 1:54 AM, Holmes,David A dhol...@mwdh2o.com wrote: This is a perfect example of why it is crucial that inbound route filters be scrupulously maintained in upstream BGP providers. Who knows who is out there. -Original Message- From: McCall, Gabriel [mailto:gabriel.mcc...@thyssenkrupp.com] Sent: Tuesday, November 01, 2011 7:29 PM To: Edward avanti; nanog@nanog.org Subject: Re: BGP conf Google for team cymru secure bgp template for a good starting point. -Original message- From: Edward avanti edward.ava...@gmail.com To: nanog@nanog.org nanog@nanog.org Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 Subject: BGP conf Halo, First, I accept this might not really right list for request, have use nsp cisco list but only first post to was succeed, sent several other for past 4 day and none appear (verified by list archive) so please excuse request. I am in need of a cisco config for BGP setup, we have a require to include IX peering at new location as well as our Verizon link, we like to take full bgp from Verizon and send to IX what they send us, I spend days reading google, and so many conflict web site example, so many example seem insecure no prefix list so on. end result to date is only sore eyes, would someone who do same (not need be Verizon) be kind to send us off list working running config (yes without your password heh) or at least how to apply to BGP router including access/prefix list and interfaces so we have an idea on what do, if you take two full BGP feed from two transit carrierin load share and IX, that good, because that our stage three plan, but I can work without two transit. I am not ignorant with cisco 7201, but am total newby to BGP. Best Thanks Edwardo This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: BGP conf
On Wed, Nov 2, 2011 at 7:50 PM, Edward avanti edward.ava...@gmail.com wrote: sorry, my english not so perfect, at no time I mean send to IX what Verizon send me, I'm not THAT stupid hehe I mean if destination/origin is via IX, then send THAT traffic only by IX and not Verizon. I understood what you mean. The recommendations in my earlier reply are still the best ones you've received: 1) hire a consultant to assist you both now and with any future problems or 2) do not worry about being multi-homed, because the extra complexity will do you more harm than good Imagine if you took your car to a shop and asked for new tires, and the mechanic said, well, I have never changed tires before and I'm not sure I have the right tools, but if you give me a couple of days I think I can read about it on the Internet and figure it out. Of course you would not buy tires from him, you would go to another shop. That mechanic would quickly find that, if he wants to sell tires, he needs to learn how to install them or hire someone to do it for him. What you are asking your boss/company to do is trust you to put tires on their car without the right tools or knowledge. The result of that is probably how your network will end up: a wreck. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Performance Issues - PTR Records
On Wed, Nov 2, 2011 at 6:08 PM, Barry Shein b...@world.std.com wrote: Another practical problem with this approach is that .IN is India but hey, at least it blocks something :-) There are also some services out there that block connections entirely, if the user doesn't have a PTR record. I'm thinking IRC servers, MUDs, and some other services with strange security policies that check for a port 113 IDENT response and RDNS to make a dark magic security decision to block a user who has no PTR. But in the modern world... more commonly, MTAs such as sendmail are often configured to require a valid PTR record. So as an ISP, you may be breaking your user's local MTA if you don't have the correct PTR for their IP addresses. So I would say following the RFCs and implementing the proper PTRs will help with that performance issue as a side-effect of having a valid zone, and head off other issues with possibly less popular services that are still blocking connections based on lack of proper PTR. :) -- -Barry Shein, that'd be .ID for Indonesia -- -JH
Re: BGP conf
On 11/2/2011 7:01 PM, Jeff Wheeler wrote: What you are asking your boss/company to do is trust you to put tires on their car without the right tools or knowledge. The result of that is probably how your network will end up: a wreck. Reminds me of the look on my original boss' face when I said, Well, I have no BGP experience, but I think I'm going to redo this entire BGP config. It doesn't look right. I then proceeded to try every ? hierarchy under bgp in the then cisco routers and read up on every command until I understood each one. Okay, it was simple, had no route-maps, and used access-lists instead of prefix-lists. It worked for a single 7206 BGP aggregation router. Now I have the mile long monstrosity that uses BGP communities for everything, and of route-maps/policies with prefix-lists for downstream customers. You have to start somewhere. cymru secure bgp templates is probably a good beginning. Careful study of your routing platform, what it supports, and reading up on what it means. If you don't understand something, use vendor specific lists/forums/documentation/google until you do. Jack
Re: Performance Issues - PTR Records
What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue. It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. On Wed, Nov 2, 2011 at 5:19 PM, Ben Jencks b...@bjencks.net wrote: On Nov 2, 2011, at 5:57 PM, Matt Chung wrote: I work for a regional ISP and very recently there has been an influx of calls reporting slowness when accessing certain websites (i.e google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the session, I have been able to pinpoint the latency at the application layer. After the tcp session has been established, it takes up to 15-20 seconds before the application begins sending data. The root of the problem was that the PTR record for our customer(s) address does not exist. As soon as the record is created, latency from the application is eliminated. This is analogous to latency when accessing a server over SSH when no PTR is available. A seperate packet capture from another customer exhibiting similar performance behavior showed many TCP retransmissions. At first glance, I assumed this was network related however this correlates with the application not responding and inducing retransmissions at the TCP layer (different symptoms, same problem). Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? You're returning NXDOMAIN, right? If they're doing a reverse lookup and you return NXDOMAIN it should fail quickly, or else the application is even more horribly broken than just doing reverse lookups would imply. On the other hand, if you're not responding to the PTR request then that could be causing the timeout. -Ben
Re: Performance Issues - PTR Records
PC wrote: What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue. It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. I think that returns SERVFAIL somewhere down the line? Does it make sense to reinforce the behaviour (good and bad terms left for another time), while looking forward to v6?
Generating IPv6 list with filtergen.level3.net
Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: Performance Issues - PTR Records
We really have no objections to creating records for our IPs however there was no compelling reason previously. With the manifestation of performance issues, we are currently creating a generic record for our addresses. I assumed that the applications would take absent records into consideration instead of waiting and timing out before responding with data. Trying to troubleshoot this issue from the limited visibility is difficult ; the latency the application is introducing is abstracted (unless I am unaware of that troubleshooting technique). Sent from my iPhone On Nov 2, 2011, at 5:58 PM, J na...@namor.ca wrote: PC wrote: What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue. It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. I think that returns SERVFAIL somewhere down the line? Does it make sense to reinforce the behaviour (good and bad terms left for another time), while looking forward to v6?
Re: Performance Issues - PTR Records
On Wed November 2 2011 20:27, Matt Chung wrote: I assumed that the applications would take absent records into consideration instead of waiting and timing out before responding with data. Trying to troubleshoot this issue from the limited visibility is difficult ; the latency the application is introducing is abstracted (unless I am unaware of that troubleshooting technique). When you mis-place your keys do you only look in one place and then give up? The calling server does not know there is no record until it exhausts its list of DNS servers, which is probably what is introducing the delay you are seeing (each server trying to find a PTR with each of its upsteams) until they all time out... -- Larry Smith lesm...@ecsis.net
Re: BGP conf
On Wed, Nov 2, 2011 at 8:44 PM, Jack Bates jba...@brightok.net wrote: Now I have the mile long monstrosity that uses BGP communities for everything, and of route-maps/policies with prefix-lists for downstream customers. You have to start somewhere. cymru secure bgp templates is probably a good beginning. I guess ten years of watching RIRs and users de-bogon new /8s didn't teach you why those Cymru examples are more dangerous than they are good. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Generating IPv6 list with filtergen.level3.net
Hi Courtney - Try something like: whois -h filtergen.level3.net AS3356 -cp -v6 or whois -h filtergen.level3.net AS3356 -cp -v4v6 Using AS7922 or something of that nature (currently I dont see any v6 routes registered under 7922.) -Kevin On Thu, 3 Nov 2011, Smith, Courtney wrote: Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: BGP conf
On 11/2/2011 8:58 PM, Jeff Wheeler wrote: On Wed, Nov 2, 2011 at 8:44 PM, Jack Batesjba...@brightok.net wrote: Now I have the mile long monstrosity that uses BGP communities for everything, and of route-maps/policies with prefix-lists for downstream customers. You have to start somewhere. cymru secure bgp templates is probably a good beginning. I guess ten years of watching RIRs and users de-bogon new /8s didn't teach you why those Cymru examples are more dangerous than they are good. Have to read the current cymru bgp templates? ! Team Cymru has removed all static bogon references from this template ! due to the high probability that the application of these bogon filters ! will be a one-time event. Unfortunately many of these templates are ! applied and never re-visited, despite our dire warnings that bogons do ! change. ! ! This doesn't mean bogon filtering can't be accomplished in an automated ! manner. Why not consider peering with our globally distributed bogon ! route-server project? Alternately you can obtain a current and well ! maintained bogon feed from our DNS and RADb services. Read more at the ! link below to learn how! ! ! https://www.team-cymru.org/Services/Bogons/
RE: Generating IPv6 list with filtergen.level3.net
Thanks!!! ~$ whois -h filtergen.level3.net RADB::AS7922 -v6 Prefix list for policy RADB::AS7922 = RADB::AS7922 2001:558::/29 2001:558::/31 2601::/28 ~$ Courtney Smith Network Engineer Comcast, National Engineering Technical Operations NOC:888.662.6386x2x2 http://as7922.peeringdb.com () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -Original Message- From: Kevin Epperson [mailto:epper...@colorado.edu] Sent: Wednesday, November 02, 2011 10:00 PM To: Smith, Courtney Cc: 'nanog@nanog.org' Subject: Re: Generating IPv6 list with filtergen.level3.net Hi Courtney - Try something like: whois -h filtergen.level3.net AS3356 -cp -v6 or whois -h filtergen.level3.net AS3356 -cp -v4v6 Using AS7922 or something of that nature (currently I dont see any v6 routes registered under 7922.) -Kevin On Thu, 3 Nov 2011, Smith, Courtney wrote: Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: Performance Issues - PTR Records
On Wed, Nov 2, 2011 at 8:33 PM, Larry Smith lesm...@ecsis.net wrote: On Wed November 2 2011 20:27, Matt Chung wrote: I assumed that the applications would take absent records into When you mis-place your keys do you only look in one place and then give up? The calling server does not know there is no record until it exhausts If the reverse zone is properly configured, but just the PTR record is missing, you get NXDOMAIN, which is not you mis-place your keys; it's someone told you authoritatively that your keys don't exist, never existed or no longer existed. If you ask where your key ring went, and Frodo Baggins informs you that it doesn't exist, because it was tossed down into a pool of magma on mount doom, and you trust his reply, you stop looking for it. The only way you don't trust a valid DNS reply is if you are implementing DNSSEC, and the authoritative proof of non-existence doesn't validate -- -JH
Re: BGP conf
On Wed, Nov 2, 2011 at 10:04 PM, Jack Bates jba...@brightok.net wrote: Have to read the current cymru bgp templates? ! manner. Why not consider peering with our globally distributed bogon ! route-server project? Alternately you can obtain a current and well I'm not telling you something you don't already know, but for the novices who regard this list as a source of expertise, I will explain in greater detail why this is a really dumb idea. If you took a list of bogons over eBGP from Cymru, you would get unused /8s and similar. What you don't get is a route that matches whatever silly thing someone on the DFZ accidentally leaked: a more-specific that will still cause you to route traffic to their leaked prefix out to the Internet (and presumably, to their network.) There is nothing good about this. It's just adding unnecessary complexity for no operational benefit. There is bad about it. It adds complexity and risk. What is that risk? If you decide that the Cymru distributed bogon route-server is for you, and simply rewrite next-hops received on that session to Null0, it is possible that Cymru could make an error, or otherwise introduce non-bogon routes into your network as if they were bogons, causing black-holes. This is obviously too much to risk for something that has no operational benefit. The Cymru guys do many positive things. One of the more questionable things they do, though, is operate a route-server with the intention of black-holing botnet CC IPs on a very wide scale. This is certainly a positive thing to do, but it was not done in a transparent manner; and in fact didn't even have management approval at Cogent when they configured it on their network. There was no established channel to find out why your IP address appeared on this list or to get it removed. All it took for me to get the whole idea canned at Cogent was one inquiry to management, asking why engineers had quietly started using a clandestine blackhole list operated by a third-party and would not give any answers to a customer if one of their IPs appeared on that list. The IP address I inquired about was certainly not a botnet CC node, and how it ended up on that list is a mystery. I'm not saying there was any malicious intent, but it was a mistake at least. Trusting that bogon black-hole list to do something you don't even need to do anyway is not smart. It's *especially* not smart for some novice who doesn't understand the implications of his decision. This is the danger of cut paste engineering. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: BGP conf
On 11/2/2011 9:58 PM, Jeff Wheeler wrote: I guess ten years of watching RIRs and users de-bogon new /8s didn't teach you why those Cymru examples are more dangerous than they are good. If you follow all the CYMRU examples and subscribe to the BGP bogon feed, that isn't an issue... Jeff
RE: BGP conf
Participants, This thread makes me want to LAUGH and VOMIT at the same time... This guy is asking for advice and all this list can do is poke and make fun at him for trying to learn the right way to do things... We ALL need to remember...NONE of us come out of the womb being BGP experts... and anyone who says they are...are lying through their teeth. I have had to work with such people who talked a big game...but in the end didn't know their ass from a hole in the ground. And to the original post Edward...if you follow team CYMRU you are pretty much on the right path to being successful in your ventures... -Original Message- From: Edward avanti [mailto:edward.ava...@gmail.com] Sent: Wednesday, November 02, 2011 7:51 PM To: Holmes, David A; nanog@nanog.org Subject: Re: BGP conf Halo, sorry, my english not so perfect, at no time I mean send to IX what Verizon send me, I'm not THAT stupid hehe I mean if destination/origin is via IX, then send THAT traffic only by IX and not Verizon. On Thu, Nov 3, 2011 at 1:54 AM, Holmes,David A dhol...@mwdh2o.com wrote: This is a perfect example of why it is crucial that inbound route filters be scrupulously maintained in upstream BGP providers. Who knows who is out there. -Original message- From: Edward avanti edward.ava...@gmail.com To: nanog@nanog.org nanog@nanog.org Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 Subject: BGP conf Halo, First, I accept this might not really right list for request, have use nsp cisco list but only first post to was succeed, sent several other for past 4 day and none appear (verified by list archive) so please excuse request. I am in need of a cisco config for BGP setup, we have a require to include IX peering at new location as well as our Verizon link, we like to take full bgp from Verizon and send to IX what they send us, I spend days reading google, and so many conflict web site example, so many example seem insecure no prefix list so on. end result to date is only sore eyes, would someone who do same (not need be Verizon) be kind to send us off list working running config (yes without your password heh) or at least how to apply to BGP router including access/prefix list and interfaces so we have an idea on what do, if you take two full BGP feed from two transit carrierin load share and IX, that good, because that our stage three plan, but I can work without two transit. I am not ignorant with cisco 7201, but am total newby to BGP. Best Thanks Edwardo This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
