Re: [VoiceOps] (cross post) VoIP heat charts...
http://www.nanpa.com/nanp1/allutlzd.zip lists NPANXX and Ratecentre. How does number portability interact with this? What fraction of numbers have been ported? (Where should I look/google to find the answer?) -- These are my opinions. I hate spam.
Re: best practice for advertising peering fabric routes
On Wednesday, January 15, 2014 09:57:32 AM Michael Hallgren wrote: I don't think you need route-reflection in a 5 node iBGP. I'm for doing it now and not worrying about it later. Also, don't originate your routes from your peering router Mark. signature.asc Description: This is a digitally signed message part.
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 12:02 AM, Dobbins, Roland rdobb...@arbor.net wrote: Again, folks, this isn't theoretical. When the particular attacks cited in this thread were taking place, I was astonished that the IXP infrastructure routes were even being advertised outside of the IXP network, because of these very issues. I know a lot of people push next-hop-self, and if you're a large ISP with thousands of BGP customers is pretty much required to scale. However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations. There are networks where fast convergence is more important than route scaling, and thus the traditional design of BGP next-hops being edge interfaces, and edge interfaces in the IGP performs better. By attempting to force IX participants to not put the route in IGP, those IX participants are collectively deciding on a slower converging network for everyone. I don't like a world where connecting to an exchange point forces a particular network design on participants. IXPs are not the problem when it comes to breaking PMTU-D. The problem is largely with enterprise networks, and with 'security' vendors who've propagated the myth that simply blocking all ICMP somehow increases 'security'. That's some circular reasoning. Networks won't 9K peer at exchange points for a number of reasons, including PMTU-D discovery issues. Since there are virtual no 9K peering at exchange points, PMTU-D is a non-issue. Maybe if IXP design didn't break PMTU-D it would help attract more 9K peers, or there might even be a future where 9K peering was required? This whole problem smacks to me of exchange points that are too big to fail. Since some of these exchanges are so big, everyone else must bend to their needs. I think the world would be a better place if some of these were broken up into smaller exchanges and they imposed less restrictions on their participants. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 9:18 PM, Leo Bicknell bickn...@ufp.org wrote: However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations. There are networks where fast convergence is more important than route scaling, and thus the traditional design of BGP next-hops being edge interfaces, and edge interfaces in the IGP performs better. A good engineer also knows that there are huge drawbacks to having a peer's network infrastructure DDoSed, routes flapping, core bandwidth consumed by tens and hundreds of gb/sec of attack traffic, et. al., too. ; By attempting to force IX participants to not put the route in IGP, those IX participants are collectively deciding on a slower converging network for everyone. I don't like a world where connecting to an exchange point forces a particular network design on participants. Concur. But that's the world we live in, unfortunately. It's just another example of the huge, concentric nature of the collateral damage arising from DDoS attacks, both from the attacks themselves, and from the compromises folks have to make in order to increase resilience against such attacks. That's some circular reasoning. Not really. What I'm saying is that since PMTU-D is already broken on so many endpoint networks - i.e., where traffic originates and where it terminates - that any issues arising from PMTU-D irregularities in IXP networks are trivial by comparison. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton signature.asc Description: Message signed with OpenPGP using GPGMail
Re: best practice for advertising peering fabric routes
On (2014-01-15 08:18 -0600), Leo Bicknell wrote: I know a lot of people push next-hop-self, and if you're a large ISP with thousands of BGP customers is pretty much required to scale. It's actually the polar opposite. If you are small, there are no compelling reasons to put IXP in IGP. If you are large, you may wish to have different IGP metric to two egress points in same peering router. In which case you should at very least have IP ACL in IXP interface which only allows LAN2LAN. -- ++ytti
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 8:49 AM, Dobbins, Roland rdobb...@arbor.net wrote: Not really. What I'm saying is that since PMTU-D is already broken on so many endpoint networks - i.e., where traffic originates and where it terminates - that any issues arising from PMTU-D irregularities in IXP networks are trivial by comparison. I think we're looking at two different aspects of the same issue. I believe you're coming at it from a 'for all users of the Internet, what's the chance they have connectivity that does not break PMTU-D.' That's an important group to study, particularly for those DSL users still left with 1500 byte MTU's. And you're right, for those users IXP's are the least of their worries, mostly it's content-side poor networking, like load balancers and firewalls that don't work correctly. I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?' I'm the network guy who wants to buy transit in the US, and transit in Germany and run a tunnel of 1500 byte packets end to end, necessitating a ~1540 byte packet. Finding transit providers who will configure jumbo frames is trivial these days, and most backbones are jumbo frame clean (at least to 4470, but many to 9K). There's probably about a 25% chance private peelings are also jumbo clean. Pretty much the only thing broken for this use case is IXP's. Only a few have a second VLAN for 9K peerings, and most participants don't use it for a host of reasons, including PMTU-D problems. I'm an oddball. I think MPLS VPN's are a terrible idea for the consumer, locking them into a single provider in the vast majority of cases. Consumers would be better served by having a tunnel box (IPSec maybe?) at their edge and running there own tunnel over IP provider-independently, if they could get 1500B MTU at the edge, and move those packets end to end. While I've always thought that, in the post-Snowden world I think I seem a little less crazy, rather than relying on your provider to keep your VPN traffic secret, customers should be encrypting it in a device they own. But hey, I get why ISP's don't want to offer 9K MTU clean paths end to end. Customers could then buy a VPN appliance and manage their own VPN's with no vendor lock-in. MPLS VPN revenues would tumble, and customers would move more fluidly between providers. That's terrible if you're an ISP. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 10:31 PM, Leo Bicknell bickn...@ufp.org wrote: I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?' I understand that perspective, absolutely. But what I'm saying is that that whether or not they want to use jumbo frames for Internet traffic, it doesn't matter, because PMTU-D is likely to be broken either at the place where the traffic is initiated, the place where the traffic is received, or both - so any nonsense in the middle, especially on IXP networks in particular, isn't really a significant issue in and of itself. If we could get things optimized and remediated to the point where potential PMTU-D breakage in IXP networks were a significant issue of iteself, the Internet would be much improved. But I don't see any likelihood of that happening anytime soon. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton signature.asc Description: Message signed with OpenPGP using GPGMail
Re: best practice for advertising peering fabric routes
On Tue, Jan 14, 2014 at 10:11 PM, Patrick W. Gilmore patr...@ianai.net wrote: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. Doing so endangers your peers the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they can't do this. Hi Patrick, I have to disagree with you. If it appears in a traceroute to somewhere else, I'd like to be able to ping and traceroute directly to it. When I can't, that impairs my ability to troubleshoot the all too common can't-get-there-from-here problems. The more you hide the infrastructure, the more intractable problems become for your customers. The IXP LAN should be reachable from every device on the ASes which connect to it, not just the immediate router. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 9:37 AM, Dobbins, Roland rdobb...@arbor.net wrote: But what I'm saying is that that whether or not they want to use jumbo frames for Internet traffic, it doesn't matter, because PMTU-D is likely to be broken either at the place where the traffic is initiated, the place where the traffic is received, or both - so any nonsense in the middle, especially on IXP networks in particular, isn't really a significant issue in and of itself. Your assertion does not match my deployment experience. When I have deployed endpoints that have working PMTU-D, I have 99.999% success with the ISP's in the middle having working PMTU-D. It even works fine for 9K providers connected to 1500B exchange points, because the packet-too-big typically originates from the input side of the router (the backbone link to the IXP router). Indeed, the only place I've seen it broken is where the ISP 9K peers at an exchange, and the far end ISP runs a 9K backbone (like 4470), so the far end IXP-router does the packet-to-big, and originates it from the exchange LAN, which because it's no longer in the table fails to past uRPF. (Business class) ISP's don't break PMTU-D, end users break it with the equipment they connect. So a smart user connecting equipment that is properly configured should be able to expect it to work properly. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 10:44 , William Herrin b...@herrin.us wrote: On Tue, Jan 14, 2014 at 10:11 PM, Patrick W. Gilmore patr...@ianai.net wrote: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. Doing so endangers your peers the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they can't do this. Hi Patrick, I have to disagree with you. If it appears in a traceroute to somewhere else, I'd like to be able to ping and traceroute directly to it. When I can't, that impairs my ability to troubleshoot the all too common can't-get-there-from-here problems. The more you hide the infrastructure, the more intractable problems become for your customers. The IXP LAN should be reachable from every device on the ASes which connect to it, not just the immediate router. We disagree. Plus, you really can't type ping on the router connected to the IXP? _If_ you can guarantee your network has zero bots, abusable [DNS|NTP|etc.] servers, all your downstreams are perfectly clean, etc., etc., then maybe I could see you carrying it in your IGP. As I know 100% of ISPs (to at least one decimal place) cannot make such a guarantee, then doing so puts the IXP and all other members - whether peers of yours or not - at risk. Putting others at risk because you are lazy or because it makes your life easier is .. I believe I called it bad manners before. But let's take the philosophical out of this. The prefix in question is owned by the IXP. I said in an earlier post that if you carry a prefix I own, did not announce to you, and make it very clear I specifically do not want you to carry, I will ask you to stop or face possible disconnection. You may claim convergence (a bit of BS), troubleshooting (non-issue, IMO), or even but I wnt to!!1!1! (whatever). Doesn't matter. That's not your prefix, you were not given it and told not to carry it, so Do Not Carry It. Ask your IXP if they mind whether you carry the prefix. See what they say. -- TTFN, patrick
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 10:52 PM, Leo Bicknell bickn...@ufp.org wrote: (Business class) ISP's don't break PMTU-D, end users break it with the equipment they connect. Concur 100%. That's my point. So a smart user connecting equipment that is properly configured should be able to expect it to work properly. In my deployment experience, many (most?) end-user organization break PMTU-D to/through their LANs outside of their IDCs, much less to the Internet, for themselves, and for everyone who wishes to communicate with them across the Internet. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton signature.asc Description: Message signed with OpenPGP using GPGMail
RE: best practice for advertising peering fabric routes
UUnet once advertised the /24 for MAE-East to me (well, Net99), and because I also had it in my IGP, my network was using UUnet's backbone for west-to-east coast traffic for a couple of days until I noticed and fixed it (with next-hop-self). I agree 100% with Patrick and others on this point. No good can come from propagating IXP address space any further than is absolutely necessary. Best not to propagate it at all. Dave -Original Message- From: Patrick W. Gilmore [mailto:patr...@ianai.net] Sent: Wednesday, January 15, 2014 8:57 AM To: NANOG list Subject: Re: best practice for advertising peering fabric routes On Jan 15, 2014, at 10:44 , William Herrin b...@herrin.us wrote: On Tue, Jan 14, 2014 at 10:11 PM, Patrick W. Gilmore patr...@ianai.net wrote: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. Doing so endangers your peers the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they can't do this. Hi Patrick, I have to disagree with you. If it appears in a traceroute to somewhere else, I'd like to be able to ping and traceroute directly to it. When I can't, that impairs my ability to troubleshoot the all too common can't-get-there-from-here problems. The more you hide the infrastructure, the more intractable problems become for your customers. The IXP LAN should be reachable from every device on the ASes which connect to it, not just the immediate router. We disagree. Plus, you really can't type ping on the router connected to the IXP? _If_ you can guarantee your network has zero bots, abusable [DNS|NTP|etc.] servers, all your downstreams are perfectly clean, etc., etc., then maybe I could see you carrying it in your IGP. As I know 100% of ISPs (to at least one decimal place) cannot make such a guarantee, then doing so puts the IXP and all other members - whether peers of yours or not - at risk. Putting others at risk because you are lazy or because it makes your life easier is .. I believe I called it bad manners before. But let's take the philosophical out of this. The prefix in question is owned by the IXP. I said in an earlier post that if you carry a prefix I own, did not announce to you, and make it very clear I specifically do not want you to carry, I will ask you to stop or face possible disconnection. You may claim convergence (a bit of BS), troubleshooting (non-issue, IMO), or even but I wnt to!!1!1! (whatever). Doesn't matter. That's not your prefix, you were not given it and told not to carry it, so Do Not Carry It. Ask your IXP if they mind whether you carry the prefix. See what they say. -- TTFN, patrick
Re: best practice for advertising peering fabric routes
On Wed, Jan 15, 2014 at 10:57 AM, Patrick W. Gilmore patr...@ianai.net wrote: On Jan 15, 2014, at 10:44 , William Herrin b...@herrin.us wrote: I have to disagree with you. If it appears in a traceroute to somewhere else, I'd like to be able to ping and traceroute directly to it. When I can't, that impairs my ability to troubleshoot the all too common can't-get-there-from-here problems. The more you hide the infrastructure, the more intractable problems become for your customers. The IXP LAN should be reachable from every device on the ASes which connect to it, not just the immediate router. We disagree. Plus, you really can't type ping on the router connected to the IXP? Not when I'm the downstream customer, no. It's jolly good that *you* can test, but before the rest of us can get through the layers of support which insulate you, we have to be able to convincingly test too. As I know 100% of ISPs (to at least one decimal place) cannot make such a guarantee, then doing so puts the IXP and all other members - whether peers of yours or not - at risk. Putting others at risk because you are lazy or because it makes your life easier is .. I believe I called it bad manners before. That makes no sense. The IXP is at no more or less risk from your customers than any other connection you have for Internet carriage. Risk which you are responsible for managing either way. I said in an earlier post that if you carry a prefix I own, did not announce to you, and make it very clear I specifically do not want you to carry, I will ask you to stop or face possible disconnection. [...] That's not your prefix, you were not given it and told not to carry it, so Do Not Carry It. Well yes, of course. If you participate in an IXP you follow the rules of the IXP. I respectfully question the wisdom of such a rule and the IXPs I deal with only ask that you not announce the IXP prefix externally. But it's not OK to unilaterally break the IXP's rules, however poorly conceived. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: best practice for advertising peering fabric routes
On 1/14/14, 8:41 PM, Patrick W. Gilmore wrote: I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device except those directly attached to that LAN. Period. So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ) Jim Shankland
Re: best practice for advertising peering fabric routes
On 2014-01-15, at 12:04, Jim Shankland na...@shankland.org wrote: On 1/14/14, 8:41 PM, Patrick W. Gilmore wrote: I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device except those directly attached to that LAN. Period. So ... RFC1918 addresses for the IXP fabric, then? I've heard apparently non-drunk people suggest IPv6 link-local addresses as BGP endpoints across exchanges, too. (Half kidding, but still ) RFC 6752. One observation on this thread: some networks have customers who react badly to unusual things seen in traceroute. Sometimes the margin on an individual customer is low enough that one support call displaces any profit you were going to make off them this month. It's understandable to me that such network operators would choose to carry IXP routes internally in order to avoid that potential support burden. I don't pretend to have any universal good/bad answer to the original question, though. I don't think the world is that simple. Joe signature.asc Description: Message signed with OpenPGP using GPGMail
Amazon AWS Engineer
Could an Amazon AWS Engineer contact me off list. We're seeing what is perceived to be performance issues and I'd like to discuss what the expected performance should be. The Amazon AWS support channels don't appear to be meant for network type question. Thanks /Ryan Ryan Harden Senior Network Engineer University of Chicago - AS160 P: 773-834-5441 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: best practice for advertising peering fabric routes
* na...@shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ) They need to be globally unique. -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: best practice for advertising peering fabric routes
* patr...@ianai.net (Patrick W. Gilmore) [Wed 15 Jan 2014, 04:36 CET]: [..] NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. This is correct, and protects both your (ISP) infrastructure and the IXP's. All major European IXPs revisited their policy after the giant DDoS attack on CloudFlare, and the above was pretty much the outcome. -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: gmail.com - 550 error for ipv6/PTR ?
On 1/14/2014 4:06 PM, Brandon Applegate wrote: Just saw this in a message tonight. No idea if this is a transient error or not. --- host gmail-smtp-in.l.google.com [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records and authentication 550-5.7.1 . Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error [support.google.com] for more 550 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA command) I saw a number of these as well but in my case the bracketed IP addresses were malformed. For example: host gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines...
Re: gmail.com - 550 error for ipv6/PTR ?
On Jan 15, 2014, at 10:05 AM, Darren Pilgrim na...@bitfreak.org wrote: On 1/14/2014 4:06 PM, Brandon Applegate wrote: Just saw this in a message tonight. No idea if this is a transient error or not. --- host gmail-smtp-in.l.google.com [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records and authentication 550-5.7.1 . Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error [support.google.com] for more 550 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA command) I saw a number of these as well but in my case the bracketed IP addresses were malformed. For example: host gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines... https://support.google.com/mail/answer/81126?hl=en#authentication Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: best practice for advertising peering fabric routes
On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker niels=na...@bakker.net wrote: * na...@shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ) They need to be globally unique. do they? :) also... there is/was an exchange in south america (columbia maybe? it's been a while since I saw this in configs) that used 192.168.0.0/16 space for their exchange.
Re: best practice for advertising peering fabric routes
On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker niels=na...@bakker.net wrote: * na...@shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ) They need to be globally unique. Hi Niels, Actually, they don't. To meet the basic definition of working, they just have to be able to originate ICMP destination unreachable packets with a reasonable expectation that the recipient will receive those packets. Global uniqueness is not required for that. However, RFC1918 addresses don't meet the requirement for a different reason: they're routinely dropped at AS borders, thus don't have an expectation of reaching the external destination. Of course working, monitorable and testable are three different things. If my NMS can't reach the IXP's addresses, my view of the IXP is impaired. And the Internet is broken is not a trouble report that leads to a successful outcome with customer support... it helps to be able to pin things down with some specificity. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: gmail.com - 550 error for ipv6/PTR ?
On 1/15/2014 10:14 AM, Franck Martin wrote: On Jan 15, 2014, at 10:05 AM, Darren Pilgrim na...@bitfreak.org mailto:na...@bitfreak.org wrote: On 1/14/2014 4:06 PM, Brandon Applegate wrote: Just saw this in a message tonight. No idea if this is a transient error or not. --- host gmail-smtp-in.l.google.com http://gmail-smtp-in.l.google.com [gmail-smtp-in.l.google.com http://gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records and authentication 550-5.7.1 . Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error [support.google.com http://support.google.com] for more 550 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA command) I saw a number of these as well but in my case the bracketed IP addresses were malformed. For example: host gmail-smtp-in.l.google.com http://gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines... https://support.google.com/mail/answer/81126?hl=en#authentication My point was that Google told me it rejected 2607:fc50:1000:1f00::2 16. In this case, 2607:fc50:1000:1f00::2 is the correct address, but it appeared (to me) that Google's data was somehow corrupt. I'm pretty sure the IPv6 address format doesn't allow spaces. ;)
Re: best practice for advertising peering fabric routes
On Wed, Jan 15, 2014 at 1:26 PM, William Herrin b...@herrin.us wrote: On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker niels=na...@bakker.net wrote: * na...@shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ) They need to be globally unique. Hi Niels, Actually, they don't. To meet the basic definition of working, they just have to be able to originate ICMP destination unreachable packets with a reasonable expectation that the recipient will receive those packets. Global uniqueness is not required for that. However, RFC1918 addresses don't meet the requirement for a different reason: they're routinely dropped at AS borders, thus don't have an expectation of reaching the external destination. Of course working, monitorable and testable are three different things. If my NMS can't reach the IXP's addresses, my view of the IXP is impaired. And the Internet is broken is not a trouble report that leads to a successful outcome with customer support... it helps to be able to pin things down with some specificity. Regards, Bill Herrin Using RFC1918 would incur the assumption that one will need to use a unique router or routing instance for every exchange connected to since exchanges are likely to have overlapping space at that point (RFC1918 IXP registry anyone?). I don't think it'd be a good idea to go down that path.. Also mentioned in a past nanog was the idea of potentially getting someone like team cymru to setup all exchange prefixes in a special bogon list and you could null route on your edge all those prefixes.. I inquired to team cymru about this back when originally discussed but never got anywhere with them. -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- [stillwa...@gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwa...@gmail.com ~]$
Re: best practice for advertising peering fabric routes
On Jan 15, 2014, at 10:26 AM, William Herrin b...@herrin.us wrote: Of course working, monitorable and testable are three different things. If my NMS can't reach the IXP's addresses, my view of the IXP is impaired. And the Internet is broken is not a trouble report that leads to a successful outcome with customer support... it helps to be able to pin things down with some specificity. This approach concerns me for a number of reasons. First, having your NMS ping your upstream’s IXP peers probably doesn’t scale. If I’m a peer of a reasonably large provider, I’m pretty sure I don’t want all their customers hammering my management plane. Even if you’re the only one doing it, you also don’t know if I’m rate-limiting pings for that or any other reason. Second, what information do you get that you didn’t already have? If you saw the IP in a traceroute then you know it exists, is alive, is in the path, and a rough estimation of the latency. Pinging it may even give you negative information. Platforms vary and all, but in my experience pinging a router, especially a potentially busy one peering at an IXP, shows notably worse performance than “real” traffic experiences (admittedly somewhat true of TTL Expired responses, but less so in my experience). Now you’re potentially seeing high latency and packet loss which in reality might not even be there at all. Third, you don’t know that your ping to the peering IP is even taking the same path as the packets addressed to the real destination. MTR for example looks nice, but it would probably be more accurate if it simply ran the traceroute over and over instead of pinging each hop directly. You would also detect path changes for the real destination that pinging intermediate hops wouldn’t show you. While I appreciate the desire to be able to do as much of your own detective work as possible, I can also see where you’re now shifting workload onto someone else’s support organization when they’re not necessarily the problem either (“Hey, my NMS says your peering router is causing latency and packet loss, fix it!”). I’m also not saying there isn’t a troubleshooting gap caused by this. I’m just not sure being able to ping the IXP hop solves that problem either. Semi-related tangent: Working in an IXP setting I have seen weird corner cases cause issues in conjunction with the IXP subnet existing in BGP. Say someone’s got proxy ARP enabled on their router (sadly, more common than it should be, and not just from noobs at startups). Now say your IXP is growing and you expand the subnet. No matter how much you harp on the customers to make the change, they don’t all do it at once. Someone announces the new, larger subnet in BGP. Now when anyone ARPs for IPs in the new part of the range, proxy ARP guy (still on the smaller subnet) says “hey I have a route for that, send it here”. That was fun to troubleshoot. :) -c
Re: best practice for advertising peering fabric routes
* c...@bloomcounty.org (Clay Fiske) [Wed 15 Jan 2014, 20:34 CET]: Semi-related tangent: Working in an IXP setting I have seen weird corner cases cause issues in conjunction with the IXP subnet existing in BGP. Say someone’s got proxy ARP enabled on their router (sadly, more common than it should be, and not just from noobs at startups). Now say your IXP is growing and you expand the subnet. No matter how much you harp on the customers to make the change, they don’t all do it at once. Someone announces the new, larger subnet in BGP. Now when anyone ARPs for IPs in the new part of the range, proxy ARP guy (still on the smaller subnet) says “hey I have a route for that, send it here”. That was fun to troubleshoot. :) Proper run IXPs pay engineers to hunt down people with Proxy ARP enabled on their peering interfaces. -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: best practice for advertising peering fabric routes
* b...@herrin.us (William Herrin) [Wed 15 Jan 2014, 19:27 CET]: On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker niels=na...@bakker.net wrote: * na...@shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ) They need to be globally unique. Actually, they don't. To meet the basic definition of working, they just have to be able to originate ICMP destination unreachable packets with a reasonable expectation that the recipient will receive those packets. Global uniqueness is not required for that. However, RFC1918 addresses don't meet the requirement for a different reason: they're routinely dropped at AS borders, thus don't have an expectation of reaching the external destination. They need to be globally unique because otherwise a connected network might be using them already internally, thus keeping them from connecting - or as another followup mail stated, force everything into their own VRFs, and that may still collide. This was rehashed a few years ago on the RIPE AP-WG mailing list, IIRC. -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: gmail.com - 550 error for ipv6/PTR ?
On Jan 15, 2014, at 10:56 AM, Darren Pilgrim na...@bitfreak.org wrote: On 1/15/2014 10:14 AM, Franck Martin wrote: On Jan 15, 2014, at 10:05 AM, Darren Pilgrim na...@bitfreak.org mailto:na...@bitfreak.org wrote: On 1/14/2014 4:06 PM, Brandon Applegate wrote: Just saw this in a message tonight. No idea if this is a transient error or not. --- host gmail-smtp-in.l.google.com http://gmail-smtp-in.l.google.com [gmail-smtp-in.l.google.com http://gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records and authentication 550-5.7.1 . Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error [support.google.com http://support.google.com] for more 550 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA command) I saw a number of these as well but in my case the bracketed IP addresses were malformed. For example: host gmail-smtp-in.l.google.com http://gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines... https://support.google.com/mail/answer/81126?hl=en#authentication My point was that Google told me it rejected 2607:fc50:1000:1f00::2 16. In this case, 2607:fc50:1000:1f00::2 is the correct address, but it appeared (to me) that Google's data was somehow corrupt. I'm pretty sure the IPv6 address format doesn't allow spaces. ;) Ah yes, the confusion with the separator between IP and ports. IPv4:port IPv6.port That gets a lot of regex confused... signature.asc Description: Message signed with OpenPGP using GPGMail
Internet Routing Registries - RADb, etc
Can someone provide a little guidance on RADb (and other IRRs)? Our organization is not a customer of any IRRs, but our ARIN IP allocation is registered in RADb and Level3's IRR. The majority of these entries are incorrect and list other AS#'s (AS's that have never been authorized to announce this IP space) as the originating AS for our ARIN IP allocation. I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response. Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)? Thanks in advance, --Blake
Re: Internet Routing Registries - RADb, etc
On 15/01/2014 21:22, Blake Hudson wrote: I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response. Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)? It depends. Most organisations do not use IRRDBs for compiling prefix lists, but some do. If you happen to get service from one of these organisations, it's better to ensure that the prefixes are correctly registered. Lots of European IXPs use IRRDBs for route-server prefix filter lists, but this may not be relevant to you. Level3 fills their IRRDB up with piles of crap. Good luck getting them to remove anything. RADB is well run, and if Cogent can't get their act together enough to remove the entries from there, you can email Merit directly (radb-supp...@merit.edu) and they can delete stuff, assuming that source: is RADB and you can prove that you legitimately hold the address space. Nick
Re: Internet Routing Registries - RADb, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Or perhaps this indicates that no one pays attention to what is in the RAdb, and therefore makes a statement about the RAdb itself? No idea myself... - - ferg On 1/15/2014 1:22 PM, Blake Hudson wrote: Can someone provide a little guidance on RADb (and other IRRs)? Our organization is not a customer of any IRRs, but our ARIN IP allocation is registered in RADb and Level3's IRR. The majority of these entries are incorrect and list other AS#'s (AS's that have never been authorized to announce this IP space) as the originating AS for our ARIN IP allocation. I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response. Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)? Thanks in advance, --Blake - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLW/kkACgkQKJasdVTchbJL0AD/eU+UD9adD33gOw3YHyD8TjaE l2ISHTI628wbF+jZSmUA/0rj0WrWrba6HqCrNsnhgIp2DClJqCYLAD8m0a1xbtG7 =coKB -END PGP SIGNATURE-
Re: gmail.com - 550 error for ipv6/PTR ?
On Wed, Jan 15, 2014 at 12:05 PM, Darren Pilgrim na...@bitfreak.org wrote: host gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines... I could not reproduce the error during a telnet test. However, I see a substantial number of outgoing 550 5.7.1 rejects that look just like that, mixed in with accepted mail to gmail.com. So it would appear to be transient, but ongoing. And more than a bit troublesome, since it is shown as a 550 reject, and delivery therefore will not be deferred and retried appropriately. Jan 15 15:41:29 [...] Failed Site gmail.com (2607:f8b0:4002:c01::1a) said after data sent: 550 5.7.1 more information. q48si1281225yhb.127 - gsmtp 550-5.7.1 [2607:f360:0:1f0::40:2f00 12] Our system has detected that this -- -JH
Re: gmail.com - 550 error for ipv6/PTR ?
Ah yes, the confusion with the separator between IP and ports. IPv4:port IPv6.port That gets a lot of regex confused... Especially since IPv4:port works, while IPv6:port usually does not and you usually need [ipv6]:port. Owen
RE: Internet Routing Registries - RADb, etc
I 100% agree with Nick. But, in dealing with Level3, you need Level3 Members Remarks in your objects to deal with multiple registries etc. They have an ok system that is a nightmare to pull from different datasources with them and they've churned the ultimately responsible individual a few times which makes it tough to get someone knowledgeable. Larry and team however at RADB will respond to remove your entries from someone else's stale records without much hassle. Cogent will use your IRR data to generate a list the first time but they don't have a clue when it comes to keeping up to date. The underlying problem is that there is incentive to enter objects (or have them entered for you) but none to remove old/stale/incorrect objects. Eric -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Wednesday, January 15, 2014 3:31 PM To: Blake Hudson; nanog@nanog.org Subject: Re: Internet Routing Registries - RADb, etc On 15/01/2014 21:22, Blake Hudson wrote: I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response. Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)? It depends. Most organisations do not use IRRDBs for compiling prefix lists, but some do. If you happen to get service from one of these organisations, it's better to ensure that the prefixes are correctly registered. Lots of European IXPs use IRRDBs for route-server prefix filter lists, but this may not be relevant to you. Level3 fills their IRRDB up with piles of crap. Good luck getting them to remove anything. RADB is well run, and if Cogent can't get their act together enough to remove the entries from there, you can email Merit directly (radb-supp...@merit.edu) and they can delete stuff, assuming that source: is RADB and you can prove that you legitimately hold the address space. Nick
Proxy ARP detection (was re: best practice for advertising peering fabric routes)
On Jan 15, 2014, at 12:46 PM, Niels Bakker niels=na...@bakker.net wrote: * c...@bloomcounty.org (Clay Fiske) [Wed 15 Jan 2014, 20:34 CET]: Semi-related tangent: Working in an IXP setting I have seen weird corner cases cause issues in conjunction with the IXP subnet existing in BGP. Say someone’s got proxy ARP enabled on their router (sadly, more common than it should be, and not just from noobs at startups). Now say your IXP is growing and you expand the subnet. No matter how much you harp on the customers to make the change, they don’t all do it at once. Someone announces the new, larger subnet in BGP. Now when anyone ARPs for IPs in the new part of the range, proxy ARP guy (still on the smaller subnet) says “hey I have a route for that, send it here”. That was fun to troubleshoot. :) Proper run IXPs pay engineers to hunt down people with Proxy ARP enabled on their peering interfaces. Yes, yes, I expected a smug reply like this. I just didn’t expect it to take so long. But how can I detect proxy ARP when detecting proxy ARP was patented in 1996? http://www.google.com/patents/US5708654 Seriously though, it’s not so simple. You only get replies if the IP you ARP for is in the offender’s route table (or they have a default route). I’ve seen different routers respond depending on which non-local IP was ARPed for. And while using something like 8.8.8.8 might be an obvious choice, I don’t care to hose up everyone’s connectivity to it just to find local proxy ARP offenders on my network. -c
Re: OpenNTPProject.org
On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT or compared, getting same 0 RTT penalty as UDP without reflection potential. I wouldn't say trivial, but QUIC and MinimaLT are hopefully the future. The near future, I hope! For now I'd just like to mention that OpenNTPD, from the OpenBSD project, is immune to the kind of large NTP amplification attacks now being discussed. It's certainly a good fit for some organizations/setups. http://www.openntpd.org Nicolai
Re: Proxy ARP detection
* c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:35 CET]: [...] Seriously though, it’s not so simple. You only get replies if the IP you ARP for is in the offender’s route table (or they have a default route). I’ve seen different routers respond depending on which non-local IP was ARPed for. And while using something like 8.8.8.8 might be an obvious choice, I don’t care to hose up everyone’s connectivity to it just to find local proxy ARP offenders on my network. You'll never be entirely sure but obviously you're not limited to sending only one ARP request - this isn't The Hunt For The Red October movie. We're talking a common misconfiguration here in this thread - or at least you were, two mails upthread. How will checking for Proxy ARP possibly hose up anybody's connectivity? You realise that ARP replies are unicast, right? And that IXPs generally have dedicated servers for monitoring from which they can source packets? -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: Proxy ARP detection
On Jan 15, 2014, at 3:47 PM, Niels Bakker niels=na...@bakker.net wrote: * c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:35 CET]: [...] Seriously though, it’s not so simple. You only get replies if the IP you ARP for is in the offender’s route table (or they have a default route). I’ve seen different routers respond depending on which non-local IP was ARPed for. And while using something like 8.8.8.8 might be an obvious choice, I don’t care to hose up everyone’s connectivity to it just to find local proxy ARP offenders on my network. You'll never be entirely sure but obviously you're not limited to sending only one ARP request - this isn't The Hunt For The Red October movie. We're talking a common misconfiguration here in this thread - or at least you were, two mails upthread. How will checking for Proxy ARP possibly hose up anybody's connectivity? You realise that ARP replies are unicast, right? And that IXPs generally have dedicated servers for monitoring from which they can source packets? This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. So no, even though I consider it someone else’s bad behavior to broadcast an ARP reply, I’m not willing to take the chance with an IP that doesn’t belong to me. -c
Re: Proxy ARP detection
* c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. So no, even though I consider it someone else’s bad behavior to broadcast an ARP reply, I’m not willing to take the chance with an IP that doesn’t belong to me. So do an ARP request for www.equinix.com, or (and!) for an unused address on your Peering LAN. Standard tools like arpwatch should alert you to fishy things going on, loudly. -- Niels. -- It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account. -- roy edroso, alicublog.blogspot.com
Re: Proxy ARP detection
On Jan 15, 2014, at 4:03 PM, Niels Bakker niels=na...@bakker.net wrote: * c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. This was some time ago, but the two I was able to dig up from that case were both Junipers. Perhaps it’s something that only happens when proxy ARP is enabled? -c
Question re: WordPress
Wondering if anyone in the community could kindly advise. How can someone get a deceased person's blog removed/taken down from WordPress? Please contact me directly offline if you can assist. Thank you Ilissa eMail: ili...@imillerpr.com
Re: Proxy ARP detection
Cisco PIX's used to do this if the firewall had a route and saw a ARP request in that IP range it would proxy arp. - Original Message - On Jan 15, 2014, at 4:03 PM, Niels Bakker niels=na...@bakker.net wrote: * c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. This was some time ago, but the two I was able to dig up from that case were both Junipers. Perhaps it’s something that only happens when proxy ARP is enabled? -c -- Eric Rosen CCIE Security #17821 Information Security Analyst Red Hat, Inc ero...@redhat.com 919.890.8555 x48555 IRC erosen
Re: gmail.com - 550 error for ipv6/PTR ?
On Jan 14, 2014, at 4:06 PM, Brandon Applegate bran...@burn.net wrote: Just saw this in a message tonight. No idea if this is a transient error or not. --- host gmail-smtp-in.l.google.com [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records and authentication 550-5.7.1 . Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error [support.google.com] for more 550 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA command) --- That URL's relevant section says: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam. --- I have both of these (PTR's RR has matching , and I have SPF (but not DKIM)). It occurs to me, you may have sent a bounce, where the envelope from is empty, therefore SPF would work on the domain in the helo/ehlo. People often forget to put a SPF record there... So there may be no SPF in fact... https://dmarcian.com/spf-survey/orbital.burn.net http://trac.tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-10.1.3 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Question re: WordPress
wordpress.com ? On Wed, Jan 15, 2014 at 8:09 PM, Ilissa Miller ili...@imillerpr.com wrote: Wondering if anyone in the community could kindly advise. How can someone get a deceased person's blog removed/taken down from WordPress? Please contact me directly offline if you can assist. Thank you Ilissa eMail: ili...@imillerpr.com -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Question re: WordPress
THANK YOU! On Jan 15, 2014, at 8:50 PM, Peter Thimmesch wrote: http://en.support.wordpress.com/deceased-user/ On Jan 15, 2014, at 8:09 PM, Ilissa Miller ili...@imillerpr.com wrote: Wondering if anyone in the community could kindly advise. How can someone get a deceased person's blog removed/taken down from WordPress? Please contact me directly offline if you can assist. Thank you Ilissa eMail: ili...@imillerpr.com Ilissa Miller CEO, iMiller Public Relations President, Northeast DAS + Small Cell Association Tel: 914.315.6424 Cel: 917.743.0931 eMail: ili...@imillerpr.com www.imillerpr.com www.northeastdas.com
Re: Proxy ARP detection
Excellent. So all everyone has to do is not buy cisco _or_ juniper. Wait a minute -- TTFN, patrick On Jan 15, 2014, at 19:54 , Eric Rosen ero...@redhat.com wrote: Cisco PIX's used to do this if the firewall had a route and saw a ARP request in that IP range it would proxy arp. - Original Message - On Jan 15, 2014, at 4:03 PM, Niels Bakker niels=na...@bakker.net wrote: * c...@bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. This was some time ago, but the two I was able to dig up from that case were both Junipers. Perhaps it’s something that only happens when proxy ARP is enabled? -c -- Eric Rosen CCIE Security #17821 Information Security Analyst Red Hat, Inc ero...@redhat.com 919.890.8555 x48555 IRC erosen
Re: Internet Routing Registries - RADb, etc
Blake, If you find that an RADb maintainer is unresponsive about removing stale/incorrect objects in the RADb, we will review your request and can remove the objects in question. Regards, Larry Blunk Merit - Original Message - Can someone provide a little guidance on RADb (and other IRRs)? Our organization is not a customer of any IRRs, but our ARIN IP allocation is registered in RADb and Level3's IRR. The majority of these entries are incorrect and list other AS#'s (AS's that have never been authorized to announce this IP space) as the originating AS for our ARIN IP allocation. I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response. Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)? Thanks in advance, --Blake
Re: Proxy ARP detection
On Wed, Jan 15, 2014 at 10:21 PM, Patrick W. Gilmore patr...@ianai.netwrote: Excellent. So all everyone has to do is not buy cisco _or_ juniper. Or make the LANs IPv6-only adressed, since ARP is not used. G And it is probably unlikely that someone will turn on a ND Proxy by accident. Wait a minute -- TTFN, patrick -- -JH
Re: Proxy ARP detection (was re: best practice for advertising peering fabric routes)
On 1/15/2014 6:31 PM, Clay Fiske wrote: Yes, yes, I expected a smug reply like this. I just didn’t expect it to take so long. But how can I detect proxy ARP when detecting proxy ARP was patented in 1996? http://www.google.com/patents/US5708654 Seriously though, it’s not so simple. You only get replies if the IP you ARP for is in the offender’s route table (or they have a default route). I’ve seen different routers respond depending on which non-local IP was ARPed for. And while using something like 8.8.8.8 might be an obvious choice, I don’t care to hose up everyone’s connectivity to it just to find local proxy ARP offenders on my network. -c Shouldn't ARP inspection be a common feature?
Re: Proxy ARP detection (was re: best practice for advertising peering fabric routes)
On Wed, Jan 15, 2014 at 10:49 PM, ML m...@kenweb.org wrote: Shouldn't ARP inspection be a common feature? Dynamic ARP inspection is mostly useful only when the trusted ports receive their MAC to IP address mapping from a trusted DHCP server, and the trusted mapping is established using DHCP snooping. Or else, you have a manually entered entries in the secure ARP database of MAC to IP mappings. Which most operators would be resistant to dealing with, because of all the extra work. -It's not as if the switches know what the valid subnets are and suppress ARP requests for outside networks. Therefore, in most cases; ARP inspection won't be used, except for DHCP clients. Arp inspection goes hand-in-hand with increasing resistance against a Man in the Middle attack from a compromised workstation on a LAN, using ARP hijacking to capture traffic or distribute malware to a neighboring workstation. In most cases, DHCP-based configuration will not be used for routers (the very devices that might inadvertently have proxy-arp) -- -JH
Re: gmail.com - 550 error for ipv6/PTR ?
It occurs to me, you may have sent a bounce, where the envelope from is empty, therefore SPF would work on the domain in the helo/ehlo. People often forget to put a SPF record there... So there may be no SPF in fact... Nope. In this case, Google was just messed up. R's, John
