Re: Bird vs Quagga revisited
MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
MPLS and VPLS on RouterOS works very well. -- Eduardo Schoedler Em 29/08/2012, às 12:39, Edward J. Dore edward.d...@freethought-internet.co.uk escreveu: MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
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
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.
[NANOG-announce] Call for Volunteers -- NANOG Education Committee
(my apologies to those receiving a second copy of this. The first copy ran into a mail filtering issue and didn't go out to most of the list) At the Vancouver meeting in June, I presented a preliminary proposal for a NANOG education initiative, which would put together a NANOG-created educational program for junior (and possibly more advanced) network operators. There was broad support from the community, and now it's time to refine the idea and turn it into something that can be implemented. We are seeking volunteers to join the Education Committee and work on the final proposal and its implementation. Among the issues that need to be decided are: - What format should the classes have? - What subject matter should they cover, and what should the curriculum be? - Who should be teaching them -- volunteers from the community or paid instructors? - Where should the classes be taught? At NANOG venues before, after, or during the conferences? At independent sites at non-conference times? - Cost structures: What should the classes cost and what will be included? - Other sources of financial support: Tuition? Sponsorships? Donations? Subsidies from the NANOG conferences? - And all sorts of other issues The expected commitment from members of the Education Committee will be as follows: - Attend bi-weekly conference calls - Research issues as needed, and provide feedback to the group The goal will be to have a reasonably solid proposal in time for the October NANOG meeting, and a final proposal in time for the February meeting. If you are interested in volunteering for this committee, please contact me. Thanks, Steve Gibbard NANOG Board s...@newnog.org ___ NANOG-announce mailing list nanog-annou...@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
Circuit of the americas aka COTA
Trendy name for the new racetrack/event venue outside austin. Does anyone know how one might get connectivity there? I figure there must be a few folks here prepping the place for the upcoming formula 1. The place seems to be a black hole to all the usual suspects. tia, chris -- Sent from my mobile device
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: LSMSGCV: Your message to curtis.star...@granburyisd.org was blocked as spam - please reply to forward it
Hi Harry, You sent your message direct to Curtis in addition to Nanog. Looks like his mailer acted on the direct one, not the list-relayed message. The message from Curtis' mailer implies that it's not a blanket challenge. Maybe you just discovered a problem with your mail server that he can help you identify and fix. Regards, Bill Herrin On Wed, Aug 29, 2012 at 9:02 PM, Harry Hoffman hhoff...@ip-solutions.net wrote: Damnit, Curtis. If your filtering mail like this then you should use a different identity for your nanog traffic! -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. challe...@granburyisd.org wrote: Did you send an email to: curtis.star...@granburyisd.org from: hhoff...@ip-solutions.net? If yes, it got caught as unsolicited email by our spam blocker. You can release the mail from spam quarantine by simply replying to this message. At the same time the spam blocker will recognize you as a trusted sender (from this email address) and automatically add you to my Allow list for this and any future communication. Many illegal spammers forge email addresses to try to get past spam blocking software. These spammers send hundreds of millions of spam messages a day, clogging email servers and wasting people’s time. We regret that these spammers have forced us to send this message to you. Original From: hhoff...@ip-solutions.net Original To: curtis.star...@granburyisd.org LSMSGCV For more information about our spam blocking software please visit www.lightspeedsystems.com -- 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
