RE: Semi-automated L3 interface DNS records
Thanks to everyone that responded. Based on the information from this list and several other areas I posted the same question, it seems like a feasible goal. If anyone has any ideas on how to either reduce my sleeping requirements or extend the number of hours in a day so that I can actually implement this, I would love to hear from you. :-P -Original Message- From: Pedersen, Sean [mailto:sean.peder...@usairways.com] Sent: Thursday, October 18, 2012 12:57 PM To: nanog@nanog.org Subject: Semi-automated L3 interface DNS records Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue.
forward and reverse DNS (was: Please, talk me down.)
On Mon, Oct 22, 2012 at 03:18:52PM +1100, Mark Andrews wrote: records are consistent. It is however good practice that these exist and are consistent. I will note that the IETF DNSOP WG was unable to agree even on that latter claim. A -- Andrew Sullivan Dyn Labs asulli...@dyn.com
Issues encountered with assigning .0 and .255 as usable addresses?
Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason.
Re: Issues encountered with assigning .0 and .255 as usable addresses?
As far as I know. There is no RFC based restrictions based on having those as usable IPs. We have been routing customers IP blocks on our network for a while and never had a problem with 0 or .255 as the assigned IP even with Microsoft Windows 2003 as the operating system. Im not sure how to fix your issue but I dont think its automatically disregarded by anyone that would seem silly. On Mon, Oct 22, 2012 at 4:07 PM, Paul Zugnoni paul.zugn...@jivesoftware.com wrote: Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. -- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
Re: Issues encountered with assigning .0 and .255 as usable addresses?
On Mon, Oct 22, 2012 at 5:07 PM, Paul Zugnoni paul.zugn...@jivesoftware.com wrote: Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. Way back in the late 90's I tried this with a /23 dialup DHCP pool and quickly found that the .0 and .255 users couldn't get to some scattered web sites, though they seemed to be able to get to most of the Internet. However, a year or so ago I spun up an always-on Amazon ec2 instance with a static IP and was handed a .0 address. I still use this VM regularly and have not run into any problems with reachability for this address.
Re: Issues encountered with assigning .0 and .255 as usable addresses?
Hi Paul, On Oct 22, 2012, at 5:07 PM, Paul Zugnoni paul.zugn...@jivesoftware.com wrote: Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. In the post-classfull routing world .0 and .255 should be normal IP addresses. CIDR was only recently defined (somewhere in 1993) so I understand it might take companies some time to adjust to this novel situation. Ok, enough snarkyness! Quite recently a participant of the NLNOG RING had a problem related to an .255 IP address. You can read more about it here: https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/ So yes, apparently problems like these still arise once in a while. My recommendation would be to fix the equipment and not blame it on .0 or .255. Kind regards, Job Snijders
Re: Issues encountered with assigning .0 and .255 as usable addresses?
On 10/22/12 17:18 -0500, Matt Buford wrote: On Mon, Oct 22, 2012 at 5:07 PM, Paul Zugnoni paul.zugn...@jivesoftware.com wrote: Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. Way back in the late 90's I tried this with a /23 dialup DHCP pool and quickly found that the .0 and .255 users couldn't get to some scattered web sites, though they seemed to be able to get to most of the Internet. However, a year or so ago I spun up an always-on Amazon ec2 instance with a static IP and was handed a .0 address. I still use this VM regularly and have not run into any problems with reachability for this address. I had a similar experience about 10 years ago, with DSL customers who had been assigned .0 or .255 addresses not able to reach some sites. -- Dan White
IP tunnel MTU
Hello, Several months ago, there was discussion on the list regarding IP tunnel maximum transmission unit (MTU). Since that time, it has been brought to my attention by members of my company's network operations staff that tunnel MTU is a very real problem they need to cope with on a daily basis - especially with the growing need to depend on both tunnels and tunnels-within-tunnels to track mobile devices. Since tunnels always reduce the effective MTU seen by data packets due to the encapsulation overhead, the only two ways to accommodate the tunnel MTU is either through the use of path MTU discovery or through fragmentation and reassembly. Unfortunately, both are known to be problematic in a non-trivial number of cases. The discussions on NANOG from back in the June timeframe resulted in Operational Issues with Tunnel Maximum transmission Unit: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ I would like to ask this group to now give this document a look and post your comments/thoughts/experiences. For example, has the tunnel MTU problem crept into daily operational considerations to the point that we should now at least be documenting it and preferably trying to do something about it? From talking to our staff, I believe the answer is yes but it would be good to have confirmation from others. Thanks in advance for your thoughts, Fred fred.l.temp...@boeing.com
RE: Issues encountered with assigning .0 and .255 as usable addresses?
From: Paul Zugnoni [mailto:paul.zugn...@jivesoftware.com] Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. We're a web host and over the past 12 years we've randomly attempted to put non-critical customer sites on .0 and .255 addresses and found customers fairly consistently had problems accessing them. These would typically be sites for development, etc. where the customer was the only one accessing it and even then it has been a high percentage of failures. It is nearly always the customer's small biz / home office cheap-o router that is the issue even in this day and age but occassionally it has been the ISP as well. I haven't kept a list of vendors/isp's unfortunately so I don't have more useful information to offer you other than that it's still a problem. We still use those addresses for that purpose since they'd otherwise go to waste but most of the time it ends up being changed when the customer tries to access it from somewhere and can't. David
hotmail.com live.com admin needed
Hi, We're trying to resolve some delivery issues reported by hotmail users. Started happening a few weeks ago. Getting immediate NDRs, and the server that is supposed to receive the email has no records of attempts. The messages also don't match what the receiving server should be sending. The server(s) listed in the MX should receive all email without authentication, since it's a mail filtering service (Maxmail) === Reporting-MTA: dns;snt0-omc3-s27.snt0.hotmail.com Received-From-MTA: dns;SNT133-W53 Arrival-Date: Mon, 22 Oct 2012 14:09:49 -0700 Final-Recipient: rfc822;administra...@.com Action: failed Status: 5.5.0 Diagnostic-Code: smtp;550 authentication required === Kindly contact me off-list. Thanks, -- Carlos M. Perez Runcentral, LLC
Re: Issues encountered with assigning .0 and .255 as usable addresses?
--- j...@instituut.net wrote: From: Job Snijders j...@instituut.net Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. I used about a /15s worth of /23s for DHCP at a previous employer for 5 years (2005 - 2010) and they're still using them today years later. Never got one complaint AFAIK. I even got one of the .0 or .255 addresses for a while and never had trouble. This was discussed in detail a while back. Look in the archives. scott
Re: Issues encountered with assigning .0 and .255 as usable addresses?
d be considered invalid. When you have a pool of assignable addresses, you = should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or N= AT pool, or subnets larger than /24). Yet I've run into a commercial IP mgm= t product and getting reports of M$ ISA proxy that is specifically blocking= traffic for an IP ending in .0 or .255. To make a long story short: If it's a product you're considering buying, problems with .0 and .255 reflect on the competence of the product's designers. You can safely assume that there are many other Severely Broken Things too and move on to saner products. For general Internet use, there is a lot of gear out there that's ten or more years old. You should avoid using .0 and .255 addresses if you can avoid it, though it's a shame to waste valid IP space to accommodate the brokenness of someone else's stuff. Some of us park stuff on .0 and .255 addresses in order to motivate others to change. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Issues encountered with assigning .0 and .255 as usable addresses?
In message 201210222307.q9mn7aiv063...@aurora.sol.net, Joe Greco writes: d be considered invalid. When you have a pool of assignable addresses, you = should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or N = AT pool, or subnets larger than /24). Yet I've run into a commercial IP mgm = t product and getting reports of M$ ISA proxy that is specifically blocking = traffic for an IP ending in .0 or .255. To make a long story short: If it's a product you're considering buying, problems with .0 and .255 reflect on the competence of the product's designers. You can safely assume that there are many other Severely Broken Things too and move on to saner products. For general Internet use, there is a lot of gear out there that's ten or more years old. You should avoid using .0 and .255 addresses if you can avoid it, though it's a shame to waste valid IP space to accommodate the brokenness of someone else's stuff. Ten year old equipment should be CIDR aware. It's not like it CIDR wasn't in wide spread using in 2002. Some of us park stuff on .0 and .255 addresses in order to motivate others to change. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CN N) With 24 million small businesses in the US alone, that's way too many apples. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Issues encountered with assigning .0 and .255 as usable addresses?
Ten year old equipment should be CIDR aware. It's not like it CIDR wasn't in wide spread using in 2002. And BCP38 has had sufficient time to be globally deployed. What's your point, again? ;-) I was pretty careful in trying to outline that it's still expected that there are defective products which even today will filter .0 and .255. This might be due to incompetence, or nobody having looked at the code in a dozen years, or other various faults. There is no central agency to validate gear against RFC, common use, and common sense, and from what I hear, even Cisco has maintained classful routing in useless contexts many years beyond what it should have. The painful difference between should be CIDR aware (we agree on this!) and is actually CIDR compliant without amateur-hour mistakes is a measurable distance, even today. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Issues encountered with assigning .0 and .255 as usable addresses?
On 10/22/12, Paul Zugnoni paul.zugn...@jivesoftware.com wrote: [snip] Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. ISA is old, and might not be supported anymore, unless you have an extended support contract. If it's not supported anymore, then don't be surprised if it has breakage you will not be able to repair. I don't recommend upgrading to TMG, either: although still supported, that was just discontinued. If ISA is refusing traffic to/from IPs ending in .0, then ISA is either broken, or misconfigured. Get a support case with the vendor, raise it as a critical issue -- unable to pass traffic to critical infrastructure that ends with a .255 or .0 IP address, demand that the vendor provide a resolution, And explain that changing the IP address of the remote server is not an option. If the vendor can't or won't provide a resolution, then not only is the proxy server broken, but malfunctioning in a way that has an impact on network connectivity. I would consider its removal compulsory, as you never know, when a network resource, web site, e-mail server, etc. your org has a business critical need to access, or be accessed from; may be placed on .255 or .0 -- -JH
Re: IP tunnel MTU
On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote: Since tunnels always reduce the effective MTU seen by data packets due to the encapsulation overhead, the only two ways to accommodate the tunnel MTU is either through the use of path MTU discovery or through fragmentation and reassembly. Actually, you can set your tunnel MTU manually. For example, the typical MTU folks set for a GRE tunnel is 1476. This isn't a new issue; it's been around ever since tunneling technologies have been around, and tons have been written on this topic. Look at your various router/switch vendor Web sites, archives of this list and others, etc. So, it's been known about, dealt with, and documented for a long time. In terms of doing something about it, the answer there is a) to allow the requisite ICMP for PMTU-D to work to/through any networks within your span of administrative control and b) adjusting your own tunnel MTUs to appropriate values based upon experimentation. Enterprise endpoint networks are notorious for blocking *all* ICMP (as well as TCP/53 DNS) at their edges due to 'security' misinformation propagated by Confused Information Systems Security Professionals and their ilk. Be sure that your own network policies aren't part of the problem affecting your userbase, as well as anyone else with a need to communicate with properties on your network via tunnels. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Issues encountered with assigning .0 and .255 as usable addresses?
And since owen has not yet mentioned it, consider something that supports having : in its address as well. Sort of tangentially related, I had a support rep for a vendor once tell me that a 255 in the second or third octet was not valid for an ipv4 address. Hard to troubleshoot a problem when I had to first explain how ip addressing worked because the rep was so fixated on the 255 we were using on the network. If any product really doesn't like 255 in any position then you should consider yourself lucky to still be in business at all. Jimmy Hess mysi...@gmail.com wrote:On 10/22/12, Paul Zugnoni paul.zugn...@jivesoftware.com wrote: [snip] Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason. ISA is old, and might not be supported anymore, unless you have an extended support contract. If it's not supported anymore, then don't be surprised if it has breakage you will not be able to repair. I don't recommend upgrading to TMG, either: although still supported, that was just discontinued. If ISA is refusing traffic to/from IPs ending in .0, then ISA is either broken, or misconfigured. Get a support case with the vendor, raise it as a critical issue -- unable to pass traffic to critical infrastructure that ends with a .255 or .0 IP address, demand that the vendor provide a resolution, And explain that changing the IP address of the remote server is not an option. If the vendor can't or won't provide a resolution, then not only is the proxy server broken, but malfunctioning in a way that has an impact on network connectivity. I would consider its removal compulsory, as you never know, when a network resource, web site, e-mail server, etc. your org has a business critical need to access, or be accessed from; may be placed on .255 or .0 -- -JH
Re: Semi-automated L3 interface DNS records
On 2012-10-18, at 14:57, Pedersen, Sean sean.peder...@usairways.com wrote: Does anyone out there have any experience with a script, tool or appliance that would help manage the creation and maintenance of DNS records for Layer 3 interfaces on routers and switches? http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf ftp://ftp.isc.org/isc/toolmakers/ We'd like to move toward this practice to help with troubleshooting and IPAM, but it's not feasible to do it manually. At a minimum, I was mulling over the idea of writing a script that would poll a device via SNMP to obtain interface information, parse it, compare the results to DNS, then generate a report if it found a miss. It wouldn't be fully-automated, but it would be better than doing that portion of the work manually. Cleaning up dead entries would be another issue. AS6461 once had the bulk of its reverse DNS auto-generated from awk scripts. It's the only way to travel. Joe
Re: forward and reverse DNS (was: Please, talk me down.)
On 2012-10-22, at 11:36, Andrew Sullivan asulli...@dyn.com wrote: On Mon, Oct 22, 2012 at 03:18:52PM +1100, Mark Andrews wrote: records are consistent. It is however good practice that these exist and are consistent. I will note that the IETF DNSOP WG was unable to agree even on that latter claim. I will further note that just because dnsop can't agree on something doesn't mean that it's not worth agreeing on. Joe
Re: forward and reverse DNS (was: Please, talk me down.)
On 10/22/12, Joe Abley jab...@hopcount.ca wrote: I will further note that just because dnsop can't agree on something doesn't mean that it's not worth agreeing on. [snip] Some of the IETF WGs' members wouldn't be able to agree what color the sky appears to be on a clear sunny day. But it is common MTAs, to be configured to perform a check for Forward-Confirmed DNS, similar to the iprev authentication mechanism mentioned in RFC5451, except this is mandatory, and they refuse delivery. Many popular anti-spam solutions are implementing this out of the box, and common MTAs provide documentation recommending configurations that implement constraints such as these: 1. If a 'HELO' or 'EHLO' message is received, and there is no argument, the SMTP server will respond with a 5xx reject, even though it is technically allowed to have a HELO/EHLO without a hostnamr parameter specified. 2. If a 'HELO' or 'EHLO' message is received; the SMTP server will begin a forward DNS lookup on the hostname presented in the HELO/EHLO, and a Reverse DNS lookup on the connecting IP; it may initiate an outgoing connection to port 113 auth (Ident) on the connecting IP, in order to ask for a username to insert in message headers. a. If the forward DNS check on the HELO name, or the PTR query on the connecting IP fails to get a response. HELO fails with a 4xx reject. b. If either result in a NXDOMAIN response, HELO fails with a 5xx reject. c. If both succeed, a forward DNS lookup is started for the name found in the PTR response, and a 4xx reject upon lookup failure, or 5xx reject upon a NXDOMAIN response, or forward lookup response not matching the IP address of the client. o The SMTP reject might instead trigger a tarpitting mechanism. Some implementations currently accept the HELO and delay the SMTP reject by default until a later stage, such as RCPT TO, and/or cache the reject decision, to reduce the impact of multiple connection attempts. 3. If a 'RCPT TO' message is received, a 5xx smtp error is sent, unless a 'MAIL FROM' message has already been received and accepted, and the mailbox is a known local mailbox. 4. If a 'MAIL FROM' message is received, a 5xx smtp error is sent, unless a 'HELO' or 'EHLO' message has already been received and accepted.If the address referenced is not , then A DNS request is sent for forward lookup of the domain in the MAIL FROM, and SPF query/policy test on the envelope from address. If there is a SPF soft fail, a 4xx reject;SPF hard fail, or the domain does not exist, a SMTP 5xx reject. Joe -- -JH
