In practice, We've always advertised our space all the way down to /24's
but also the aggregate block (the /20 or the /21). Just so there was still
reachability to our network in the event that someone made the foolish
mistake of filtering lets say prefixes smaller /23...
Anyways, I've always thought that was standard practice. And its never been
a problem. Until we brought up peering with level 3..
I noticed that while the /24's made it out to the world. The larger
counterparts (2 /21's and a /20) did not. So, I start sniffing around. Find
that I do indeed see the prefixes in Level 3's looking glass but they
aren't handing it off to peers. So, Naturally, I land on this being some
kind of prefix filtering issue and open a ticket with Level 3. They tell me
this is standard practice. And If I want to see the /20 or /21's make it
out to the rest of the world, I need to stop sending the /24's.
Does this sound normal?
Is what I'm doing (Advertising the aggregate prefix) a good rule of thumb?
Anyways, I've always thought that was standard practice. And its never been
a problem. Until we brought up peering with level 3..
No...I'd call that global table pollution. In general, there's no reason you should announce your CIDRs and all their /24 subnets.
I noticed that while the /24's made it out to the world. The larger
counterparts (2 /21's and a /20) did not. So, I start sniffing around. Find
that I do indeed see the prefixes in Level 3's looking glass but they
aren't handing it off to peers. So, Naturally, I land on this being some
kind of prefix filtering issue and open a ticket with Level 3. They tell me
this is standard practice. And If I want to see the /20 or /21's make it
out to the rest of the world, I need to stop sending the /24's.
Does this sound normal?
No. I announce to Level3 our IP space and 2 subnets of each CIDR (i.e. /17 + 2 /18 subnets of that /17, etc.), but I use community tags (and other tricks) to mark the more specifics as advertise to [certain] L3
customers only, and let the less specifics out to the world. The only problems I've had with this have been when L3 peers have become customers, and one L3 customer doing something odd (never did find out what) that caused them to effectively null route our space until I kept them from seeing the more specifics (creative abuse of loop detection).
Level3's prefix filter for your session should be built based on IRR data. If it's not doing what you want, you probably haven't setup the IRR data properly.
No, that's not standard practice. I do this exact thing with Level 3 and have been for many many many years. Whoever is telling you this must be green.
I would recommend adding the no-export community to your more specific routes if you can so as to be a good steward of the ever growing Internet IPv4 table.
In practice, We've always advertised our space all the way down to /24's
but also the aggregate block (the /20 or the /21). Just so there was still
reachability to our network in the event that someone made the foolish
mistake of filtering lets say prefixes smaller /23...
Anyways, I've always thought that was standard practice.
That's very poor practice. Each announcements costs *other people* the
better part of $10k per year. Be polite with other peoples' money. If
the /24 shares the exact same routing policy as the covering route,
announce only the covering route.
For all the good it'll do you, you can break it out to /24's when and
if someone mis-announces one of your address blocks. Competing
announcements of the /24 still won't leave you with correct
connectivity. If anything, putting the /24 announcement in ahead of
time will delay your detection of the problem by causing a partial
failure instead of a total one.
I noticed that while the /24's made it out to the world. The larger
counterparts (2 /21's and a /20) did not. So, I start sniffing around. Find
that I do indeed see the prefixes in Level 3's looking glass but they
aren't handing it off to peers. So, Naturally, I land on this being some
kind of prefix filtering issue and open a ticket with Level 3. They tell me
this is standard practice. And If I want to see the /20 or /21's make it
out to the rest of the world, I need to stop sending the /24's.
Does this sound normal?
That's insane. Assuming you're authorized to announce that address
space, Level 3 should be propagating your announcements exactly as you
make them. As only one of your peers, they're in no position to
understand the traffic engineering behind your announcement choices.
If they are acting as you say, they are dead wrong to do so.
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.
What, you don't spend $4,000,000,000 per year due to the size of the global routing table? I know I've budgeted $4.5B for next year to account for growth, which leaves my expected balance sheet at about.... err.... carry the two... -$4.4999B. Sweet!
The "better part" of $10k. It's been several years since I refreshed
the source numbers but the formula for the estimate and what were then
the source numbers are documented at http://bill.herrin.us/network/bgpcost.html
Also note that was for IPv4 announcements. I didn't cost IPv6
announcements but it looked like they were roughly twice the price.
That may or may not still be true depending on how the switching
engines are built these days. My guess is: no change.
And yes, it is a really big number. At the time it meant that roughly
$2B of the annual worldwide economy (something like 2/1000ths of a
percent) was attributable to the BGP prefix count.
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.
I have ended up excluding .0 and .255 from our DHCP pools in larger than /24 subents due to this exact issue in the past... It is a PITA. I wish people would update filters.
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.
This is what happens when old network folk don't learn about new convention or new network / security folk read old books.
And it happens alot!
Although not as common as blanket blocking of ICMP .
Matt Addison wrote the following on 8/29/2012 6:08 PM:
Sent from my mobile device, so please excuse any horrible misspellings.
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.
Matt Addison wrote the following on 8/29/2012 6:08 PM:
Sent from my mobile device, so please excuse any horrible misspellings.
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.
I can distinctly remember having the issue in 10/8 address space with
Win2k and WinXP
I remember it too... I had a ticket get escalated from our support group in about 2003 of a customer who could not get any internet access... they had XP and had been assigned a .0 IP out of a /23 we were using for a specific pop. That /23 came out of 64.0.0.0/8 so it was clearly a bit more blanket than a class based filter. They may have had some third party firewall software on their machine, I can't remember, but I know my solution was to be a bit disgusted and then exclude .255 and .0 from the pool.
