Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
On Fri, Mar 11, 2011 at 8:14 PM, Jeff Wheeler j...@inconcepts.biz wrote: It's the same thing that happens if you toss a /8 on an IPv4 LAN and start banging away at the ARP table, while expecting all of your legitimate hosts within that /8 to continue working correctly. We all know that's crazy, right? This is a valid concern. However... How is it suddenly less crazy to put an even larger subnet on an IPv6 LAN without gaining any direct benefits from doing so? [...] This is not a valid statement. I understand that you don't value the benefits we find with /64 or less, but we find value there, and it's really important to us, and they're things which were explicitly hoped for and planned for with IPv6 transition. The problem you pointed out, with a single host overrunning switch tables, can be outsmarted rather than brute forced by mandating small enough subnets that it doesn't exist. If we presume that the originating host doesn't fake its' layer 2 MAC as it's faking its layer 3 address, it's pretty trivial; you build in a software option that puts a maximum number of IPs per MAC. You balance virtualization cluster size limits with preemptive defense against this type of DOS when you do that, but balance points around 1E2 to 1E3 seem to me to be able to handle that just fine. You build in an override for switches / L2 gateways, or by port, or whatever other tuning mechanisms make sense (default to 10, override for your VMware cluster box and your switches...). If the originating host does try to fake its layer 2 MAC, you can detect new floods of new MACs via existing mechanisms. Plenty of port MAC map / allowed MAC mechanisms already exist for basic LAN security purposes. You just dump the fake MACs on the floor. The world is not perfect, and I'm sure there are still new vulnerabilities out there. But we can smart this one. If we can't smart this one, I'll be extremely surprised and disappointed. -- -george william herbert george.herb...@gmail.com
Re: [afnog] Suspicious request for IP address space
On Tue, Mar 08, 2011 at 06:23:26PM +0200, Shepherd Magumo wrote: Odds are, they're looking for a willing host for a snowshoe spamming operation. If I wanted space for something like that, Afrinic region providers would not be my first choice...particularly for the hosting. AFAIK, there are numerous LIRs in the RIPE region, particularly Romania who are more than happy to lease large blocks of IPv4 to anyone for any purpose. I guessed as much, it can only be a spamming operation. I will play along, offer them a lease and charge them over 9000 a day. Tell them they can have the block, but they need to send you an up-front reservation fee (by Western Union) to cover local administrative costs.
Re: estimation of number of DFZ IPv4 routes at peak in the future
On Sat, Mar 12, 2011 at 2:17 AM, Joel Jaeggli joe...@bogus.com wrote: I'm super-tired of the but tcams are an expensive non-commodity part not subject to economies of scale. this has been repeated ad nauseam since the raws workshop if not before. You don't have to build a lookup engine around a tcam and in fact you can use less power doing so even though you need more silicon to achieve increased parallelism. Hi Joel, You're either building a bunch of big TCAMs or a radix trie engine with sufficient parallelism to get the same aggregate lookup rate. If there's a materially different 3rd way to build a FIB, one that works at least as well, feel free to educate me. And while RIB churn doesn't grow in lockstep with table size, it does grow. Either way when you boost from 1M to 10M you're talking about engineering challenges with heat dissipation and operating challenges with power consumption, not to mention more transistors. I'll be convinced it can be done for less than 2x cost when someone actually does it for less than 2x cost. Whether it's 2x cost or 1.2x cost, the point remains the same: we could have routers today that handle the terminal size of the IPv4 table without breaking the bank. Your favorite router manufacturer has made vague assertions about how they would build one given sufficient customer demand. So make a demand. 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: Switching Email
On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kell jeff-k...@utc.edu wrote: On 3/11/2011 8:24 PM, Scott Weeks wrote: --- b...@herrin.us wrote: From: William Herrin b...@herrin.us No, it isn't. Contrary to mailing list best practices, NANOG unsubscribe information is stubbornly stashed in the email headers -- That's a feature. Not a bug. :-) Actually, it's RFC 2369 :) Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. On the other hand, the very first guideline at http://www.mail-abuse.com/an_listmgntgdlines.html is: Mailing list administrators must provide [...] clear and effective instructions for unsubscribing from a mailing list. Hidden in the headers is rather less than clear or effective. Even that lightweight, the CAN-SPAM act, calls for each message to contain clear and conspicuous notice of the opportunity [...] to decline to receive further messages. -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
need help about switch montior
Hi ls there any program/way to monitor the switch port/switch status when it reaches to certain bandwidth? Thank you so much
Re: estimation of number of DFZ IPv4 routes at peak in the future
On Sat, 2011-03-12 at 08:00 -0500, William Herrin wrote: You're either building a bunch of big TCAMs or a radix trie engine with sufficient parallelism to get the same aggregate lookup rate. If there's a materially different 3rd way to build a FIB, one that works at least as well, feel free to educate me. And while RIB churn doesn't grow in lockstep with table size, it does grow. Radix trie traversal can be pipelined, with every step in the search being done in separate memory bank. The upper levels of tries are small, and the lower levels contain a lot of gunk which is not used often - so they can be cached on-chip. FIB lookup is much easier than executing instructions like CPUs do precisely because packets are not dependent on each other, so you don't need to stall pipeline (like CPUs do on jumps, I'll skip the discussion of things like branch prediction and speculative execution). This didn't stop folks at Intel producing cheap silicon which executes instructions at astonishing speeds. Where TCAMs really shine is packet classification - but you don't generally need huge TCAM to hold ACLs in. Your favorite router manufacturer has made vague assertions about how they would build one given sufficient customer demand. So make a demand. OFRV has a track record of producing grossly over-engineered devices, hardware-wise. I've heard a very senior hardware guy who came from OFRV claiming that they do that deliberately to increase barriers to entry for competition, though this doesn't make sense to me. --vadim
[NANOG-announce] NANOG 52 Registration is open!
Registration for NANOG 52 is open. Something new this time around: There is a $25 discount for NewNOG members. Please register soon and see you in Denver. Dave (for the NANOG PC) ___ NANOG-announce mailing list nanog-annou...@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: need help about switch montior
I use this Nagios plugin for up/down status alerts, it has some support for interface bandwidth (and errors/discards) monitoring. It's just a perl script so you could easily modify it to suit your needs. http://nagios.manubulon.com/snmp_int.html -wil On Mar 12, 2011, at 5:51 AM, Deric Kwok wrote: Hi ls there any program/way to monitor the switch port/switch status when it reaches to certain bandwidth? Thank you so much
Re: unsubscribing, was Switching Email
Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. Alpine, which has what must be the cruddiest GUI on the planet, does. Too bad people prefer glitz to function. R's, John
Re: unsubscribing, was Switching Email
--As of March 12, 2011 3:02:38 PM +, John Levine is alleged to have said: Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. Alpine, which has what must be the cruddiest GUI on the planet, does. Too bad people prefer glitz to function. --As for the rest, it is mine. Squirrelmail and Kmail both do as well, although in both cases it's an option that needs to be configured. (In Squirrelmail's case it's actually a plugin, I think.) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: Switching Email
William Herrin b...@herrin.us writes: Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. Gnus? Jens, Gnus user since 1999 -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: Switching Email
William Herrin b...@herrin.us writes: and you have to read the mail in Microsoft Lookout, interspersed with work-oriented messages from your boss and colleagues. With Outlook popping new-message-notifications up on the projector while you try to give a presentation during a meeting, each containing the sender and message subject... Well I try to avoid Outlook, but even I was able to create some basic filter rules during my last projekt (where I was forced to use it). Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
Re: need help about switch montior
We use Solarwinds Orion for this stuff. We have some alerts for some switch Ports configured. You can get a trial version at www.solarwinds.com 2011/3/12 Wil Schultz wschu...@bsdboy.com I use this Nagios plugin for up/down status alerts, it has some support for interface bandwidth (and errors/discards) monitoring. It's just a perl script so you could easily modify it to suit your needs. http://nagios.manubulon.com/snmp_int.html -wil On Mar 12, 2011, at 5:51 AM, Deric Kwok wrote: Hi ls there any program/way to monitor the switch port/switch status when it reaches to certain bandwidth? Thank you so much
Re: unsubscribing, was Switching Email
On 3/12/2011 10:02 AM, John Levine wrote: Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. Alpine, which has what must be the cruddiest GUI on the planet, does. Too bad people prefer glitz to function. And Glitzy MUAs and MTAs tend to be the least RFC compliant of all. Thunderbird (older versions) had a plugin (Display Mailing List Headers) that would do it, but the plugin is not compatible with the current version[s] of Thunderbird. Any MUA that has a toggle or view to display all headers may indirectly do it if they create clickable links for http: and mailto: directives, e.g., from this list: List-Id: North American Network Operators Group nanog.nanog.org List-Unsubscribe: https://mailman.nanog.org/mailman/listinfo/nanog, mailto:nanog-requ...@nanog.org?subject=unsubscribe List-Archive: http://mailman.nanog.org/pipermail/nanog List-Post: mailto:nanog@nanog.org List-Help: mailto:nanog-requ...@nanog.org?subject=help List-Subscribe: https://mailman.nanog.org/mailman/listinfo/nanog, mailto:nanog-requ...@nanog.org?subject=subscribe Jeff
Re: OSPFv3 Authentication
Janos, On Tue, 28 Sep 2010, Venkatesh Sriram wrote: While I have used MD5 with OSPFv2, I never used authentication with OSPFv3 since IPsec is (a) not available on all platforms (or/and requires a special license) and (b) requires too much of coordination with other folks to bring it up. I know operators who use authentication with ISIS for v6, but very little auth for OSPFv3.Obviously, you'll find an equal number that enthusiastically use auth with OSPFv3, so really there isnt any one right answer. Dear Sriram, Can you list/name the platforms does not support IPsec for OSPFv3 without special license? e.g. to avoid such a platform Best Regards, Janos Some platforms of Cisco for one. http://mellowd.co.uk/ccie/?p=1421 Sriram
Re: Cisco IOS MPLS VPN Bug
On 2011-03-12, at 2:31 AM, Joe Renwick wrote: These routers are configured as BGP route-reflectors. ... Niether soft nor hard clears on the BGP neighbors worked, only the config removal. Once re-applied life was good. ... The bug itself was with the BGP updates sent by the RR. During the outage these updates did not include the Route Target Extended Community required by the route-reflector clients which identifies which VRF the route belongs too. ... Notice the mysterious disappearance of the RT community. ... Looking to see if anyone has seen this issue particularly with this version of code. TAC is trying to tell me that this was a bug in a previous version but is fixed in the code I am running. Interesting. I recently closed off a TAC case on a similar issue, but not an identical issue. In my case, it was 12.2(52)EY on an ME3600 and in my particular topology, an ME3600 wasn't announcing a plain ol' BGP community to one of it's two RRs. The extended communities were fine tho. Also, the announcements were being stuffed into two different update groups; the ME that was sending the 'good' announcement was announcing updates to update-group 1 and 2 and the ME that was announcing the 'bad' announcement was announcing updates to update-group 1 only. We didn't spend as much time as you clearly have troubleshooting the issue because we caught it before it was customer affecting. That said, at the time, I noticed the same thing; hard clearing the sessions didn't fix it. I didn't try to unconfigure the neighbour though; in my case, I was running EY on this switch and because the ME3600s are so new and EY1 was available and I knew that I'd have to reboot anyway to clear the issue, I decided to upgrade to EY1 and that seemed to clear up the problem. I haven't seen this resurface since. EY1 was available as soon as we started receiving our ME3600s, so as a policy we upgraded every one before it went into the field, except I had missed this one in particular. There were no open bugs pointing to my issue that the TAC engineer could find, but if you could pass me the case number, I'd like to give it to my engineer so he can see if your issue is somehow related to mine, just manifested in a slightly different way.
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Fri, Feb 11, 2011 at 8:29 PM, Tom Limoncelli t...@whatexit.org wrote: On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong o...@delong.com wrote: I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. I'm writing an article where I want to say that but I can't find an article I can reference to back it up. I don't want to accidentally encourage an urban legend or rumor. (For example, I can't find verification to the rumor that ARIN rejected a request from LTE providers for IPv4 space and instead told them to go straight to IPv6. I do others in this thread saying that native IPv4 on LTE is common, so unless someone can give me evidence, I'll have to update that part of the article. OMG i'd love to make that point; anyone have proof?). I could, instead, write, most carriers will probably roll IPv6 out as part of their 4G upgrade but that sounds wishy-washy. Thanks in advance, Tom -- http://EverythingSysadmin.com -- my blog (new posts Mon and Wed) http://www.TomOnTime.com -- my advice (more videos coming soon) The article I mentioned I was writing has been published and is now available on-line here: http://queue.acm.org/detail.cfm?id=1959015 Thanks for all the assistance both on this mailing list and the private email I received! Tom Limoncelli http://www.EverythingSysadmin.com -- Sign up for my new class Advanced Time Mgmt: Team Efficiency at PICC! April 29-30, New Jersey, LOPSA PICC: www.picconf.org Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11 Dec 4-5, Boston, ACM CHIMIT, chimit.acm.org Call for papers and talk proposals open at LISA and CHIMIT!
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Now that is what Baldrick* would call a cunning plan! And interesting examples. Christian *Apologies to Tony Robinson and Blackadder On 12 Mar 2011, at 18:52, Tom Limoncelli wrote: On Fri, Feb 11, 2011 at 8:29 PM, Tom Limoncelli t...@whatexit.org wrote: On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong o...@delong.com wrote: I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. I'm writing an article where I want to say that but I can't find an article I can reference to back it up. I don't want to accidentally encourage an urban legend or rumor. (For example, I can't find verification to the rumor that ARIN rejected a request from LTE providers for IPv4 space and instead told them to go straight to IPv6. I do others in this thread saying that native IPv4 on LTE is common, so unless someone can give me evidence, I'll have to update that part of the article. OMG i'd love to make that point; anyone have proof?). I could, instead, write, most carriers will probably roll IPv6 out as part of their 4G upgrade but that sounds wishy-washy. Thanks in advance, Tom -- http://EverythingSysadmin.com -- my blog (new posts Mon and Wed) http://www.TomOnTime.com -- my advice (more videos coming soon) The article I mentioned I was writing has been published and is now available on-line here: http://queue.acm.org/detail.cfm?id=1959015 Thanks for all the assistance both on this mailing list and the private email I received! Tom Limoncelli http://www.EverythingSysadmin.com -- Sign up for my new class Advanced Time Mgmt: Team Efficiency at PICC! April 29-30, New Jersey, LOPSA PICC: www.picconf.org Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11 Dec 4-5, Boston, ACM CHIMIT, chimit.acm.org Call for papers and talk proposals open at LISA and CHIMIT!
Re: Switching Email
On Sat, 12 Mar 2011 08:16:19 EST, William Herrin said: Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. EXMH had that support long ago: cvs repository 4/9/1999 Support for RFC2369. If a message contains RFC2369 compliant headers, a List... menu will appear with List related items on it. [ Note that this makes visible a mailto url related bug which you'll find described in exmh.BUGS ] -cwg pgpN3mByzBKq7.pgp Description: PGP signature
Re: Switching Email
On Sat, Mar 12, 2011 at 3:10 PM, valdis.kletni...@vt.edu wrote: EXMH had that support long ago: cvs repository 4/9/1999 Support for RFC2369. If a message contains RFC2369 compliant headers, a List... menu will appear with List related items on it. [ Note that this makes visible a mailto url related bug which you'll find described in exmh.BUGS ] -cwg Previous big fan of NMH reporting in - was my favorite email client for many many years :)
Re: Switching Email
On 12/03/11 5:16 AM, William Herrin wrote: On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kelljeff-k...@utc.edu wrote: On 3/11/2011 8:24 PM, Scott Weeks wrote: --- b...@herrin.us wrote: From: William Herrinb...@herrin.us No, it isn't. Contrary to mailing list best practices, NANOG unsubscribe information is stubbornly stashed in the email headers -- That's a feature. Not a bug. :-) Actually, it's RFC 2369 :) Anyone have a list of MUAs I don't have a list, but if you are viewing the email using the gmail web interface, and select the show details interface, you will see: fromScott Weeks sur...@mauigateway.com reply-tosur...@mauigateway.com tonanog@nanog.org dateFri, Mar 11, 2011 at 5:24 PM subjectRe: Switching Email mailing listnanog.nanog.org Filter messages from this mailing list mailed-bynanog.org unsubscribeUnsubscribe from this mailing-list Where Filter messages from this mailing list is a link, and Unsubscribe from this mailing-list is a link. Unfortunately, there's no confirmation or undo when you try to unsubscribe (as I just did, to test it). Oops! jc
Re: estimation of number of DFZ IPv4 routes at peak in the future
On 3/12/11 5:00 AM, William Herrin wrote: On Sat, Mar 12, 2011 at 2:17 AM, Joel Jaeggli joe...@bogus.com wrote: I'm super-tired of the but tcams are an expensive non-commodity part not subject to economies of scale. this has been repeated ad nauseam since the raws workshop if not before. You don't have to build a lookup engine around a tcam and in fact you can use less power doing so even though you need more silicon to achieve increased parallelism. Hi Joel, You're either building a bunch of big TCAMs or a radix trie engine with sufficient parallelism to get the same aggregate lookup rate. The trie is working acceptably in 120Gb/s linecards today. If there's a materially different 3rd way to build a FIB, one that works at least as well, feel free to educate me. Don't need one, that's the point, heroic measures are not in fact required. On the trie side it's the key length O(m) that ditactates the lookup time in the trie and the worst case is therefore bounded by the straight-forward proposition (how to I forward to this /128). having generally shorter routes would got long way towards extending the route capacity of the device, but the table sizes kills you on installing and updating the fib not on the search part. And while RIB churn doesn't grow in lockstep with table size, it does grow. It does, it just has to not grow faster than our ability to manage it. so long as the remains the case managing the RIB remains in the domain of straight forward capacity management. compressing rib churn out of fib updates and tweaks to bgp state-machines generally is I think an area that has a lot of room for innovation, but that doesn't have to involve the forwarding plane. Either way when you boost from 1M to 10M you're talking about engineering challenges with heat dissipation and operating challenges with power consumption, not to mention more transistors. We don't need 10 million routes today, we need 2 million in the class of device that currently has 512K (36Mbit CAM) (and has been in production for some time) in 3-5years... That today can/is being done with 64MB RLDRAM. In same time-frame the networks that currently need 2 million route FIBS will need 4-5M. To harp on rldram since I'm somewhat familiar with it, clearly we need faster parts with lower power consumption and it's timely that ddr3 derived parts should begin sampling at some point. I'll be convinced it can be done for less than 2x cost when someone actually does it for less than 2x cost. part of the exercise is neither building nor buying the capacity before you need it. the later the features needed crystalize into silicon the more likely they are to be usable. Whether it's 2x cost or 1.2x cost, the point remains the same: we could have routers today that handle the terminal size of the IPv4 table without breaking the bank. Your favorite router manufacturer has made vague assertions about how they would build one given sufficient customer demand. So make a demand. previous $employer crossed the 800K prefix count in FIBS on couple devices a while ago. I generally don't have to many cases where vendors roll their eyes and laugh hysterically when I talk about what we project our FIB requirements as, that's reserved for other features. Regards, Bill Herrin
Re: Switching Email
In message aanlktinvbcodxicqhmclop7qg3mh4388mrp1uevvk...@mail.gmail.com, Will iam Herrin writes: On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kell jeff-k...@utc.edu wrote: On 3/11/2011 8:24 PM, Scott Weeks wrote: --- b...@herrin.us wrote: From: William Herrin b...@herrin.us No, it isn't. Contrary to mailing list best practices, NANOG unsubscribe information is stubbornly stashed in the email headers -- That's a feature. =A0Not a bug. =A0:-) Actually, it's RFC 2369 =A0:) Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. On the other hand, the very first guideline at http://www.mail-abuse.com/an_listmgntgdlines.html is: Mailing list administrators must provide [...] clear and effective instructions for unsubscribing from a mailing list. Hidden in the headers is rather less than clear or effective. Even that lightweight, the CAN-SPAM act, calls for each message to contain clear and conspicuous notice of the opportunity [...] to decline to receive further messages. Headers are the ONLY way to do this so it works in all languages for all the planet. Click here to unsubscribe is a joke when it is written in a language you don't read. As for the CAN-SPAM act, it's also a joke. It doesn't require a pre-existing relationship where there is a chance the recipient can read the message. -Bill --=20 William D. Herrin her...@dirtside.com=A0 b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Switching Email
--- b...@herrin.us wrote: On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kell jeff-k...@utc.edu wrote: On 3/11/2011 8:24 PM, Scott Weeks wrote: --- b...@herrin.us wrote: From: William Herrin b...@herrin.us No, it isn't. Contrary to mailing list best practices, NANOG unsubscribe information is stubbornly stashed in the email headers -- That's a feature. Not a bug. :-) Actually, it's RFC 2369 :) On the other hand, the very first guideline at http://www.mail-abuse.com/an_listmgntgdlines.html is: Mailing list administrators must provide [...] clear and effective instructions for unsubscribing from a mailing list. Hidden in the headers is rather less than clear or effective. On the many other mailing lists I'm on folks don't even read it when it's at the bottom of the email. Having it at the bottom of every email is irritating and does not solve the problem of folks sending in the emails to the list for unsubscription. scott
Re: Switching Email
--- b...@herrin.us wrote: From: William Herrin b...@herrin.us colleagues. With Outlook popping new-message-notifications up on the projector while you try to give a presentation during a meeting, each containing the sender and message subject... -- I am happy I have never used Outlook for that reason and many others. Try Pine. It won't do that to you. ;-) scott
Re: estimation of number of DFZ IPv4 routes at peak in the future
On Sat, Mar 12, 2011 at 4:43 PM, Joel Jaeggli joe...@bogus.com wrote: On 3/12/11 5:00 AM, William Herrin wrote: I'll be convinced it can be done for less than 2x cost when someone actually does it for less than 2x cost. part of the exercise is neither building nor buying the capacity before you need it. the later the features needed crystalize into silicon the more likely they are to be usable. That must be my mistake then, because I thought the exercise was building it in a way that it stays built for the maximum practical number of years. When it has to be touched again (or tweaked if it gets near its limit) that's manpower. Skilled manpower plus the secondary costs from the inevitable delay deploying it is usually the most expensive thing. 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: estimation of number of DFZ IPv4 routes at peak in the future
On Sat, Mar 12, 2011 at 7:27 PM, William Herrin b...@herrin.us wrote: That must be my mistake then, because I thought the exercise was building it in a way that it stays built for the maximum practical number of years. When it has to be touched again (or tweaked if it So when you upgrade a device, you always buy the suitable device which has the highest capabilities? You put in a top-of-rack switch with 10GbE for servers with no 10GbE ports and no plans of needing 10GbE connectivity to the next round of servers? You buy a modular router for branch offices that have only a few workstations and no predictable need for upgraded connectivity? This is a good way to waste money, and a bad way to ensure that you will have the *features* you may want in the future. New features will not be back-ported to your box of choice, but you will have sunk unnecessary budget resources into that box, making it harder to justify upgrades. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Internet Edge Router replacement - IPv6 route tablesizeconsiderations
Leo Bicknell wrote: In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong wrote: On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: Well, I at least think an option should be a /80, using the 48 bits of MAC directly. This generates exactly the same collision potential as today we have with a /64 and an EUI-64 constructed from an EUI-48 ethernet address. The router is already sending RA's for SLAAC to work, sending along one of a well-known set of masks would be a relatively minor modification. How would you use that on a Firewire netowrk or FDDI or any of the other media that uses 64-bit MAC addresses? It wouldn't. Yes it would. It works for any size subnet that can fit both the RA node and the auto configuring one, from /0 - /127. And it is even backwards compatible. 1) Listen to RA, discover subnet size and whether to perform autoconfiguration, for backwards compatibility, assume /64 size if not included in RA. 2a) Generate address using phy bits, right aligned up to the lesser of subnet/phy size. Use 1fff as leftmost host bits if the subnet size is 64 and the phy is 48. 2b) Use any other algorithm that may be more desirable, such as one that helps preserves privacy and that contains /dev/random as one of its inputs. The randomness can be optionally initially confined to the subnet bits that exceed the phy bits, if any. 3) Perform DAD 4a) Collision, goto 2b, remembering the previous values and avoiding them. Retry 2a and forget all avoided values when they total up to (subnet size ** 2) - 3. 4b) No collision, happy surfing. 5) RA values change/expire, goto 1 Why is the ability to blindly embed the phy L2 into an auto-configured L3 address considered a prerequisite, let alone a universally good idea? I'm not proposing a solution for everything, just a useful case for some things. I don't want to change say, RIR policy that you can allocate a /64, just allow operators to use /80's, or /96's in a more useful way if they find that useful. Basically I think the IETF and IPv6 propoents went a bit too far down the one size fits all route. It has nothing to do with how many numbers may or may not be used, but everything to do with the fact that you often have to fit inside what's been given to you. If you're stuck with a monopoly provider who gives you a /64 to your cable modem there should be easy options to split it up and get some subnets. Leaving scarcity behind should not mean kicking flexibility to the curb as well. Just because SLAAC may work best with /64 should not mean that it must only work with a /64. And failing with an unconfigurable stack when DAD detects a collision means that SLAAC is not a guaranteed safe general use option, contrasted with DHCP and the possibility of conflict detection and reaction. Using bad design choices as justification for requiring additional ones simply means that SLAAC is broken as designed. It also means attempts to fix it are going to run up against entrenched opposition. Which is readily apparent. DHCPv6 needs to be fixed with address and router options and then all DHCPv6 servers/helpers should be configurable to disable all RA on a segment by way of beaconing their own poison-reverse RA. Joe
