Re: Level 3 BGP Advertisements
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 smime.p7s Description: S/MIME cryptographic signature
Re: Level 3 BGP Advertisements
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 hvgeekwt...@gmail.com wrote: On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS curtis.star...@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 ATT, 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
Re: Level 3 BGP Advertisements
On Thu, Aug 30, 2012 at 11:50 AM, Blake Hudson bl...@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 hvgeekwt...@gmail.com wrote: On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS curtis.star...@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 ATT, 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
RE: Level 3 BGP Advertisements
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
Re: Level 3 BGP Advertisements
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 Abrahamssonemail: swm...@swm.pp.se
Re: Level 3 BGP Advertisements
On 29 Aug 2012, at 20:28, Nick Olsen n...@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
Re: Level 3 BGP Advertisements
[...] Please, unless you really know why you need to do otherwise, just originate your aggregates. +1
Re: Level 3 BGP Advertisements
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_
Re: Level 3 BGP Advertisements
--- On Wed, 8/29/12, Nick Olsen n...@flhsi.com wrote: From: Nick Olsen n...@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
Re: Level 3 BGP Advertisements
Thanks for the input Jon. I should note that is exactly what we are doing. The /24's are actually tagged with the advertise to customers, prepend to peers community. Nick Olsen Network Operations (855) FLSPEED x106 From: Jon Lewis jle...@lewis.org Sent: Wednesday, August 29, 2012 3:48 PM To: Nick Olsen n...@flhsi.com Subject: Re: Level 3 BGP Advertisements 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_
RE: Level 3 BGP Advertisements
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 [n...@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.
Re: Level 3 BGP Advertisements
I hear you guys, It's done that way for a bit of traffic steering. If I could get away with just the aggregates I would, Trust me. Nick Olsen Network Operations (855) FLSPEED x106 From: Berry Mobley be...@gadsdenst.org Sent: Wednesday, August 29, 2012 3:45 PM To: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements [...] Please, unless you really know why you need to do otherwise, just originate your aggregates. +1
Re: Level 3 BGP Advertisements
On Wed, Aug 29, 2012 at 2:56 PM, Nick Olsen n...@flhsi.com wrote: I hear you guys, It's done that way for a bit of traffic steering. If I could get away with just the aggregates I would, Trust me. Nick Olsen Network Operations (855) FLSPEED x106 From: Berry Mobley be...@gadsdenst.org Sent: Wednesday, August 29, 2012 3:45 PM To: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements [...] Please, unless you really know why you need to do otherwise, just originate your aggregates. +1 That should be unnessecary, the local prefs should already be winning as a customer vs transit/peer for equal prefix length. As an aside, generally inbound traffic steering as a reason for disaggregation is fairly frowned upon by the community at large as it effectively makes everyone else pay more in additional hardware cost for your savings. -Blake
Re: Level 3 BGP Advertisements
My more specifics are advertise to customers only (not supposed to be visible to peers), which was how I found that TWT had transitioned from Level3 peer to customer...and I'm only going 1 bit more specific (not down to the /24s) for TE purposes. On Wed, 29 Aug 2012, Nick Olsen wrote: Thanks for the input Jon. I should note that is exactly what we are doing. The /24's are actually tagged with the advertise to customers, prepend to peers community. Nick Olsen Network Operations (855) FLSPEED x106 From: Jon Lewis jle...@lewis.org Sent: Wednesday, August 29, 2012 3:48 PM To: Nick Olsen n...@flhsi.com Subject: Re: Level 3 BGP Advertisements 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_ -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: Level 3 BGP Advertisements
-Original Message- From: Blake Dunlap [mailto:iki...@gmail.com] Sent: Wednesday, August 29, 2012 4:00 PM To: n...@flhsi.com Cc: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements On Wed, Aug 29, 2012 at 2:56 PM, Nick Olsen n...@flhsi.com wrote: I hear you guys, It's done that way for a bit of traffic steering. If I could get away with just the aggregates I would, Trust me. Nick Olsen Network Operations (855) FLSPEED x106 From: Berry Mobley be...@gadsdenst.org Sent: Wednesday, August 29, 2012 3:45 PM To: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements [...] Please, unless you really know why you need to do otherwise, just originate your aggregates. +1 That should be unnessecary, the local prefs should already be winning as a customer vs transit/peer for equal prefix length. As an aside, generally inbound traffic steering as a reason for disaggregation is fairly frowned upon by the community at large as it effectively makes everyone else pay more in additional hardware cost for your savings. -Blake If you have provided addressing from your aggregate to your customer and they have indicated that they are multi-homing, you need to preserve their prefix-length in your outbound advertisements, or the redundant provider carries the inbound traffic. Is this also frowned on? To me, this is the multihoming tax we all pay for. Paul
Re: Level 3 BGP Advertisements
If you have provided addressing from your aggregate to your customer and they have indicated that they are multi-homing, you need to preserve their prefix-length in your outbound advertisements, or the redundant provider carries the inbound traffic. Is this also frowned on? To me, this is the multihoming tax we all pay for. Paul Someone multihoming below you on PA space is a pretty special case (part of why I said generally above actually), but definately one I would consider valid as for passing the announcements through from their AS. -Blake
Re: Level 3 BGP Advertisements
On Wed, Aug 29, 2012 at 3:28 PM, Nick Olsen n...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
$10k per BGP prefix? (was Re: Level 3 BGP Advertisements)
- Original Message - From: William Herrin b...@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 j...@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
RE: Level 3 BGP Advertisements
Sorry for the top post... Not necessarily a Level 3 problem but; We are announcing our /19 network as one block via BGP through ATT, 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:b...@herrin.us] Sent: Wednesday, August 29, 2012 3:36 PM To: n...@flhsi.com Cc: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements On Wed, Aug 29, 2012 at 3:28 PM, Nick Olsen n...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Level 3 BGP Advertisements
On 29-08-12 22:55, STARNES, CURTIS wrote: We are announcing our /19 network as one block via BGP through ATT, 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
Re: $10k per BGP prefix? (was Re: Level 3 BGP Advertisements)
On 12-08-29 04:55 PM, Jay Ashworth wrote: - Original Message - From: William Herrin b...@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
Re: $10k per BGP prefix? (was Re: Level 3 BGP Advertisements)
On Wed, Aug 29, 2012 at 4:55 PM, Jay Ashworth j...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Level 3 BGP Advertisements
On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS curtis.star...@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 ATT, 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
RE: Level 3 BGP Advertisements
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
Re: Level 3 BGP Advertisements
Sent from my mobile device, so please excuse any horrible misspellings. On Aug 29, 2012, at 18:30, james machado hvgeekwt...@gmail.com wrote: On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS curtis.star...@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 ATT, 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.
RE: Level 3 BGP Advertisements
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.star...@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 ATT, 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:b...@herrin.us] Sent: Wednesday, August 29, 2012 3:36 PM To: n...@flhsi.com Cc: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements On Wed, Aug 29, 2012 at 3:28 PM, Nick Olsen n...@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 her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/; Falls Church, VA 22042-3004
Re: Level 3 BGP Advertisements
In practice, We've always advertised our space all the way down to /24's ^ really bad anti-social and disgusting
