The use of .0/.255 addresses.

Mailman List Mirror (Read Only)
1

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.

2

[...]

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.)

3

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

4

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.

5

Some networks use /31s on p2p links, including peering links
to other providers.. :slight_smile:

  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

6

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.

7

May I take this opportunity to remind people of my Atlanta 1998 (IIRC) NANOG tutorial on ISP addressing, "Good Providers have No Class"?

8

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 :slight_smile:

9

This is what happens when your educational system continues to teach
classful routing as anything other than a HISTORICAL FOOTNOTE
*coughCiscocough*.

Yes, it sure would be nice if Cisco would revise some of their CCNA
course material and exams. Plenty of classful stuff still left there,
I'm afraid.

It's kind of stupid when you have to tell fellow workers trying to get
a certification "This isn't real life, you just have to learn it for
the exam. In real life we use CIDR."

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

10

sthaug@nethelp.no wrote:

It's kind of stupid when you have to tell fellow workers trying to get
a certification "This isn't real life, you just have to learn it for
the exam. In real life we use CIDR."

You don�t have to take the CCNA stuff if you go for CCIE directly.

Pete

11

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

12

> 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

13

[...]

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?

14

[...]
> 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

15

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.

16

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.)

17

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,

18

sigh, i cant read, you did mean class E :wink:

regards,