Level 3 BGP Advertisements
blake at ispn.net
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
> 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 22.214.171.124) that end with .0
or .255. If your IP range is 0.0.0.0 - 126.96.36.199 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.
More information about the NANOG