Have just spent some time trying to track down what seemed to be an elusive problem, I thought I'd mention it here. I've had problems accessing www.level3.net, www.ebay.co.uk and www.dabs.com (and a few others I don't recall). As I'm the first user of a reasonably new netblock I thought it might be something to do with filters on our upstreams or similar. Trying an IP from our older netblock worked without problems, which seemed to back this up. However eventually I tracked it down to the use of the .0 address from the new netblock; changing to use the .1 address meant I could access the above sites without any difficulty. Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them. J. -- /-\ | This is not a daffodil! This is |@/ Debian GNU/Linux Developer | not a daffodil! \- |
Jonathan McDowell <noodles@earth.li> wrote: [...]
Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them.
It's funny that it is you of all people that would note this, as I came to the same sort of conclusion after configuring and installing tippett.debian.org for you. Tippett has the IP address of 195.92.249.0. In the old classful scheme, this would be in a class C network. Energis actually have 195.92/16 and "supernet" the class Cs into more useful chunks. I think it's a good idea to conserve address space by issuing the IP addresses thus released. Unfortunately, a certain software producer in Redmond apparently hasn't heard of CIDR. I found that I could ping Tippett from a Windows 2000 box just fine, but TCP connections would always fail with "connection refused". Getting a packet sniffer on the job showed that Windows wasn't even issuing a SYN - it was deciding for itself that a connection wasn't valid without even trying. So it seems inadvisable to use addresses that would be network and broadcast addresses in the old classful scheme. IOW, if you've got, say, an 80.x.x.x address, .0 and .255 are most likely fine. (But test it first, as I haven't.) -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key
Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them.
The .255 address is very likely to be a broadcast address from a netblock of /24 or longer. I would suspect that folks are wary of accepting packets from a broadcast address as that could easily be a smurf. The .0 address was used as a broadcast address long ago and then was deprecated, so the same rationale probably applies. Tony
On Sat, 26 Jun 2004, Tony Li wrote:
The .255 address is very likely to be a broadcast address from a netblock of /24 or longer. I would suspect that folks are wary of accepting packets from a broadcast address as that could easily be a smurf. The .0 address was used as a broadcast address long ago and then was deprecated, so the same rationale probably applies.
I have a case where this is currently biting me. I've got a few small blocks of address space that I've chopped up into /32's for router loopback IPs. These are in /24's which have been subnetted with various sized customer subnets and then a /27 or so worth of router loopback /32's. One in particular is: interface Loopback0 ip address 209.208.6.255 255.255.255.255 I found some time ago that my home DSL connected network could not reach (telnet, ping, etc.) that router's loopback. Our monitoring system could, and several iBGP peers could, so I didn't notice the issue until one night when trying to do some work from home. What I've found is that one of our routers (7206 doing T1/DSL aggregation running 12.1T) has .255 issues. Yes, it does have ip subnet-zero & ip classless in the config. What's really odd is, from that 7206, I can traceroute to 209.208.6.255, but if I ping 209.208.6.255 from it, I get replies from another 209.208.6.x address on a connected T1 customer's CPE, as if the ping was sent out as a broadcast ping. #sh ip ro 209.208.6.255 Routing entry for 209.208.6.255/32 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 4 Last update from 209.208.16.29 on FastEthernet0/0.1, 00:46:47 ago Routing Descriptor Blocks: * 209.208.16.29, from 209.208.6.255, 00:46:47 ago, via FastEthernet0/0.1 Route metric is 20, traffic share count is 1 #ping 209.208.6.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.208.6.255, timeout is 2 seconds: Reply to request 0 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 1 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 2 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 3 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 4 from XXXXXXXXXX (209.208.6.xyz), 68 ms I suppose I'll give up on using the .255 IP, but I've not been looking forward to changing that as it means redoing half a dozen BGP peerings. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sat, 26 Jun 2004, Jon Lewis wrote:
On Sat, 26 Jun 2004, Tony Li wrote:
The .255 address is very likely to be a broadcast address from a netblock of /24 or longer. I would suspect that folks are wary of accepting packets from a broadcast address as that could easily be a smurf. The .0 address was used as a broadcast address long ago and then was deprecated, so the same rationale probably applies.
I have a case where this is currently biting me. I've got a few small blocks of address space that I've chopped up into /32's for router loopback IPs. These are in /24's which have been subnetted with various sized customer subnets and then a /27 or so worth of router loopback /32's. One in particular is:
interface Loopback0 ip address 209.208.6.255 255.255.255.255
Hi Jon, I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems..
I found some time ago that my home DSL connected network could not reach (telnet, ping, etc.) that router's loopback. Our monitoring system could, and several iBGP peers could, so I didn't notice the issue until one night when trying to do some work from home.
I could see the problem with DSL's where the provider may be interfering.. surprised about your monitoring tho...
What I've found is that one of our routers (7206 doing T1/DSL aggregation running 12.1T) has .255 issues. Yes, it does have ip subnet-zero & ip classless in the config. What's really odd is, from that 7206, I can traceroute to 209.208.6.255, but if I ping 209.208.6.255 from it, I get replies from another 209.208.6.x address on a connected T1 customer's CPE, as if the ping was sent out as a broadcast ping.
that looks really interesting. be curious as to how it gets forwarded across to CPE box to get the reply at all (even if it confuses the broadcast, surely you have directed broadcast disabled on 7206 + CPE)? Steve
#sh ip ro 209.208.6.255 Routing entry for 209.208.6.255/32 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 4 Last update from 209.208.16.29 on FastEthernet0/0.1, 00:46:47 ago Routing Descriptor Blocks: * 209.208.16.29, from 209.208.6.255, 00:46:47 ago, via FastEthernet0/0.1 Route metric is 20, traffic share count is 1
#ping 209.208.6.255
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.208.6.255, timeout is 2 seconds:
Reply to request 0 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 1 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 2 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 3 from XXXXXXXXXX (209.208.6.xyz), 68 ms Reply to request 4 from XXXXXXXXXX (209.208.6.xyz), 68 ms
I suppose I'll give up on using the .255 IP, but I've not been looking forward to changing that as it means redoing half a dozen BGP peerings.
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Stephen J. Wilcox <steve@telecomplete.co.uk> wrote: [...]
I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems..
Well, I'd expect Linux and OSX to do the right thing. It just seems to be Windows that makes a complete sow's ear of it. As to the IP addresses ending in 255 that are working from Windows boxes, would I be right in guessing that the first octet of the IP addresses in question is between 1 and 191? -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key
On Sun, 27 Jun 2004, Peter Corlett wrote:
Stephen J. Wilcox <steve@telecomplete.co.uk> wrote: [...]
I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems..
Well, I'd expect Linux and OSX to do the right thing. It just seems to be Windows that makes a complete sow's ear of it.
As to the IP addresses ending in 255 that are working from Windows boxes, would I be right in guessing that the first octet of the IP addresses in question is between 1 and 191?
Hi Peter, actually no.. I just did a test right now, I'm at a friends and using an XP machine connected via a cable modem.. my results arent entirely in agreement with my initial post I tested to both a "Class A" .255 we have and also to a "Class C" .255 we have Class A: works on everything..trace, ping, ssh Class C: spooky, traces up to the interface before the device. wont ping. connections fail with Network error: Cannot assign requested address. But, this same test works when tried from linux - possibly different behaviour between icmp and udp on cisco??
From the hop-before-last (cisco 7206 12.2(14)S3) if i ping it seems to be broadcasting out of the interface towards the .255 rather than unicasting, i confirm this with a packet capture:
16:03:47.614187 Class-C.x.x.x > 255.255.255.255: icmp: echo request the cisco reports correct routing of the Class-C /32 Steve
On 27-jun-04, at 16:12, Peter Corlett wrote:
I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems..
Well, I'd expect Linux and OSX to do the right thing. It just seems to be Windows that makes a complete sow's ear of it.
If you want to have some real fun, try configuring some class E addresses. Windows of course won't have it, and Cisco also doesn't want anything to do with it, even to the point of rejecting routes within 240.0.0.0/4 when they come in over BGP. (Which an MacOSX box running Zebra will happily provide.)
On Sun, 27 Jun 2004, Iljitsch van Beijnum wrote:
If you want to have some real fun, try configuring some class E addresses. Windows of course won't have it, and Cisco also doesn't want anything to do with it, even to the point of rejecting routes within 240.0.0.0/4 when they come in over BGP. (Which an MacOSX box running Zebra will happily provide.)
Class D you mean surely? Note that while GNU Zebra might be configurable to provide such updates, it too rejects such updates if received on unicast IPv4 address family sessions bgp_route.c::bgp_nlri_parse(): /* Check address. */ if (packet->afi == AFI_IP && packet->safi == SAFI_UNICAST) { if (IN_CLASSD (ntohl (p.u.prefix4.s_addr))) { zlog (peer->log, LOG_ERR, "IPv4 unicast NLRI is multicast address %s", inet_ntoa (p.u.prefix4)); bgp_notify_send (peer, BGP_NOTIFY_UPDATE_ERR, BGP_NOTIFY_UPDATE_INVAL_NETWORK); return -1; } } and has done since GNU Zebra 0.91. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: Many receive advice, few profit by it. -- Publilius Syrus
On Sun, 27 Jun 2004, Paul Jakma wrote:
On Sun, 27 Jun 2004, Iljitsch van Beijnum wrote:
do with it, even to the point of rejecting routes within 240.0.0.0/4 when they come in over BGP. (Which an MacOSX box running Zebra will happily provide.)
Class D you mean surely?
sigh, i cant read, you did mean class E ;) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: "Die? I should say not, dear fellow. No Barrymore would allow such a conventional thing to happen to him." -- John Barrymore's dying words
On Sun, 27 Jun 2004, Stephen J. Wilcox wrote:
Hi Jon, I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems..
I'm pretty confident this is a classful/classless bug in 12.1T. I just got into the customer's router that was sending what looked like replies to a broadcast ping, and that's just what it was. Here's the output from debug ip packet on the CPE that was replying when I pinged 209.208.6.255 from the 7206. IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2 IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2 IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2 Checked with an ACL on the input side of the CPE's serial subint, *Mar 3 08:40:19: %SEC-6-IPACCESSLOGDP: list test permitted icmp 209.208.6.xyZ (Serial0.2 DLCI 100) -> 255.255.255.255 (0/0), 1 packet where 209.208.6.xyz is the customer's serial IP, and 209.208.6.xyZ is the 7206's serial IP. Both ends to have no ip directed-broadcast.
I found some time ago that my home DSL connected network could not reach (telnet, ping, etc.) that router's loopback. Our monitoring system could, and several iBGP peers could, so I didn't notice the issue until one night when trying to do some work from home.
I could see the problem with DSL's where the provider may be interfering.. surprised about your monitoring tho...
No...I said the monitoring system didn't have a problem with it. It fortunately doesn't have to transit the affected router which only handles T1 & DSL aggregation (including my home DSL).
#sh ip ro 209.208.6.255 Routing entry for 209.208.6.255/32 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 4 Last update from 209.208.16.29 on FastEthernet0/0.1, 00:46:47 ago Routing Descriptor Blocks: * 209.208.16.29, from 209.208.6.255, 00:46:47 ago, via FastEthernet0/0.1 Route metric is 20, traffic share count is 1
#sh ip cef 209.208.6.255 209.208.6.255/32, version 12215105, cached adjacency 209.208.16.29 0 packets, 0 bytes tag information set, shared local tag: 398 fast tag rewrite with Fa0/0.1, 209.208.16.29, tags imposed: {114} via 209.208.16.29, FastEthernet0/0.1, 0 dependencies next hop 209.208.16.29, FastEthernet0/0.1 valid cached adjacency tag rewrite with Fa0/0.1, 209.208.16.29, tags imposed: {114} #sh tag-switching forwarding-table 209.208.6.255 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 398 114 209.208.6.255/32 0 Fa0/0.1 209.208.16.29 MAC/Encaps=18/22, MTU=1520, Tag Stack{114} 0001638B90000005DC493400810000018847 00072000 No output feature configured Per-packet load-sharing It knows the next hop is another 7206 with connections to the rest of our network. Why is it sending this out as a broadcast ping instead of routing (tag switching) it? I know...wrong list. I'll ask on cisco-nsp, but the operational lesson here is that it's not just the junk from Redmond that may have classful/classless IP routing issues. Even your core routers might, depending on IOS versions. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sat, Jun 26, 2004 at 05:01:14PM -0700, Tony Li wrote:
Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them.
The .255 address is very likely to be a broadcast address from a netblock of /24 or longer. I would suspect that folks are wary of accepting packets from a broadcast address as that could easily be a smurf. The .0 address was used as a broadcast address long ago and then was deprecated, so the same rationale probably applies.
Some networks use /31s on p2p links, including peering links to other providers.. :) This means those links can have a .0 or .255 IP. This topic has been rehashed a few times in the past (you can find it in the nanog archives..) people using a /23 and .0 and .255 in dial and dhcp (dsl) pools having problems due to b0rken networks/hosts. My suggestion: get them to clean their act up. This includes Washington state host software vendors that may need to distribute patches for networking stacks with defects in their handling of outbound TCP connections (referenced in an alternate email..) - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Sat, 26 Jun 2004, Jared Mauch wrote:
This includes Washington state host software vendors that may need to distribute patches for networking stacks with defects in their handling of outbound TCP connections (referenced in an alternate email..)
Then of course we could use their ignorance to advantage and setup box that you know will never be accessed from windows as .0 or .255. You want to have a firewall or router interface that will not be dropped by the zombie army? Sure, thing, just set to to .0 Actually I've done testing on this about 6 months ago and setup box with normal ip and box with .0 ip and check how much boxes were being scanned. What an amazing results! The box with normal ip gets usually at least once per minute. The box with .0 ip got scanned I think once over several days period. Apparently viruses and hackers don't know that .0 can actually be real ip either! Of course, now that I have mentioned this, it might be changing real soon (so I'll do another test in 6 months to check :) -- William Leibzon Elan Networks william@elan.net
On Sun, Jun 27, 2004 at 12:32:40AM +0100, Jonathan McDowell wrote:
Have just spent some time trying to track down what seemed to be an elusive problem, I thought I'd mention it here.
I've had problems accessing www.level3.net, www.ebay.co.uk and www.dabs.com (and a few others I don't recall). As I'm the first user of a reasonably new netblock I thought it might be something to do with filters on our upstreams or similar. Trying an IP from our older netblock worked without problems, which seemed to back this up.
However eventually I tracked it down to the use of the .0 address from the new netblock; changing to use the .1 address meant I could access the above sites without any difficulty.
Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them.
This is what happens when your educational system continues to teach classful routing as anything other than a HISTORICAL FOOTNOTE *coughCiscocough*. This is also how you end up with 76k /24s in the global routing table. Do you part to help control the ignorant population: whenever you hear someone say "class [ABC]" in reference to anything other than a historical allocation, smack them. Hard. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
At 10:03 PM -0400 6/26/04, Richard A Steenbergen wrote:
This is what happens when your educational system continues to teach classful routing as anything other than a HISTORICAL FOOTNOTE *coughCiscocough*. This is also how you end up with 76k /24s in the global routing table.
Do you part to help control the ignorant population: whenever you hear someone say "class [ABC]" in reference to anything other than a historical allocation, smack them. Hard.
May I take this opportunity to remind people of my Atlanta 1998 (IIRC) NANOG tutorial on ISP addressing, "Good Providers have No Class"?
On Sun, Jun 27, 2004 at 12:32:40AM +0100, Jonathan McDowell wrote:
Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them.
This comes up every year or two on nanog; it's discouraging that operators and/or vendors are still screwing this up over a decade after RFC 1519. Thus spake "Richard A Steenbergen" <ras@e-gerbil.net>
This is what happens when your educational system continues to teach classful routing as anything other than a HISTORICAL FOOTNOTE *coughCiscocough*. This is also how you end up with 76k /24s in the global routing table.
"Those who can, do. Those who can't, teach."
Do you part to help control the ignorant population: whenever you hear someone say "class [ABC]" in reference to anything other than a historical allocation, smack them. Hard.
It seems to be pretty common usage now to refer to a /24 as a "Class C", regardless of the first octet. Certainly incorrect, but half as many syllables... S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
participants (12)
-
abuse＠cabal.org.uk -
Howard C. Berkowitz -
Iljitsch van Beijnum -
Jared Mauch -
Jon Lewis -
Jonathan McDowell -
Paul Jakma -
Richard A Steenbergen -
Stephen J. Wilcox -
Stephen Sprunk -
Tony Li -
william(at)elan.net