Level 3 BGP Advertisements

Thu Aug 30 18:50:41 UTC 2012

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 at gmail.com> wrote:
>
>> On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS
>> <Curtis.Starnes at 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