Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
Asr1002-f may have problem as it limited to 512k iirc On 08 мая 2014 г., at 2:45, Shawn L sha...@up.net wrote: Do the ASR1k routers have this issue as well? I searched around but couldn't find any information. -- Forwarded message -- From: Irwin, Kevin kevin.ir...@cinbell.com Date: Wed, May 7, 2014 at 10:39 AM Subject: Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. To: nanog@nanog.org nanog@nanog.org I¹m really surprised that most people have not hit this limit already, especially on the 9K¹s, as it seems Cisco has some fuzzy math when it comes to the 512K limit. Also make sure you have spare cards when you reload after changing the scaling, those old cards don¹t always like to come back. On 5/6/14, 7:01 PM, Larry Sheldon larryshel...@cox.net wrote: On 5/6/2014 10:39 AM, Drew Weaver wrote: Just something to think about before it becomes a story the community talks about for the next decade. Like we have for the last two? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document.
Re: US patent 5473599
* Blake Dunlap iki...@gmail.com [2014-05-08 03:19]: Except for that whole mac address thing, that crashes networks... this lie doesn't get any more true by repeating them over and over. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
* Robert Drake rdr...@direcpath.com [2014-05-08 06:02]: On 5/7/2014 9:47 PM, Rob Seastrom wrote: Now, the bar for an informational RFC is pretty low. Especially for people who have written them before. Those people seem to think one is needed in this case so they might want to get started writing it. Then patches to the man pages covering the past issues can be added to document things, and a patch can be issued with the new OUI, ethertype, or port number, whichever the RFC decides to go for. spot on. but apparently nanog is just about whining for the sake of whining. Must be a pretty horrible existence (I pity the fool?) to live on donated resources but lack the creativity to figure out a way to run a special fund raiser for an amount worthy of a Scout troop bake sale. Makes you wonder what the OpenBSD project could accomplish if they had smart people who could get along with others to the point of shaking them down for tax-deductible donations, doesn't it? The money could also be donated by parties interested in solutions. again, spot on. Open source is about people finding a problem and fixing it for their own benefit then giving the fix away to the community for everyone's benefit. I know in the past the OpenBSD community has been harsh with outsiders who submit patches. I honestly expect the same response in this case, especially because of the underlying drama associated with it, but without trying first it just seems like the network community is whining without being helpful at all. I think we are pretty damn open for patches from outside. And I have said it before, if somebody does the work and gives us a mac addr range to use without unreasonable terms and conditions attached, we'll almost certainly use it. Chances increased if it is a full patch with code for the transition period. Sorry, doesn't fit nanog, since that would require work instead of just whining and bitching. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
* Owen DeLong o...@delong.com [2014-05-08 07:16]: If they take their ball and go home, that's fine. The problem is that they seem to occasionally have their ball brought (by systems administrators) to networks where the network engineers are already running VRRP on routers (for example) and because: 1. The systems administrators don't necessarily have in-depth knowledge of what the network is doing. nothing technology can solve 2. The network administrators don't necessarily get told about every detail of the Systems administrators intentions. nothing technology can solve 3. There's no knowledge among the two groups that either is using the other protocol (CARP vs. VRRP) nothing technology can solve 4. There's even less knowledge that the two are going to fight with each other. that is a lie, they coexist just fine. even with conflicting mac addrs you just get log spam. OTOH, if the BSD folk had (or in the future did) fix CARP so that instead of trying to steal VRRP MAC addresses in a conflicting manner, it would either use a non-conflicting MAC prefix (how about one with the locally assigned bit set, such as the VRRP Mac | 0x02000::) and make a legitimate attempt at getting CARP into an RFC with a legitimately assigned protocol number, everyone could get along without issue. awaiting your diff. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
* Owen DeLong o...@delong.com [2014-05-08 04:36]: I don’t believe for one second that the IESG refused to deal with ‘em. you're free to believe whatever you want and ignore facts. I do believe the IESG did not hand them everything they wanted on a silver platter in contravention of the established consensus process and that they failed to gain the consensus they wanted as easily as they hoped. lie. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
* Gary Buhrmaster gary.buhrmas...@gmail.com [2014-05-08 00:43]: But (presuming no adjustments) the patent is now expired, and the OpenBSD team could now release CARPv2 (or whatever they decide to call it) which would implement the standard, should they wish to work and play well with the standards bodies and community. why would we give up authentication and adress family independence? the vrrp dilemma forced us to invent carp instead, but now carp is far superior. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
If OBSD can't afford MAC addresses but does not object to them in principle, I can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee. -- ++ytti
Re: US patent 5473599
* Eygene Ryabinkin r...@grid.kiae.ru [2014-05-08 11:12]: Henning, Thu, May 08, 2014 at 09:35:00AM +0200, Henning Brauer wrote: * Blake Dunlap iki...@gmail.com [2014-05-08 03:19]: Except for that whole mac address thing, that crashes networks... this lie doesn't get any more true by repeating them over and over. So, you insist that VRRP and CARP instances with the same VRID/VHID in the same L2 segment will coexist peacefully? I had seen problems with such setup, so if you can enlighten me how to overcome them (rather than saying you must choose different VRID/VHID) -- it will be very good. you shouldn't see issues but log spam. I haven't seen anotehr issue and I haven't seen a single report claiming otherwise over the last 10 years either, minus the mentioned cisco 3600 don't bother checking the version number field before parsing on screwup. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
* Saku Ytti s...@ytti.fi [2014-05-08 12:14]: If OBSD can't afford MAC addresses but does not object to them in principle, I can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee. congratulations, that is far ahead of just whining. when/if we change the mac addrs, the new range should be utterly correct and not just a little bit better. not sure this would qualify. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
On 08/05/2014 11:25, Henning Brauer wrote: you shouldn't see issues but log spam. maybe you misunderstand the problem. If you have vrrp and carp on the same vlan, using the same vrrp group ID as VHID, then each virtual IP will arp for the same mac address on that vlan. This messes up the switch's forwarding table for that particular vlan because it sees multiple entries from different ports for the same mac address. Switches will not do unicast replication in this situation, but instead will forward all traffic for a particular destination mac address to the port which announced the mac address most recently. In other words, this is much more serious than log spam: it is guaranteed to cause network downtime, because you cannot have two hosts on the same L2 domain using the same mac address, but doing different things. Nick
Re: US patent 5473599
* Nick Hilliard n...@foobar.org [2014-05-08 13:03]: On 08/05/2014 11:25, Henning Brauer wrote: you shouldn't see issues but log spam. maybe you misunderstand the problem. If you have vrrp and carp on the same vlan, using the same vrrp group ID as VHID, then each virtual IP will arp for the same mac address on that vlan. correct. This messes up the switch's forwarding table for that particular vlan because it sees multiple entries from different ports for the same mac address. correct. my switches seem to deal with that, wether they have special handling for that mac addr range or not i dunno. again, stress the fact that afair we have gotten zero reports about that issue for 10 years, it obviously means that either 1) a vast majority of switches deal with it just fine 2) people know that vhids shouldn't clash and avoid that -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
On Thu, May 08, 2014 at 12:31:23PM +0200, Henning Brauer wrote: * Saku Ytti s...@ytti.fi [2014-05-08 12:14]: If OBSD can't afford MAC addresses but does not object to them in principle, I can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee. when/if we change the mac addrs, the new range should be utterly correct and not just a little bit better. not sure this would qualify. I fail to see the issue with using these addresses, they are globally unique and correctly administrated at IEEE, Saku Ytti can do whatever he wants (like giving indefeasible rights of use to the OpenBSD Foundation). It won't come any cheaper than this (I am Dutch, I recognise a good deal when I see one!). If the team accepts I'll submit a patch to wireshark so decoded packets containing MACs from that block are properly identified as OpenBSD. Kind regards, Job
Re: US patent 5473599
On 08/05/2014 12:09, Henning Brauer wrote: my switches seem to deal with that, wether they have special handling for that mac addr range or not i dunno. I've seen this problem cause downtime on production networks. fyi, it will probably work fine on hubs, but not on switches. again, stress the fact that afair we have gotten zero reports about that issue for 10 years, it obviously means that either 1) a vast majority of switches deal with it just fine 2) people know that vhids shouldn't clash and avoid that https://www.google.com/search?q=vrrp+carp+incompatible Several of the results refer to openbsd mailing list postings. Nick
Re: US patent 5473599
And that's why C. should use a more appropriate example to defend his position. By this thread, I suspect, that whoever dealt with those different organization for OpenBSD CARP, lacked the skills to accomplish the task and got shut down for being an ass. PS: Being of the Church of FreeBSD, I freely acknowledge that I got no clue about the scope of the drama that CARP was involved with. But I was aware of Cisco/VRRP/HSRP patent and CARP and found CIsco to be a bit of a bully to actually enforce it for such a simple technology. That being said, I was never attracted to OpenBSD for some gut reason... I know why now =D - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 05/07/14 20:56, valdis.kletni...@vt.edu wrote: On Wed, 07 May 2014 17:10:32 -0700, Constantine A. Murenin said: Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY, Because it doesn't squat on the port. It politely asks Do you speak SPDY, or just https? and then listens to what the other end replies.
Re: US patent 5473599
On 8/05/2014, at 11:09 pm, Henning Brauer hb-na...@bsws.de wrote: * Nick Hilliard n...@foobar.org [2014-05-08 13:03]: On 08/05/2014 11:25, Henning Brauer wrote: you shouldn't see issues but log spam. maybe you misunderstand the problem. If you have vrrp and carp on the same vlan, using the same vrrp group ID as VHID, then each virtual IP will arp for the same mac address on that vlan. correct. This messes up the switch's forwarding table for that particular vlan because it sees multiple entries from different ports for the same mac address. correct. my switches seem to deal with that, wether they have special handling for that mac addr range or not i dunno. What make and model switches? I am sure someone here can easily verify their behaviour and if they have some baked in pixie dust to handle this. But a pure l2 switch should not be able to mask the issue given all it has to go on is MAC so you would either see excessive flooding of a unicast MAC, or black holing of VRRP or CARP. Neither of which are desirable and given that the flooding would lead to serious security issues worries me from such a security focused community as the OpenBSD community professes to be. again, stress the fact that afair we have gotten zero reports about that issue for 10 years, it obviously means that either 1) a vast majority of switches deal with it just fine 2) people know that vhids shouldn't clash and avoid that -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: US patent 5473599
On Thu, May 08, 2014 at 09:48:26AM +0200, Henning Brauer wrote: awaiting your diff. http://marc.info/?l=openbsd-techm=139955603603070w=2 Kind regards, Job
Re: bgp convergence problem
On Thu, May 8, 2014 at 1:51 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Wednesday, May 07, 2014 07:28:46 PM Peter Rubenstein wrote: Operationally speaking, AS1 should not be leaking routes from one upstream to the other. Bad route policy. ideally it'd be nice to be valley-free... so to speak. Also, AS3 should not accept routes from AS1 that don't belong to it. Customer router filtering would prevent this. always with the route filtering... routes want to be free man, free! How I wish this happened in real life. We are chasing route leaks several AS's down the path that are not even remotely connected to us on a weekly basis. But I guess that's what they pay us for :-(. if only there were some technology that could be used to thwart such things.
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
It depends, you can put in a table-map to stop the routes from being installed into the FIB/RIB on an ASR-1K with 2GB of RAM you can then have up to 2 million IPv4 routes. Alternatively, if you are not using your ASR-1k to forward traffic, I think you could also just turn off CEF and have the same result. On 5/8/14, 2:15 AM, Nikolay Shopik sho...@inblock.ru wrote: Asr1002-f may have problem as it limited to 512k iirc On 08 мая 2014 г., at 2:45, Shawn L sha...@up.net wrote: Do the ASR1k routers have this issue as well? I searched around but couldn't find any information. -- Forwarded message -- From: Irwin, Kevin kevin.ir...@cinbell.com Date: Wed, May 7, 2014 at 10:39 AM Subject: Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. To: nanog@nanog.org nanog@nanog.org I¹m really surprised that most people have not hit this limit already, especially on the 9K¹s, as it seems Cisco has some fuzzy math when it comes to the 512K limit. Also make sure you have spare cards when you reload after changing the scaling, those old cards don¹t always like to come back. On 5/6/14, 7:01 PM, Larry Sheldon larryshel...@cox.net wrote: On 5/6/2014 10:39 AM, Drew Weaver wrote: Just something to think about before it becomes a story the community talks about for the next decade. Like we have for the last two? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document.
Re: bgp convergence problem
On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow wrote: if only there were some technology that could be used to thwart such things. It's gotten to a point where a repeat offender has me wound up enough to prepend his AS into some of my paths. I wish there was a simpler way to turn them off. Mark. signature.asc Description: This is a digitally signed message part.
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On Thursday, May 08, 2014 04:45:09 PM Irwin, Kevin wrote: It depends, you can put in a table-map to stop the routes from being installed into the FIB/RIB on an ASR-1K with 2GB of RAM you can then have up to 2 million IPv4 routes. Helpful only if you don't want to forward traffic through the box, in which case running IOS XE on a VM on a server is a more lasting idea :-). Mark. signature.asc Description: This is a digitally signed message part.
NAT (PAT) log
Hello, as we are running out of ipv4 addresses we started to think of dual stack deployment in our network and that means we will soon need to have some NAT in place (NAT44).However I am curios to find how do you manage NAT logs? Considering the fact that we will need to use overload for pools I don't see any good solution how to track ip address leases. Any ideas?
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
I know most people have problems with 2 bgp feeds and 4GB RAM on ASR1002-F (as it max installable memory). So I doubt about 2M routes with 2GB RAM. On 08.05.2014 18:45, Irwin, Kevin wrote: on an ASR-1K with 2GB of RAM you can then have up to 2 million IPv4 routes
RE: NAT (PAT) log
In the past, when we had a Cisco 7200 doing NATing, we had a script someone wrote that would telnet into the router and do a sh ip nat trans. The file would be saved out and we could parse through it at a later time, we had the script run even 10 minutes or so I believe. If that is what you are looking for, I can try and dig up the script we had for this. -Mike -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Pavel Dimow Sent: Thursday, May 08, 2014 11:20 AM To: NANOG Subject: NAT (PAT) log Hello, as we are running out of ipv4 addresses we started to think of dual stack deployment in our network and that means we will soon need to have some NAT in place (NAT44).However I am curios to find how do you manage NAT logs? Considering the fact that we will need to use overload for pools I don't see any good solution how to track ip address leases. Any ideas?
RE: Residential CPE suggestions
We’ve had two of the ER3s in production. One of which has had no problems to date, the other one had several issues just staying online. It would randomly drop out from time to time (no ICMP, didn't pass traffic; basically a flashing brick). These were both single homed stub networks on older firmware so your results may vary. In my past experience the Ubiquiti release cycle is: Announce Product -- (1 year later) -- Reannounce Product /Start Shipping -- (4 months later) -- Claim it's still on the boat and will reach distributors soon -- (2 months later) -- Begin shipping from Distribution with defunct firmware -- (8 months later and a few firmware updates) -- Release a stable firmware version TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be ready for production networks or very patient customers. For what you’re looking for though no one else can match that price point. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jimmy Hess Sent: Tuesday, May 6, 2014 9:13 PM To: sur...@mauigateway.com Cc: NANOG list Subject: Re: Residential CPE suggestions On Tue, May 6, 2014 at 2:31 PM, Scott Weeks sur...@mauigateway.com wrote: I wouldn't worry. A fancy GUI without intelligent engineering and design leveraged is just more rope for everyone to hang themselves with, esp. when something in the GUI inevitably doesn't work quite like it's supposed to. Network vendor GUIs never work 100% like they are supposed to; there's always eventually some bug or another, or limitation requiring some workaround. And IPv6 is a game-changer. It looks like everyone here should start looking for a new career: Next-generation user experience allows anyone to quickly become a routing expert. ;-) scott -- -JH
Re: Residential CPE suggestions
On May 8, 2014, at 12:19 PM, Nolan Rollo nro...@kw-corp.com wrote: TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be ready for production networks or very patient customers. For what you’re looking for though no one else can match that price point. +1 If you have hardware in-hand and don't mind support via their 'free' forums. If you can reproduce any issues, they will promptly recreate it and fix it. You may end up waiting awhile for the software, but even $big_vendor has that issue. I'm using both the nanobridge/nanobeam hardware as well as edgerouter and unifi and they work quite well. - Jared
Re: Residential CPE suggestions
I would love to see the EdgeRouter Lite, or something similar with 2 SFP ports and 2 1000bT ports (Which would fit with the OP's question). Q-in-Q tunneling and basic routing required, but not much else for me. Bonus points points for something like that with redundant power supplies for $1k There really does not seem to be anything in that space that is viable and inexpensive. thanks, -Randy - Original Message - We’ve had two of the ER3s in production. One of which has had no problems to date, the other one had several issues just staying online. It would randomly drop out from time to time (no ICMP, didn't pass traffic; basically a flashing brick). These were both single homed stub networks on older firmware so your results may vary. In my past experience the Ubiquiti release cycle is: Announce Product -- (1 year later) -- Reannounce Product /Start Shipping -- (4 months later) -- Claim it's still on the boat and will reach distributors soon -- (2 months later) -- Begin shipping from Distribution with defunct firmware -- (8 months later and a few firmware updates) -- Release a stable firmware version TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be ready for production networks or very patient customers. For what you’re looking for though no one else can match that price point. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jimmy Hess Sent: Tuesday, May 6, 2014 9:13 PM To: sur...@mauigateway.com Cc: NANOG list Subject: Re: Residential CPE suggestions On Tue, May 6, 2014 at 2:31 PM, Scott Weeks sur...@mauigateway.com wrote: I wouldn't worry. A fancy GUI without intelligent engineering and design leveraged is just more rope for everyone to hang themselves with, esp. when something in the GUI inevitably doesn't work quite like it's supposed to. Network vendor GUIs never work 100% like they are supposed to; there's always eventually some bug or another, or limitation requiring some workaround. And IPv6 is a game-changer. It looks like everyone here should start looking for a new career: Next-generation user experience allows anyone to quickly become a routing expert. ;-) scott -- -JH
Re: bgp convergence problem
On Thu, May 8, 2014 at 10:51 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow wrote: if only there were some technology that could be used to thwart such things. It's gotten to a point where a repeat offender has me wound up enough to prepend his AS into some of my paths. I wish there was a simpler way to turn them off. :( that's bad news... config hackery is brittle. (but fun)
Re: Residential CPE suggestions
I still get email updates on the thread I created in mid 2013. In my experience their forum is a good excuse for not EVER answering the phone. And when I say ever.. I mean.. They don't even take sales calls. (the issue is still there.. By the way.) Sent from my T-Mobile 4G LTE Device Original message From: Jared Mauch ja...@puck.nether.net Date: 05/08/2014 9:28 AM (GMT-08:00) To: Nolan Rollo nro...@kw-corp.com Cc: NANOG list nanog@nanog.org Subject: Re: Residential CPE suggestions On May 8, 2014, at 12:19 PM, Nolan Rollo nro...@kw-corp.com wrote: TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be ready for production networks or very patient customers. For what you’re looking for though no one else can match that price point. +1 If you have hardware in-hand and don't mind support via their 'free' forums. If you can reproduce any issues, they will promptly recreate it and fix it. You may end up waiting awhile for the software, but even $big_vendor has that issue. I'm using both the nanobridge/nanobeam hardware as well as edgerouter and unifi and they work quite well. - Jared
Experience with Third-Party memory (Cisco)?
With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks
Re: Observations of an Internet Middleman (Level3)
http://blog.level3.com/global-connectivity/observations-internet-middleman/ See also... Level 3 accuses five unnamed US ISPs of abusing their market power in peering http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed-us-isps-of-abusing-their-market-power-in-peering/ ... I’d love to see Cogent, Google and other providers release their data next, so even if the FCC doesn’t want to pursue this, a growing cry of consumer outrage could push the agency to do something about a very real and difficult problem that’s crippling access to video content on 5 U.S. broadband networks. Level 3 didn’t name names, but based on the deals Netflix has signed and the complaints it has made about ATT, I’m confident that ATT, Verizon and Comcast are among the five.
Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here...
Observations of an Internet Middleman (Level3) http://blog.level3.com/global-connectivity/observations-internet-middleman/ See also... Level 3 accuses five unnamed US ISPs of abusing their market power in peering http://gigaom.com/2014/05/05/level-3-accuses-five-unnamed-us-isps-of-abusing-their-market-power-in-peering/ ... I’d love to see Cogent, Google and other providers release their data next, so even if the FCC doesn’t want to pursue this, a growing cry of consumer outrage could push the agency to do something about a very real and difficult problem that’s crippling access to video content on 5 U.S. broadband networks. Level 3 didn’t name names, but based on the deals Netflix has signed and the complaints it has made about ATT, I’m confident that ATT, Verizon and Comcast are among the five. =JeffH
preemptive apology..
..for inadvertent double-post. mea culpa.
Re: US patent 5473599
On Thu, May 8, 2014 at 3:49 AM, Henning Brauer hb-na...@bsws.de wrote: * Owen DeLong o...@delong.com [2014-05-08 04:36]: I don’t believe for one second that the IESG refused to deal with ‘em. you're free to believe whatever you want and ignore facts. I do believe the IESG did not hand them everything they wanted on a silver platter in contravention of the established consensus process and that they failed to gain the consensus they wanted as easily as they hoped. lie. I was the IESG member responsible for the VRRP working group when the OpenBSD developer (I'm sorry, Henning, I forget if it was you or someone else) came to a VRRP WG meeting and demanded that the IETF handle the patent issue with VRRP. We described the IETF's IPR process and that the policy is explicitly not to do what was being requested, and the response was more or less well, then we'll have to fix the problem for you. At later meetings I heard buzz about how the developers intended CARP to interfere with VRRP, with the philosophical position that VRRP wasn't a protocol. When I first saw the claims that IANA told OpenBSD that you had to have deep pockets to get a protocol number, I asked the IANA to share the original request and any related correspondence with the IESG. They could not find any such correspondence in the raw archive of the iana@iana.orgmailbox. While the OpenBSD project has done an incredible amount of good on the Internet, the version of events described by the 3.5 release song does not match my personal experiences. Bill
Re: US patent 5473599
* Bill Fenner fen...@gmail.com [2014-05-08 20:41]: I was the IESG member responsible for the VRRP working group when the OpenBSD developer (I'm sorry, Henning, I forget if it was you or someone else) wasn't me, as stated repeatedly I wasn't the one talking to the standard bodies. came to a VRRP WG meeting and demanded that the IETF handle the patent issue with VRRP. We described the IETF's IPR process and that the policy is explicitly not to do what was being requested, and the response was more or less well, then we'll have to fix the problem for you. At later meetings I heard buzz about how the developers intended CARP to interfere with VRRP, with the philosophical position that VRRP wasn't a protocol. I think we have told what happened in enough detail in the 3.5 commentary already posted to this thread. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On Thursday, May 08, 2014 05:29:08 PM Nikolay Shopik wrote: I know most people have problems with 2 bgp feeds and 4GB RAM on ASR1002-F (as it max installable memory). So I doubt about 2M routes with 2GB RAM. I've never ran the ASR1002-F, but I know some other ASR1000 platforms consume half the memory just for the IOS image upon boot. This makes running a second instance of IOSd on boxes that have a single RP a sure way to lead to a crash when the same box is running BGP (happened to me once, 2nd IOSd never again). Mark. signature.asc Description: This is a digitally signed message part.
Re: bgp convergence problem
On Thursday, May 08, 2014 06:34:14 PM Christopher Morrow wrote: :( that's bad news... config hackery is brittle. (but fun) Don't I know :-)... *sigh* Mark. signature.asc Description: This is a digitally signed message part.
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On Tue, May 06, 2014 at 03:39:13PM +, Drew Weaver wrote: I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. Closer to? Internap announces 507K prefixes to me today. Coupled with the prefixes I carry in iBGP internally, I've been sitting at 511K for quite some time, and at occasions, exceeded 512K in the last 2 weeks. L3 Forwarding Resources FIB TCAM usage: TotalUsed %Used 72 bits (IPv4, MPLS, EoM) 802816 511848 64% IP routing table maximum-paths is 32 Route SourceNetworksSubnets OverheadMemory (bytes) connected 0 31 30124464 static 1 78 17456 11376 ospf 1 1 310 22392 44784 Intra-area: 110 Inter-area: 160 External-1: 0 External-2: 41 NSSA External-1: 0 NSSA External-2: 0 bgp 23456 167707 343507 3680812875466680 External: 507479 Internal: 3735 Local: 0 internal605413246152 Total 173763 343926 3685098888773456 -- Brandon Ewing(nicot...@warningg.com) pgpNYNuoqXpz4.pgp Description: PGP signature
Re: Experience with Third-Party memory (Cisco)?
On 08/05/14 17:46, Shawn L wrote: Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. As far as I'm aware, there are up to four ISR 3825s still operating somewhere I've worked previously, with Crucial DIMMs in them. The stuff that came out looked pretty bog-standard OEM stuff, too. I suppose it could depend on what type of memory it is, but when it's just regular DDR SDRAM, I don't see any cause for concern for the few tens of pounds it cost (versus £hundreds for Cisco's own) to find out. Tom
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
I could never get an definitive answer out of TAC or my account team, but I believe the ASR1002 w/ESP5 is also affected. On Thu, May 8, 2014 at 1:15 AM, Nikolay Shopik sho...@inblock.ru wrote: Asr1002-f may have problem as it limited to 512k iirc On 08 мая 2014 г., at 2:45, Shawn L sha...@up.net wrote: Do the ASR1k routers have this issue as well? I searched around but couldn't find any information. -- Forwarded message -- From: Irwin, Kevin kevin.ir...@cinbell.com Date: Wed, May 7, 2014 at 10:39 AM Subject: Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. To: nanog@nanog.org nanog@nanog.org I¹m really surprised that most people have not hit this limit already, especially on the 9K¹s, as it seems Cisco has some fuzzy math when it comes to the 512K limit. Also make sure you have spare cards when you reload after changing the scaling, those old cards don¹t always like to come back. On 5/6/14, 7:01 PM, Larry Sheldon larryshel...@cox.net wrote: On 5/6/2014 10:39 AM, Drew Weaver wrote: Just something to think about before it becomes a story the community talks about for the next decade. Like we have for the last two? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document.
Re: Experience with Third-Party memory (Cisco)?
On 05/08/2014 01:46 PM, Shawn L wrote: With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks No direct experience with Cisco but we used to use Kingston memory in Dell servers without any issues. attachment: boutilpj.vcf
RE: Experience with Third-Party memory (Cisco)?
A few years back, we had to do memory upgrades on our ASAs in order to move to 8.3 code. All was done with 3rd party memory kits. There have been no performance issues we've noticed with them. The one issue we had was that one of the memory sticks in the kit was bad. The vendor immediately sent out a replacement for it and all was well after that. -Gary -Original Message- From: NANOG [mailto:nanog-bounces+gary.dunaway=teamhgs@nanog.org] On Behalf Of Shawn L Sent: Thursday, May 08, 2014 11:47 AM To: nanog Subject: Experience with Third-Party memory (Cisco)? With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ Please make note of our new e-mail domain name: TEAMHGS.COM. Request you to update your address book accordingly. Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Hinduja Global Solutions or postmas...@teamhgs.com immediately and destroy all copies of this message and any attachments. 9284f6a0-bf16-11e3-b1b6-0800200c9a66
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On 05/06/2014 05:39 PM, Drew Weaver wrote: I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. Thanks for this e-mail with clear subject ;) Did anyone yet calculated roughly when the ipv4 routing table will hit 512K ?
Re: Experience with Third-Party memory (Cisco)?
Running 6500's and 7200's with 3rd party memory... No issues. On Thu, May 8, 2014 at 7:02 PM, Gary Dunaway gary.duna...@teamhgs.com wrote: A few years back, we had to do memory upgrades on our ASAs in order to move to 8.3 code. All was done with 3rd party memory kits. There have been no performance issues we've noticed with them. The one issue we had was that one of the memory sticks in the kit was bad. The vendor immediately sent out a replacement for it and all was well after that. -Gary -Original Message- From: NANOG [mailto:nanog-bounces+gary.dunaway=teamhgs@nanog.org] On Behalf Of Shawn L Sent: Thursday, May 08, 2014 11:47 AM To: nanog Subject: Experience with Third-Party memory (Cisco)? With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ Please make note of our new e-mail domain name: TEAMHGS.COM. Request you to update your address book accordingly. Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Hinduja Global Solutions or postmas...@teamhgs.com immediately and destroy all copies of this message and any attachments. 9284f6a0-bf16-11e3-b1b6-0800200c9a66 -- Regards, Chris Knipe
Re: Experience with Third-Party memory (Cisco)?
This is what your looking for : http://www.ebay.com/itm/IBM-PC2700U-512MB-DDR-CL2-5-333Mhz-ECC-Memory-38L52 31-/331191705115?pt=US_Memory_RAM_hash=item4d1c905e1b 512MB DDR CL2.5 Unbuffered/Unregistered CL2.5 - buy 10 and have a huge stack of spares :) -- Geraint Jones Director of Systems Infrastructure Koding (AS62805) https://koding.com gera...@koding.com Phone (415) 653-0083 On 9/05/14 4:46 am, Shawn L sha...@up.net wrote: With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks
Re: US patent 5473599
I think we have told what happened in enough detail in the 3.5 ^your version of commentary already posted to this thread. randy, yet another of the hordes of vrrp users
Re: Experience with Third-Party memory (Cisco)?
I used some old laptop simms from ebay in my 2801.. Worked like a charm :) On 5/8/14, 10:08 PM, Geraint Jones gera...@koding.com wrote: This is what your looking for : http://www.ebay.com/itm/IBM-PC2700U-512MB-DDR-CL2-5-333Mhz-ECC-Memory-38L5 2 31-/331191705115?pt=US_Memory_RAM_hash=item4d1c905e1b 512MB DDR CL2.5 Unbuffered/Unregistered CL2.5 - buy 10 and have a huge stack of spares :) -- Geraint Jones Director of Systems Infrastructure Koding (AS62805) https://koding.com gera...@koding.com Phone (415) 653-0083 On 9/05/14 4:46 am, Shawn L sha...@up.net wrote: With all the talk lately about the growth in routes, I got to thinking about upgrading the memory in a couple of my routers. Does anyone have experience using third-party guaranteed compatible memory. With Cisco's discount it looks like I can upgrade for $5k vs $700 with third party memory. I'm just wondering if others have used it, and how it's performed, or if it isn't worth the risk. thanks
