Greetings all. 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? Any other thoughts? Nick Olsen Network Operations (855) FLSPEED x106
On 29 Aug 2012, at 20:28, Nick Olsen <nick@flhsi.com> wrote:
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...
Filtering your de-aggregated prefixes in the presence of covering aggregates in this case would certainly not be foolish. :-) Please, unless you really know why you need to do otherwise, just originate your aggregates. Your friends, Every other Autonomous System
On Wed, 29 Aug 2012, Nick Olsen wrote:
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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
--- On Wed, 8/29/12, Nick Olsen <nick@flhsi.com> wrote:
From: Nick Olsen <nick@flhsi.com> Subject: Level 3 BGP Advertisements To: nanog@nanog.org Date: Wednesday, August 29, 2012, 12:28 PM Greetings all.
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?
Any other thoughts?
Nick Olsen Network Operations (855) FLSPEED x106
my 2 cents: I would think L3 would announce the /20 and /21's and no-export the /24 Why announce more-specifics if you can get away with a few shorter-prefixes. Do you have a setup where you have to announce /24's? If you can do with a /20 and two /21's, that would be the way to go. ./Randy
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. ________________________________________ From: Nick Olsen [nick@flhsi.com] Sent: Wednesday, August 29, 2012 2:28 PM To: nanog@nanog.org Subject: Level 3 BGP Advertisements Greetings all. 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? Any other thoughts? Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
On Wed, Aug 29, 2012 at 3:28 PM, Nick Olsen <nick@flhsi.com> wrote:
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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
That's very poor practice. Each announcements costs *other people* the better part of $10k per year.
That sounds ... really really big to me, Bill. Do you have a source for that cust-accounting number? Cheers, -- jra '2 or 3 orders of magnitude' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 12-08-29 04:55 PM, Jay Ashworth wrote:
----- Original Message -----
From: "William Herrin" <bill@herrin.us> That's very poor practice. Each announcements costs *other people* the better part of $10k per year. That sounds ... really really big to me, Bill. Do you have a source for that cust-accounting number?
Cheers, -- jra '2 or 3 orders of magnitude' a
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! - Pete
On Wed, Aug 29, 2012 at 4:55 PM, Jay Ashworth <jra@baylink.com> wrote:
That's very poor practice. Each announcements costs *other people* the better part of $10k per year.
That sounds ... really really big to me, Bill. Do you have a source for that cust-accounting number?
Hi Jay, 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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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. -----Original Message----- From: William Herrin [mailto:bill@herrin.us] Sent: Wednesday, August 29, 2012 3:36 PM To: nick@flhsi.com Cc: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements On Wed, Aug 29, 2012 at 3:28 PM, Nick Olsen <nick@flhsi.com> wrote:
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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 29-08-12 22:55, STARNES, CURTIS wrote:
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.
Yes, actually there are people over Internet blocking all IP's ending with 0 or 255 as a kind of bogon or other old wives' tale. -- Grzegorz Janoszka
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
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. John
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.
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
On Thu, Aug 30, 2012 at 11:50 AM, Blake Hudson <blake@ispn.net> wrote:
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.
I can distinctly remember having the issue in 10/8 address space with Win2k and WinXP
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
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. John
On Thu, 30 Aug 2012, Blake Hudson wrote:
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.
Just for kicks, I tried using a .0.0/16 and .255.255/16 adress for stuff in IOS (configured it as loopback and tried to establish bgp sessions etc), that didn't work so well. I don't remember exactly what the problem was, but I did indeed run into problems. -- Mikael Abrahamsson email: swmike@swm.pp.se
Just for kicks, I tried using a .0.0/16 and .255.255/16 adress for stuff in IOS (configured it as loopback and tried to establish bgp sessions etc), that didn't work so well. I don't remember exactly what the problem was, but I did indeed run into problems.
LU-CIX uses .255 and .0 for their route servers. See [1]. And it looks like most router fabrics can now handle BGP sessions to those addresses. Regards, Marc [1] http://www.lu-cix.lu/route-servers.html
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 . -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. "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. -----Original Message----- From: William Herrin [mailto:bill@herrin.us] Sent: Wednesday, August 29, 2012 3:36 PM To: nick@flhsi.com Cc: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements On Wed, Aug 29, 2012 at 3:28 PM, Nick Olsen <nick@flhsi.com> wrote:
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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>; Falls Church, VA 22042-3004
participants (19)
-
Andy Davidson -
Berry Mobley -
Blake Hudson -
Grzegorz Janoszka -
Hale, William C -
Harry Hoffman -
james machado -
Jay Ashworth -
John van Oppen -
Jon Lewis -
Marc Storck -
Matt Addison -
Mikael Abrahamsson -
Nick Olsen -
Peter Kristolaitis -
Randy -
Randy Bush -
STARNES, CURTIS -
William Herrin