Re: Thanks Let's Prevent this in the Future.
One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors. We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are signed but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/ http://www.labs.lacnic.net/rpkitools/looking_glass/ Regards, -as On 1 Feb 2012, at 06:58, Kelvin Williams wrote: First off, I'd like to thank everyone on this list who have reached out today and offered us help with our hijacked network space. It's so refreshing to see that there are still so many who refuse to leave a man/woman down. I'm not going to place any blame, its useless. There were lies, there were incompetencies, and there was negligence but that is now water under the bridge. However, I think that we as network operators have a duty to each other to make sure we don't allow a downstream customer wreck the operations of another entity who has been rightfully allocated resources. A few months ago, when establishing a new peering relationship I was encouraged (actually required) to utilize one of the IRRs. I took the time to register all of my routes, ASNs, etc. However, as I learned today, this was probably done in vain. Too many people won't spend the extra 30-seconds to verify the information listed there or in ARINs WHOIS. I don't care what a customer tells me, too many times I've found they aren't 100% honest either for malicious/fraudulent reasons or they are unknowing. So, for our networks or the networks we manage, we want to verify what a customer is saying to prevent what happened to us today. I'd like to get a conversation going and possibly some support of an initiative to spend that extra 30-seconds to verify ownership and authorization of network space to be advertised. Additionally, if someone rings your NOC's line an industry-standard process of verifying ownership and immediately responding by filtering out announcements. There's no sense in allowing a service provider to be impaired because a spammer doesn't want to give up clean IP space. Do you protect a bad customer or the Internet as a whole? I pick the Internet as a whole. How can we prevent anyone else from ever enduring this again? While we may never stop it from ever happening, spammers (that's what we got hit by today) are a dime a dozen and will do everything possible to hit an Inbox, so how can we establish a protocol to immediate mitigate the effects of an traffic-stopping advertisement? I thought registering with IRRs and up-to-date information in ARINs WHOIS was sufficient, apparently I was wrong. Not everyone respects them, but then again, they aren't very well managed (I've got several networks with antiquated information I've been unable to remove, it doesn't impair us normally, but its still there). What can we do? Better yet, how do we as a whole respond when we encounter upstream providers who refuse to look at the facts and allow another to stay down? kw -- Kelvin Williams Sr. Service Delivery Engineer Broadband Carrier Services Altus Communications Group, Inc. If you only have a hammer, you tend to see every problem as a nail. -- Abraham Maslow
Re: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
Randy Bush ra...@psg.com writes: well, not exactly. to quote myself from the other week in another forum [ 30 lines deleted ] Sorry to drone on, but these three really need to be differentiated. The truly wonderful thing about the evolution of BGP security is its elegant simplicity. It is good to know that the barriers to entry for the IRR system (templates, objects, Dear Colleague emails from the auto-dbm robot, etc) have been eradicated in favor of simple, easy-to-understand and maintain maintain digital certificate chains. I predict epic uptake the likes of which we haven't seen since I filed my last NACR. -r
Re: Thanks Let's Prevent this in the Future.
In related news, the IETF working group that is writing standards for the RPKI is having an interim meeting in San Diego just after NANOG. They deliberately chose that place/time to make it easy for NANOG attendees to contribute, so comments from this community are definitely welcome. http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209 On Fri, Feb 3, 2012 at 7:16 AM, Arturo Servin aser...@lacnic.net wrote: One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors. We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are signed but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/ http://www.labs.lacnic.net/rpkitools/looking_glass/ Regards, -as On 1 Feb 2012, at 06:58, Kelvin Williams wrote: First off, I'd like to thank everyone on this list who have reached out today and offered us help with our hijacked network space. It's so refreshing to see that there are still so many who refuse to leave a man/woman down. I'm not going to place any blame, its useless. There were lies, there were incompetencies, and there was negligence but that is now water under the bridge. However, I think that we as network operators have a duty to each other to make sure we don't allow a downstream customer wreck the operations of another entity who has been rightfully allocated resources. A few months ago, when establishing a new peering relationship I was encouraged (actually required) to utilize one of the IRRs. I took the time to register all of my routes, ASNs, etc. However, as I learned today, this was probably done in vain. Too many people won't spend the extra 30-seconds to verify the information listed there or in ARINs WHOIS. I don't care what a customer tells me, too many times I've found they aren't 100% honest either for malicious/fraudulent reasons or they are unknowing. So, for our networks or the networks we manage, we want to verify what a customer is saying to prevent what happened to us today. I'd like to get a conversation going and possibly some support of an initiative to spend that extra 30-seconds to verify ownership and authorization of network space to be advertised. Additionally, if someone rings your NOC's line an industry-standard process of verifying ownership and immediately responding by filtering out announcements. There's no sense in allowing a service provider to be impaired because a spammer doesn't want to give up clean IP space. Do you protect a bad customer or the Internet as a whole? I pick the Internet as a whole. How can we prevent anyone else from ever enduring this again? While we may never stop it from ever happening, spammers (that's what we got hit by today) are a dime a dozen and will do everything possible to hit an Inbox, so how can we establish a protocol to immediate mitigate the effects of an traffic-stopping advertisement? I thought registering with IRRs and up-to-date information in ARINs WHOIS was sufficient, apparently I was wrong. Not everyone respects them, but then again, they aren't very well managed (I've got several networks with antiquated information I've been unable to remove, it doesn't impair us normally, but its still there). What can we do? Better yet, how do we as a whole respond when we encounter upstream providers who refuse to look at the facts and allow another to stay down? kw -- Kelvin Williams Sr. Service Delivery Engineer Broadband Carrier Services Altus Communications Group, Inc. If you only have a hammer, you tend to see every problem as a nail. -- Abraham Maslow
Re: [#135346] Unauthorized BGP Announcements (follow up to Hijacked Networks)
On Thu, 2 Feb 2012, Dave Pooser wrote: ...and all we need is for billion-dollar corporations to start putting moral rectitude ahead of profits. Well, heck, that should start happening any day now! And then FedEx will deliver my unicorn! /snark Your unicorn has been impounded by Customs. jms
Re: Verisign deep-hacked. For months.
- Original Message - From: Jeff Wheeler j...@inconcepts.biz On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: So what part of VRSN got broken into? They do a lot more than just DNS. Indeed, VeriSign owns Illuminet, who are mission-critical for POTS. Illuminet is also in the business of recording telephone calls, SMS messages, etc. for law enforcement. Illuminet? Shea and Wilson would be proud. Cheers, -- jr 'and somewhere, an evil geek is dry-washing his hands' 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 http://photo.imageinc.us +1 727 647 1274
[POLITICS] ICANN elections
There are four really good candidates. Please consider sending in a statement of support for one of them. /bill - Forwarded message - Date: Fri, 03 Feb 2012 09:38:06 +1000 To: Bill Manning bmann...@karoshi.com Subject: Comment Period for ICANN Board Seat 9 Election Consistent with the ASO Memorandum of Understanding and ICANN Bylaws, the Address Supporting Organization Address Council (ASO AC) is responsible for the appointment of a representative to serve on Seat Number 9 of the ICANN Board. The ASO AC is pleased to announce the following four candidates for its upcoming appointment. The Candidates are: - Thomas Eric Brunner-Williams - Martin J. Levy - William Manning - Raymond Alan Plzak In accordance with the ASO AC election procedures, a comment period is now open. A short biography is available and supporting comment facilities for each candidate may be found at: http://aso.icann.org/people/icann-board-elections/2012-elections/ The comment period will close at 23:59 UTC on 19 April 2012. Comments will be moderated. ASO Secretariat secretar...@aso.icann.org - End forwarded message -
Re: Verisign deep-hacked. For months.
On Thu, Feb 2, 2012 at 10:34 PM, Jeff Wheeler j...@inconcepts.biz wrote: On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: So what part of VRSN got broken into? They do a lot more than just DNS. Indeed, VeriSign owns Illuminet, who are mission-critical for POTS. Illuminet is also in the business of recording telephone calls, SMS messages, etc. for law enforcement. Wasn't this division acquired by TNS ? http://www.bizjournals.com/washington/stories/2009/05/04/daily5.html Rubens
RE: Thanks Let's Prevent this in the Future.
Thanks for the reminder, Richard. Yes, as I announced earlier (see http://mailman.nanog.org/pipermail/nanog/2012-January/044493.html - the message with the corrected date), there is an interim sidr meeting on Thu *9* Feb in San Diego. Registration is free. Registration is easy (email). Registration is open to all. Registration is open ended. Registration is encouraged (so we know how many to expect). As the message says, see the sidr wiki http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209 for agenda and a list of attendees. --Sandy Murphy From: Richard Barnes [richard.bar...@gmail.com] Sent: Friday, February 03, 2012 8:09 AM To: Arturo Servin Cc: nanog Subject: Re: Thanks Let's Prevent this in the Future. In related news, the IETF working group that is writing standards for the RPKI is having an interim meeting in San Diego just after NANOG. They deliberately chose that place/time to make it easy for NANOG attendees to contribute, so comments from this community are definitely welcome. http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209 snip
Re: [POLITICS] ICANN elections
What Bill said. Comments to the website (http://aso.icann.org/people/icann-board-elections/2012-elections/) are moderated, so any statements of support won't show up (except to the person who makes the statement) until the moderator has gotten a round tuit. The [s]electorate to be persuaded is here: http://aso.icann.org/people/address-council/address-council-members/ Cheers, Eric There are four really good candidates. Please consider sending in a statement of support for one of them. /bill - Forwarded message - Date: Fri, 03 Feb 2012 09:38:06 +1000 To: Bill Manning bmann...@karoshi.com Subject: Comment Period for ICANN Board Seat 9 Election Consistent with the ASO Memorandum of Understanding and ICANN Bylaws, the Address Supporting Organization Address Council (ASO AC) is responsible for the appointment of a representative to serve on Seat Number 9 of the ICANN Board. The ASO AC is pleased to announce the following four candidates for its upcoming appointment. The Candidates are: - Thomas Eric Brunner-Williams - Martin J. Levy - William Manning - Raymond Alan Plzak In accordance with the ASO AC election procedures, a comment period is now open. A short biography is available and supporting comment facilities for each candidate may be found at: http://aso.icann.org/people/icann-board-elections/2012-elections/ The comment period will close at 23:59 UTC on 19 April 2012. Comments will be moderated. ASO Secretariat secretar...@aso.icann.org - End forwarded message -
Re: [rt-users] External Auth using Active Directory 2008
I would use ldapsearch on that machine to make sure you can bind to the AD server using the login credentials in your Site_Config. Make sure you are using the proper certificates to connect via the TLS you have configured. I've noticed that being one of the biggest problems with ldap and Windows 2008 and 2008 R2 AD servers. james
Re: [rt-users] External Auth using Active Directory 2008
my apologies - fat fingered the email address james
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 04 Feb, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 395820 Prefixes after maximum aggregation: 169388 Deaggregation factor: 2.34 Unique aggregates announced to Internet: 191947 Total ASes present in the Internet Routing Table: 40003 Prefixes per ASN: 9.89 Origin-only ASes present in the Internet Routing Table: 32689 Origin ASes announcing only one prefix: 15521 Transit ASes present in the Internet Routing Table:5393 Transit-only ASes present in the Internet Routing Table:142 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 315 Unregistered ASNs in the Routing Table: 120 Number of 32-bit ASNs allocated by the RIRs: 2257 Number of 32-bit ASNs visible in the Routing Table:1921 Prefixes from 32-bit ASNs in the Routing Table:4672 Special use prefixes present in the Routing Table:2 Prefixes being announced from unallocated address space:120 Number of addresses announced to Internet: 2512081104 Equivalent to 149 /8s, 187 /16s and 80 /24s Percentage of available address space announced: 67.8 Percentage of allocated address space announced: 67.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.0 Total number of prefixes smaller than registry allocations: 167934 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:97613 Total APNIC prefixes after maximum aggregation: 31507 APNIC Deaggregation factor:3.10 Prefixes being announced from the APNIC address blocks: 93918 Unique aggregates announced from the APNIC address blocks:39044 APNIC Region origin ASes present in the Internet Routing Table:4648 APNIC Prefixes per ASN: 20.21 APNIC Region origin ASes announcing only one prefix: 1238 APNIC Region transit ASes present in the Internet Routing Table:731 Average APNIC Region AS path length visible:4.3 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table:140 Number of APNIC addresses announced to Internet: 635833440 Equivalent to 37 /8s, 230 /16s and 12 /24s Percentage of available APNIC address space announced: 80.6 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:148115 Total ARIN prefixes after maximum aggregation:75385 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 120087 Unique aggregates announced from the ARIN address blocks: 49290 ARIN Region origin ASes present in the Internet Routing Table:14884 ARIN Prefixes per ASN: 8.07 ARIN Region origin ASes announcing only one prefix:
bufferbloat videos are up.
If people have heard of bufferbloat at all, it is usually just an abstraction despite having had personal experience with it. Bufferbloat can occur in your operating system, your home router, your broadband gear, wireless, and almost anywhere in the Internet. Most still think that if experience poor Internet speed means they must need more bandwidth, and take vast speed variation for granted. Sometimes, adding bandwidth can actually hurt rather than help. Most people have no idea what they can do about bufferbloat. So I’ve been working to put together several demos to help make bufferbloat concrete, and demonstrate at least partial mitigation. The mitigation shown may or may not work in your home router, and you need to be able to set both upload and download bandwidth. People like Fred Baker, with fiber to his house and Cisco routers, need not pay attention Two of four cases we commonly all suffer from at home are: 1. Broadband bufferbloat (upstream) 2. Home router bufferbloat (downstream) Rather than attempt to show worst case bufferbloat which can easily induce complete failure, I decided to demonstrate these two cases of “typical” bufferbloat as shown by the ICSI data. As the bufferbloat varies widely as theICSI data http://gettys.files.wordpress.com/2010/12/uplink_buffer_all.pngshows http://gettys.files.wordpress.com/2010/12/downlink_buffer_all.png, your mileage will also vary widely. There are two versions of the video: 1. A short bufferbloat video http://www.youtube.com/watch?v=npiG7EBzHOU, of slightly over 8 minutes, which includes both demonstrations, but elides most of the explanation. It’s intent is to get people “hooked” so they will want to know more. 2. The longer version of the video http://www.youtube.com/watch?v=-D-cJNtKwuwclocks in at 21 minutes, includes both demonstrations, but gives a simplified explanation of bufferbloat’s cause, to encourage people to dig yet further. Best regards, Jim Gettys
IPv6 dual stacking and route tables
So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency. If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. Any guidance would be appreciated. Thanks. -Hammer- I was a normal American nerd -Jack Herer
Re: IPv6 dual stacking and route tables
On Feb 3, 2012, at 3:10 PM, -Hammer- wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency. If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. Any guidance would be appreciated. Thanks. -Hammer- We have been accepting our upstreams' connected and customer routes only (v4) and full routes (v6) without issue. I can't say that I have previously heard of the DNS performance example/concern you provided above
Re: IPv6 dual stacking and route tables
You should accept the full v6 table, because some IPs may not, currently, be reachable via one of the carriers. On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- bhmc...@gmail.com wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency. If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. Any guidance would be appreciated. Thanks. -Hammer- I was a normal American nerd -Jack Herer
Re: IPv6 dual stacking and route tables
On Fri, 3 Feb 2012, -Hammer- wrote: If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. We currently take full v4 and v6 routes, however we do not yet have end-users officially on v6 (users doing their own 6to4 tunnels and stuff like Teredo notwithstanding), so I don't have any experience with the A/ resolution asymmetry you're describing. jms
Re: IPv6 dual stacking and route tables
On Fri, Feb 3, 2012 at 12:10 PM, -Hammer- bhmc...@gmail.com wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency. If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. Any guidance would be appreciated. Thanks. Well. I don't really follow the above text. But, the principle is the same for IPv4 or IPv6. If you take a full or partial table, your router can make a better choice than just getting default (only maybe, BGP is never guaranteeing anything about performance). That said, in v6, it is a little bit more important, IMHO, to take the ISP routes instead of just a default since the v6 peering is not as robust out on the Internet. There are still turf wars going on or some SPs are still not peering IPv6 in all the places they peer for IPv4. Less peering = longer latency. But, this situation has improved dramatically in the last 12 months. In the end, my guidance is to take provider routes or customer route + default. This helps your router make an educated guess without absorbing all the churn and gunk that a full BGP feed hits your router with. Make the SP trim those routes on their side so you don't see it. CB -Hammer- I was a normal American nerd -Jack Herer
Re: IPv6 dual stacking and route tables
On 2012-02-03 21:10 , -Hammer- wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Dear Hammer, Welcome to the 21th century. 2012 is going to the year (they claim, again ;) of IPv6 thus it is better to start before the big launch event that is this year, (of which there was also one back in in 2004: http://www.global-ipv6.org/ for the folks who have IPv6 for some time now ;) Better late than never some would say. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The only advantage of more routes, in both IPv4 and IPv6 is that the path selection can be better. An end-host does not make this decision where packets flow, thus having a full route or not should not matter much, except that the route might be more optimal. No DNS involvement here yet. The trick comes with Happy-Eyeballs alike setups (especially Mac OSX Lion and up which does not follow that spec and in which it cannot be turned off either, which is awesome when you are debugging things...) Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool. Chrome has it's own HE implementation, thus if you run Chrome on a Mac you will have sometimes one sometimes another connect depending on if you are using Safari or Chrome for instance as Safari does use the system provided things. Ping will pick another again etc. It will be quite random all the time. The fun with the Mac OS X implementation is that it keeps a local cache of per-destination latency/speed information. If you thus have two default routes, be that IPv4 or IPv6, and your routers are swapping paths between either and thus don't have a stable outgoing path those latencies will vary and thus the pretty HE algorithms will be very confused. This is likely why your source recommended to have a full path, as per sub-prefix the path will become more stable and established than if you are doing hot-potato with two defaults. Greets, Jeroen
Re: IPv6 dual stacking and route tables
Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online and offline responses. That was fast. The struggle is that I'm having trouble seeing how/why it would matter other than potential latency on the IPv4 side. IPv6 conversations usually involve taking the full table when dealing with multi-homed/multi-site setups. IPv4 I didn't really consider (taking the full table) until I mentioned this to some of my vendors technical folks and it caused a lot of reflection. Not on the L3 part. Just on the DNS part. This appears to be a tough subject area when it comes to V4/V6 deployment strategies. The bottom line is that I'll take whatever the carrier feeds in V6. Just trying to see where I would be missing out by not doing the same in V4. Again, I have the hardware to support it and I really have no reason not to do it. I just want to be able to justify to myself why I'm doing it. A lot of kinks to work out this year. -Hammer- I was a normal American nerd -Jack Herer On 2/3/2012 2:28 PM, Jeroen Massar wrote: On 2012-02-03 21:10 , -Hammer- wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Dear Hammer, Welcome to the 21th century. 2012 is going to the year (they claim, again ;) of IPv6 thus it is better to start before the big launch event that is this year, (of which there was also one back in in 2004: http://www.global-ipv6.org/ for the folks who have IPv6 for some time now ;) Better late than never some would say. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The only advantage of more routes, in both IPv4 and IPv6 is that the path selection can be better. An end-host does not make this decision where packets flow, thus having a full route or not should not matter much, except that the route might be more optimal. No DNS involvement here yet. The trick comes with Happy-Eyeballs alike setups (especially Mac OSX Lion and up which does not follow that spec and in which it cannot be turned off either, which is awesome when you are debugging things...) Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool. Chrome has it's own HE implementation, thus if you run Chrome on a Mac you will have sometimes one sometimes another connect depending on if you are using Safari or Chrome for instance as Safari does use the system provided things. Ping will pick another again etc. It will be quite random all the time. The fun with the Mac OS X implementation is that it keeps a local cache of per-destination latency/speed information. If you thus have two default routes, be that IPv4 or IPv6, and your routers are swapping paths between either and thus don't have a stable outgoing path those latencies will vary and thus the pretty HE algorithms will be very confused. This is likely why your source recommended to have a full path, as per sub-prefix the path will become more stable and established than if you are doing hot-potato with two defaults. Greets, Jeroen
Re: IPv6 dual stacking and route tables
On 2012-02-03 21:37 , -Hammer- wrote: Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online and offline responses. That was fast. The struggle is that I'm having trouble seeing how/why it would matter other than potential latency on the IPv4 side. IPv6 conversations usually involve taking the full table when dealing with multi-homed/multi-site setups. IPv4 I didn't really consider (taking the full table) until I mentioned this to some of my vendors technical folks and it caused a lot of reflection. Not on the L3 part. Just on the DNS part. This appears to be a tough subject area when it comes to V4/V6 deployment strategies. The bottom line is that I'll take whatever the carrier feeds in V6. Just trying to see where I would be missing out by not doing the same in V4. Again, I have the hardware to support it and I really have no reason not to do it. I just want to be able to justify to myself why I'm doing it. Why you want non-defaults in both IPv4 and IPv6: - more possible paths - less chances of blackholes. And of course, those paths will be more stable and you don't get hot-potato swapping between two defaults. And that in turn allows the Happy Eyeballs mechanisms to do their jobs much better as they keep a history per host or prefix, they assume IPv6 /48's and IPv4 /24's from what I have seen, in some cases. Greets, Jeroen
Re: IPv6 dual stacking and route tables
OK. Looking forward to getting the lab up. Since I can handle the volume I'll take both tables. At least in the lab. Looking forward to doing some experiments with DNS just to see what all the fuss is about. Looks like I'll need to order a Mac for the lab. No harm there. :) -Hammer- I was a normal American nerd -Jack Herer On 2/3/2012 2:47 PM, Jeroen Massar wrote: On 2012-02-03 21:37 , -Hammer- wrote: Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online and offline responses. That was fast. The struggle is that I'm having trouble seeing how/why it would matter other than potential latency on the IPv4 side. IPv6 conversations usually involve taking the full table when dealing with multi-homed/multi-site setups. IPv4 I didn't really consider (taking the full table) until I mentioned this to some of my vendors technical folks and it caused a lot of reflection. Not on the L3 part. Just on the DNS part. This appears to be a tough subject area when it comes to V4/V6 deployment strategies. The bottom line is that I'll take whatever the carrier feeds in V6. Just trying to see where I would be missing out by not doing the same in V4. Again, I have the hardware to support it and I really have no reason not to do it. I just want to be able to justify to myself why I'm doing it. Why you want non-defaults in both IPv4 and IPv6: - more possible paths - less chances of blackholes. And of course, those paths will be more stable and you don't get hot-potato swapping between two defaults. And that in turn allows the Happy Eyeballs mechanisms to do their jobs much better as they keep a history per host or prefix, they assume IPv6 /48's and IPv4 /24's from what I have seen, in some cases. Greets, Jeroen
Re: IPv6 dual stacking and route tables
On Feb 3, 2012, at 3:25 PM, Philip Dorr wrote: You should accept the full v6 table, because some IPs may not, currently, be reachable via one of the carriers. Definitely agreed here, and this is why we take full v6 tables. Especially since one of our upstreams does not peer with at least one other large network; if we took just a default from them, we would likely be sending them traffic which they in turn do not have a route for whereas the other upstream of ours does. On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- bhmc...@gmail.com wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency. If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. Any guidance would be appreciated. Thanks. -Hammer- I was a normal American nerd -Jack Herer
BGP Update Report
BGP Update Report Interval: 26-Jan-12 -to- 02-Feb-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS840253901 3.1% 29.0 -- CORBINA-AS OJSC Vimpelcom 2 - AS28683 39445 2.3% 646.6 -- BENINTELECOM 3 - AS580033859 1.9% 117.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 4 - AS12479 25806 1.5% 154.5 -- UNI2-AS France Telecom Espana SA 5 - AS982925640 1.5% 36.9 -- BSNL-NIB National Internet Backbone 6 - AS32528 23059 1.3%7686.3 -- ABBOTT Abbot Labs 7 - AS23154 20656 1.2%5164.0 -- SANMINA-SCI Sanmina-SCI Corporation 8 - AS20632 20258 1.2% 519.4 -- PETERSTAR-AS PeterStar 9 - AS702918611 1.1% 7.2 -- WINDSTREAM - Windstream Communications Inc 10 - AS671318375 1.1% 37.7 -- IAM-AS 11 - AS24560 18180 1.0% 46.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS31148 16044 0.9% 24.7 -- FREENET-AS FreeNet ISP 13 - AS606612493 0.7%6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 14 - AS958311691 0.7% 11.9 -- SIFY-AS-IN Sify Limited 15 - AS17974 11635 0.7% 8.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS597611626 0.7% 118.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - AS453811580 0.7% 22.7 -- ERX-CERNET-BKB China Education and Research Network Center 18 - AS650311445 0.7% 7.0 -- Axtel, S.A.B. de C.V. 19 - AS37004 11269 0.7% 433.4 -- SUBURBAN-AS 20 - AS43348 10512 0.6% 79.6 -- TATARINOVA-AS PE Tatarinova Alla Ivanovna TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS291269346 0.5%9346.0 -- DATIQ-AS Datiq B.V. 2 - AS32528 23059 1.3%7686.3 -- ABBOTT Abbot Labs 3 - AS606612493 0.7%6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 4 - AS23154 20656 1.2%5164.0 -- SANMINA-SCI Sanmina-SCI Corporation 5 - AS102093894 0.2%3894.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center 6 - AS5868 1677 0.1%1677.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - AS533621001 0.1%1001.0 -- MIXIT-AS - Mixit, Inc. 8 - AS16045 830 0.1% 830.0 -- SPEKTAR-AD Spektar AD 9 - AS27295 670 0.0% 670.0 -- GENICA - Genica Corporation 10 - AS36980 660 0.0% 660.0 -- JOHNHOLT-ASN 11 - AS28683 39445 2.3% 646.6 -- BENINTELECOM 12 - AS532221770 0.1% 590.0 -- 13 - AS19226 565 0.0% 565.0 -- AURA-SOUTH - A.U.R.A 14 - AS174083247 0.2% 541.2 -- ABOVE-AS-AP AboveNet Communications Taiwan 15 - AS28123 527 0.0% 527.0 -- 16 - AS528611575 0.1% 525.0 -- 17 - AS20632 20258 1.2% 519.4 -- PETERSTAR-AS PeterStar 18 - AS5863 473 0.0% 473.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS49047 471 0.0% 471.0 -- PCSI-ASN Pentacomp Systemy Informatyczne S.A. 20 - AS27689 465 0.0% 465.0 -- Laboratorio Nacional de Informática Avanzada AC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 148.164.14.0/24 20619 1.1% AS23154 -- SANMINA-SCI Sanmina-SCI Corporation 2 - 84.204.132.0/24 20117 1.1% AS20632 -- PETERSTAR-AS PeterStar 3 - 130.36.34.0/2411529 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/2411529 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 122.161.0.0/1610190 0.6% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - 217.170.24.0/219346 0.5% AS29126 -- DATIQ-AS Datiq B.V. 7 - 62.36.252.0/22 8037 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 202.92.235.0/246528 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 9 - 150.225.0.0/16 6247 0.3% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 10 - 204.29.239.0/246246 0.3% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 11 - 62.36.249.0/24 6087 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 62.36.241.0/24 5537 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 13 - 194.63.9.0/24 5387 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 14 - 62.36.210.0/24 5289 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 15 - 190.67.172.0/225051 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 16 - 111.125.126.0/24 4975 0.3% AS17639 -- COMCLARK-AS ComClark Network Technology Corp. 17 -
The Cidr Report
This report has been generated at Fri Feb 3 21:12:45 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
27-01-12396272 229808
28-01-12395687 230060
29-01-12396508 229971
30-01-12396324 229998
31-01-12396621 229745
01-02-12396817 230146
02-02-12397186 229608
03-02-12397625 230080
AS Summary
40099 Number of ASes in routing system
16816 Number of ASes announcing only one prefix
3445 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
109882880 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 03Feb12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 398212 230080 16813242.2% All ASes
AS6389 3445 204 324194.1% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 3260 1427 183356.2% WINDSTREAM - Windstream
Communications Inc
AS18566 2093 413 168080.3% COVAD - Covad Communications
Co.
AS4766 2478 1005 147359.4% KIXS-AS-KR Korea Telecom
AS22773 1499 118 138192.1% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4755 1528 197 133187.1% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS2118 1391 76 131594.5% RELCOM-AS OOO NPO Relcom
AS4323 1610 386 122476.0% TWTC - tw telecom holdings,
inc.
AS28573 1624 407 121774.9% NET Servicos de Comunicao S.A.
AS1785 1868 789 107957.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS7552 1408 363 104574.2% VIETEL-AS-AP Vietel
Corporation
AS19262 1386 401 98571.1% VZGNI-TRANSIT - Verizon Online
LLC
AS10620 1735 766 96955.9% Telmex Colombia S.A.
AS8402 1653 726 92756.1% CORBINA-AS OJSC Vimpelcom
AS7303 1260 366 89471.0% Telecom Argentina S.A.
AS26615 885 33 85296.3% Tim Celular S.A.
AS8151 1337 550 78758.9% Uninet S.A. de C.V.
AS18101 935 156 77983.3% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1102 344 75868.8% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS24560 1010 299 71170.4% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS30036 1437 753 68447.6% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS9498 878 206 67276.5% BBIL-AP BHARTI Airtel Ltd.
AS9394 878 210 66876.1% CRNET CHINA RAILWAY
Internet(CRNET)
AS7545 1642 998 64439.2% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS3356 1098 457 64158.4% LEVEL3 Level 3 Communications
AS17676 687 74 61389.2% GIGAINFRA Softbank BB Corp.
AS17974 1724 1121 60335.0% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS11172 698 113 58583.8% Alestra, S. de R.L. de C.V.
AS15557 1096 511 58553.4% LDCOMNET Societe Francaise du
Radiotelephone S.A
AS4804 660 95 56585.6% MPX-AS Microplex PTY LTD
Total 44305135643074169.4% Top 30 total
Possible Bogus Routes
10.86.64.32/30
Re: This network is too good...
On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom r...@seastrom.com wrote: Hi all, Any thoughts on products that screw up networks in deterministic (and realistic found-in-the-wild) ways? I'm thinking of stuff like PacketStorm, Dummynet, etc. Dial up jitter, latency, tail drop, RED, whatever... (I know someone's gonna say Just buy a Brand Z FubarSwitch 3k, they will screw up your whole network and you don't even have to configure it to do so!) I'm all-ears like Ross Perot. Thanks, -r Definite +1 for dummynet on freebsd; I've used in the lab at layer 2 in bridge mode, and layer 3 both, for doing testing. latency introduction is good down to a few ms, but isn't accurate below that--but for most of what we do, in terms of simulating latency and loss/jitter, it works like a charm. Matt
Re: IPv6 dual stacking and route tables
On Feb 3, 2012, at 12:10 PM, -Hammer- wrote: So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency. If you have a specific route to a record but a less specific route to an A record the potential is for the trip to take longer. That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6. Any guidance would be appreciated. Thanks. -Hammer- I was a normal American nerd -Jack Herer On a purely theoretical level, mores specific routes are always better than default. So, on a purely theoretical level: IDEAL: Full routes, both protocols Advantage: Most information available, theoretically best decisions possible. Disadvantage: Router cost rivals national debt of third-world country. Second best:Full routes IPv6, default or partial routes IPv4 Advantage: Lots of information available, theoretically best IPv6 decisions. Disadvantage: IPv6 might outperform IPv4 (not really a problem in most cases) Bigger disadvantage: Some IPv4 destinations might get blackholed from time to time. Third choice: Default both protocols Advantage: At least you're still dual-stacked. Disadvantage: All the disadvantages applied to IPv4 above now apply to IPv6, too. Worst choice: Don't implement IPv6 Advantage: Absolutely none. Disadvantage: You can reach progressively less and less of the internet over time. However, the real answer is more complex than that. Sometimes the route that looks the best in BGP might not actually be the best and so in some cases with full tables you might send to the provider with the less effective path even though default would have had you going via the more effective path. These circumstances are rare, however, but, BGP has lots of knobs and depending on how well you and your upstreams set those knobs, your experience can be radically better or worse as a result. If your trip to the A destination via default takes longer than your trip to the destination via specifics, I'm not seeing a problem. Clients that have IPv6 capability will get a better user experience and clients that don't have IPv6 will get the same experience they got with default-based IPv4 prior to you implementing IPv6. Owen
ATT / prodigy.net mail admin
Hello, Can an ATT mail admin contact me off-list please? I have attempted to get a resolution for an issue through the normal channels and have not gotten anywhere. Sincerely, Bobby Glover Director of Information Services SVI Incorporated
Re: not excactly on-topic Server Cabinet question
On Wed, Feb 01, 2012 at 11:05:09PM -0600, Erik Amundson wrote: I apologize for this being off-topic in the NANOG list, but I'm hoping some of you have experience with the particulars of what I'm looking for... I am looking for a server cabinet which has an electric latching mechanism on it. I want to use my existing security system and proximity card reader, but have a cabinet door that would open when the card reader is read. Does anyone sell anything like this? Chatsworth has a solution.. http://www.chatsworth.com/Products/Environmental-Monitoring-and-Security/Electronic-Locking-Systems/
Re: bufferbloat videos are up.
On Fri, 3 Feb 2012, Jim Gettys wrote: 2. The longer version of the video Good visualisation. Just a little nitpicking, 802.11 is 54 megabit, not megahertz. It should also be pointed out that 802.11 is half duplex, which might affect things. Also, you might want to point out in your material that large buffers are there to handle bursts on TCP sessions over high RTT. Your suggestion to improve interactive performance hurts high speed TCP high RTT sessions. This is probably what most people want to do, but it would be good to point it out. Doing a promotion for ECN support in equipment would also be good, because introduing WRED with high drop probability a low buffer fill will really hurt performance for TCP transfers. ECN will help to avoid restransmissions, which just wastes bw. Where does your 100ms buffer size recommendation come from? The classical one is 2xRTT, with a lot of platforms developed around 2000 sized at 600ms of buffering (because 300 ms RTT seems like a decent value to choose for max RTT I guess). At megabit speeds I'd say to achieve your goal having 100ms FIFO buffering is too high anyway, so to handle your problem you need fairqueue to look at flows and put persistent buffer filling TCP sessions in the background. This would also mean TCP would be able to use full bw without hurting interactivity. Also, for some operating systems (Linux is the one I know about), there is a tendency to have high buffers not only in the IP stack, but also high FIFO buffers towards the hardware, in the device driver. I engaged the linux-usb mailing list about this, and I did see some talk that indicated that people understood the problem. So basically I agree with your problem statement, however I think it would be benficial if your proposed solution was a bit more specific, or at least pointed more in that direction. To propose a solution that sounds more like limit buffers to 100ms or less and everything will be fine would indeed remove some of the problem, but it would hurt performance for some applications. The problem you're describing has been know for 25 years, unfortunately not by the right people in the business, especially the ones making high volume low cost home equipment. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: bufferbloat videos are up.
On Feb 3, 2012, at 10:09 PM, Mikael Abrahamsson wrote: So basically I agree with your problem statement, however I think it would be benficial if your proposed solution was a bit more specific, or at least pointed more in that direction. To propose a solution that sounds more like limit buffers to 100ms or less and everything will be fine would indeed remove some of the problem, but it would hurt performance for some applications. The key to the solution is better Adaptive Queue Management, or AQM. As long as we have to decide on fixed queue sizes for all traffic, we're forced to cater to the most common traffic type. It would be nice to put queues of different RTT into different queues. Today that is basically impossible. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: Question about prefix list
Ann, the commas not withstanding, the le/ge operands as applicable to prefix-lists simply mean less-than or equal-to or greater-than or equal-to wrt netmasks in CIDR speak. In you prefix-list below, the le operand means - allow following ranges: /22,/23,/24 deny all else for the /21 it means allow /21 thru /24 Anything without an operand means an exact-match(permit/deny) Homework for you: What do the following do: 1) ip prefix-list foo deny 0.0.0.0/0 le32 2) ip prefix-list foo permit 0.0.0/0 le 32 Understand the above and you will understand how operands work in prefix-lists. ./Randy --- On Wed, 2/1/12, Ann Kwok annkwo...@gmail.com wrote: From: Ann Kwok annkwo...@gmail.com Subject: Question about prefix list To: nanog@nanog.org Date: Wednesday, February 1, 2012, 6:32 AM Hi I read this prefix list. Can I know why there is le 24 after network block in /22 and /21 Why don't have le 24 after /24? I also saw another prefix list before. They use le 32 instead of le 24 What are their different? ip prefix-list prefix-filter-as100 seq 10 permit 202,168.136.0/22 le 24 ip prefix-list prefix-filter-as100 seq 20 permit 202,22.92.0/22 le 24 ip prefix-list prefix-filter-as100 seq 30 permit 202,21.148.0/22 le 24 ip prefix-list prefix-filter-as100 seq 40 permit 203,178.88.0/21 le 24 ip prefix-list prefix-filter-as100 seq 50 permit 178.88.74.0/24 Thank you so much Here is how I look at prefix lists Lets say I have the following: ip prefix-list EXAMPLE permit 202.21.148.0/22 le 24 What this essentially means is match any prefixes that match the first 22 bits of 202.21.148.0 with a prefix length less than or equal to /24. The third octet (148) is 10010100 in binary, the /22 would be at 100101|00. So we would match anything that has the same bits set before the divider or the /22 mark. Matching prefixes would be: 202.21.148.0/22 202.21.148.0/23 202.21.150.0/23 202.21.148.0/24 202.21.149.0/24 202.21.150.0/24 202.21.151.0/24 Hope that makes sense. -- Matt Reath CCIE #27316 (SP) m...@mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath
Re: Please help our simple bgp
Hello Our router is running simple bgp. one BGP router, two upstreams (each 100M from ISP A and ISP B) We are getting full feeds tables from them We discover the routes is going to ISP A only even the bandwidth 100M is full Can we set the weight to change to ISP B to use ISP B as preference routes? Can the following configuration work? What suggest to this weight no. too? neighbor 1.2.3.4 description ISP B neighbor 1.2.3.4 remote-as 111 neighbor 1.2.3.4 weight 2000 If this works, how is ISP B upstream connection is down? Can it still be failover to ISP A automatically? If it won't work, Do you have any suggestion? Thank you for your help Ann, I've done this for a few customers that have requested it. Some engineers complain that advertising /24 routes dilutes the Internet routing tables, which is true in some regards. However, this does work in many situations to balance things out. Check out my blog post that walks through this procedure: http://mattreath.com/2012/01/29/bgp-load-balancing/ -Matt -- Matt Reath CCIE #27316 (SP) m...@mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath
