nanog mailing list archives

Re: Level 3 BGP Advertisements


From: Blake Hudson <blake () ispn net>
Date: Thu, 30 Aug 2012 13:50:41 -0500

Matt Addison wrote the following on 8/29/2012 6:08 PM:
Sent from my mobile device, so please excuse any horrible misspellings.

On Aug 29, 2012, at 18:30, james machado <hvgeekwtrvl () gmail com> wrote:

On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS
<Curtis.Starnes () granburyisd org> wrote:
Sorry for the top post...

Not necessarily a Level 3 problem but;

We are announcing our /19 network as one block via BGP through AT&T, not broken up into smaller announcements.
Earlier in the year I started receiving complaints that some of our client systems were having problems connecting to 
different web sites.
After much troubleshooting I noticed that in every instance the xlate in our Cisco ASA for the client's IP last octet 
was either a 0 or 255.
Since I am announcing our network as a /19, the subnet mask is 255.255.224.0, that would make our network address 
x.x.192.0 and the broadcast x.x.223.255.
So somewhere the /24 boundary addresses were being dropped.

Just curious if anyone else has seen this before.
some OS's by M and others as well as some devices have IP stacks which
will not send or receive unicast packets ending in 0 or 255.  have had
casses where someone was doing subnets that included those in the DCHP
scopes and the computers that received these addresses were black
holes.

james
MSKB 281579 affects XP home and below. Good times anytime someone adds
a .0 or .255 into an IP pool.

It might be relevant to note that XP and below is simply respecting classful boundaries. This does not affect all .0 or .255 address, just class C addresses (192.0.0.0 through 223.255.255.255) that end with .0 or .255. If your IP range is 0.0.0.0 - 191.255.255.255 you are not affected (by this particular bug) by using .0 or .255 as the last octet unless the address is ALSO the last octet of the classful boundary for your subnet. In effect, these OS's simply enforce classful boundaries regardless of the subnet mask you have set. As the KB states, this "bug" affects supernets only. I'm not trying to defend MS (they can do that themselves), but your statement was misleading.

We do, sometimes, use .0 and .255 addresses. Most clients work fine with them (including XP). However, I have personally seen a few networks where an administrator had blocked .0 and .255 addresses, causing problems for people on his network communicating to hosts that ended in .0 or .255. It has been years since I have seen an issue with a .0 or a .255 IP however. Given fears over IP shortages, even a couple percent of addresses wasted due to subnetting can be cause for adjusting network policy. I would not be surprised if folks who excluded .0 and .255 addresses from their assignable pools will re-evaluate that decision over the next few years.

--Blake




Current thread: