The trick is some of those additional features are better
optimized in more modern IOS releases (SRE, 15S). Quagmire.
Mark.
Haha, you remind me of PXF (although that was the NSE-100
and NSE-150).
Mark.
At 700-800 megabit/s aggregated througput (in+out), you're very clsoe to the max performance envelope of the G1. If you're going down this route, be prepared to purchase new hardware at short notice in case your traffic increases faster than you anticipated.
Cisco once implemented and released this feature to use the second core of the NPE-G1, most notably to manage the BRAS & en/decapsulations tasks for LAC/LNS/PTA (PPPoE, L2TP...), effectively offering such 1.6 factor.
It was called MPF, and was released in special 12.3-YM IOS (in 2004/2005 I guess).
The first core was still running "normal" IOS while the second core was running a dedicated microcode (acting as some sort of data plane).
However several features were not available, and it was quite buggy and unstable (unless you only used the very minimum features implemented in the MPF microcode: no MSS adjust, no ACL for PPP sessions...).
It was quickly deprecated anyway.
http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_end-of-life_notice0900aecd8067dd9f.html
Are you suggesting getting the default gateway from both providers or getting the full table from one and using the default as a backup on the other (7206)?
Thanks,
Whatever suits you best. Test and see. I'd just receive the full table
anyway but filter them out, letting only the default routes go into the
RIB. This should streamline your FIB. As I say, you lose outbound load
balancing and your redundancy becomes all-or-nothing, but you save a few
cycles.
Again, I wouldn't recommend any of this because of the drawbacks, but
along with other recommendations that others have made, like Turbo ACLs,
it may buy you some time.
Or assuming your using an Ethernet of some sort as your upstream connections you could grab something like a CCR from mikrotik for < $1k and sleep easy knowing you're only using 6% of it's capacity.
We run 7206 NPE-G1s on some GigE peering points. At about 800Mbps of
aggregate Internet traffic (inbound + outbound, as measured from Cacti)
the CPU sits around 70%.
Setup:
- inbound and outbound Internet-facing ACLs (50 lines and 25 lines
respectively, turbo ACL)
- Inbound Internet-facing policy-map to remark DSCP (references 7-line ACL)
- minimal routes via BGP (approx 1500)
- 15.1 SP train
YMMV, but they work well for us in this scenario. With
downstream-to-upstream traffic patterns of approx 7-to-1 the GigE and CPU
will peak out at about the same time.
Side note - our G2s at that same 800Mbps traffic rate run at approx 60%
CPU.
Cheers
Mark W
Our G2 with BGP full-view and sampled netflow 1:100 doing 1,2Gbit with
about 88% load.
I generally spec the NPE-G1 as "up to 1Gbps" if you're using the onboard ports. This assumes ISP type loads with little upstream, lots of downstream, and relatively large flows (mostly 1500 byte packets) on ethernet. It sounds like this fits your usage case well. If one were to throw in ATM or another media type I'd drop the performance quote to half. If you cannot make use of CEF, or use source based routing, drop the performance to ~ 100Mbps. NPE-G1 with 1Gbps of RAM can take 2 full BGP feeds (about 700MB of memory used). Each additional feed will likely require another 100-200MB of memory (no soft reconfig).
NPE-G2 w/ 2GB of RAM can take several full feeds and may be able to operate up to 2Gbps using the onboard ports. I haven't pushed one of these to its limits, most people seem to move on to newer platforms first.
--Blake
Vlade Ristevski wrote the following on 2/10/2014 9:17 AM:
Thanks for all the responses. It's been very helpful. Based on your collective feedback, I'm definitely going to retire the 7206 this summer. I'm looking at the ASR-1002-X and Juniper MX-5, MX-10. I may as well go with something 10Gig capable.
My Cisco SE brought up an interesting alternative. This summer we're replacing our 6513 Sup720 with a pair of 6807 with redundant Sup 2Ts. It is where all our internal Fiber terminates and where internal routing happens. He said we can add extra memory and terminate our BGP sessions here and use that for our Internet connections. After thinking it over, I'd still rather have dedicated routers for our Internet access but I'm curious what you guys think about this suggestion.
My Cisco SE brought up an interesting alternative. This summer we're replacing our 6513 Sup720 with a pair of 6807 with redundant Sup 2Ts. It is where all our internal Fiber terminates and where internal routing happens. He said we can add extra memory and terminate our BGP sessions here and use that for our Internet connections. After thinking it over, I'd still rather have dedicated routers for our Internet access but I'm curious what you guys think about this suggestion.
I think at the Internet edge, physical separation trumps logical unless you have no other choice. Personally, I would keep them separate.
My .02,
-dan
A lot of people use SUP720-3BXL and RSP720-3CXL for full BGP table routing. This will work just fine until the IPv4 routing table reaches 800k entries or something (if you want to do IPv6 at the same time, you probably don't want to go over 800k IPv4 routes and 50k IPv6 routes to have a little bit of margin of the around 1M routes the XL sup can handle).
If you have the budget, run dedicated peering/upstream
routers.
Hierarchical separation of functions at the hardware level
provides lots of flexibility in other areas as your network
grows. If cash is not a constraint, go for it, I'd say.
Mark.
Or route churn which quickly shows the inadequacies of the
CPU in those control planes.
An NPE-G1/G2 has a much quicker CPU.
Mark.
Dan Brisson wrote the following on 2/12/2014 9:06 PM:
My Cisco SE brought up an interesting alternative. This summer we're replacing our 6513 Sup720 with a pair of 6807 with redundant Sup 2Ts. It is where all our internal Fiber terminates and where internal routing happens. He said we can add extra memory and terminate our BGP sessions here and use that for our Internet connections. After thinking it over, I'd still rather have dedicated routers for our Internet access but I'm curious what you guys think about this suggestion.
I think at the Internet edge, physical separation trumps logical unless you have no other choice. Personally, I would keep them separate.
My .02,
-dan
A point to consider:
Layer 3 infrastructure and the services that run on L3 devices (ssh, ntp, routing protocols, packet classification, monitoring, shaping, etc) have a much higher surface area for attack and bugs. They therefore (theoretically) require more frequent updates and encounter more problems. Do you want to disrupt your layer 2 infrastructure every time you update your L3 infrastructure? Do you want to expose your L2 infrastructure to the potential bugs in L3 and above code? Separate physical devices can create a more available network.
Counter point:
A router in front of a router adds an additional point of failure. If you're not gaining anything (features, redundancy, etc) by its introduction you're just wasting money and hurting your (potential) availability.
If you provide a lot of L2 only services, or have a substantial amount of traffic that never leaves L2, I would recommend dividing your network by OSI layer. This allows you to easily have different update, security, warranty, etc policies for the different services your network provides. If you are an ISP offering L3 only services or all traffic on your network hits L3, then a failure of any one layer will disrupt all communication; In this case, you may save time/money and increase availability by combining L2 and L3+ functions.
--Blake