What router would be recommended to run two 100 meg links to an ISP with CEF load balancing and Forwarding on both links. Also what memory requirements.
Or is there a better approach for a pair of bonded 100 meg links with heavy usage.
The handoff is two 100Mbps links to the provider (the provider wont bond the links) then the local-loop is a 200Mbps link to us.
Beside the physical speed, what traffic volume and features do you expect to have on the links ?
Typical internet traffic, VPNS, etc. I would expect the links to be loaded at around 70% utilization most of the time. Fairly heavy use.
Then to be on the safe side, get 7200VXR with NPE-G2 (G1 if G2 is budget prohibitive).
Hope this helps, please rate post if it does!
I agree with Paolo, both that the G2 is a safe choice, and that a G1 would likely work too. (The difference, the G2 provides more headroom for growth due to its additional performance. 2x a G1)
If you don't see the need for slots, and expect to just continue to use Ethernet, you might also consider the 7301 (about the same performance as a G1) or the 7201 (about the same performance as the G2).
If it's important to you, note neither the G2 nor 7201 run a mainline code yet; both should be able to run 12.5 when it's released.
Other possible routers might include the 3845 which offers half the performance of the G1 (NB: this might not offer enough performance for what you describe).
Or, there's the 7304 with NSE-150, which offers even more performance than the G2 (NB: also runs non-mainline IOS; I suspect it won't go mainline). The 7304 supports dual NSE-150s for redundancy. The 7304 also can support OC-12 and OC-48 interfaces, where the 7200 is limited to OC-3.
With regard to your question of memory, you didn't mention whether your accepting full Internet tables. Without such, likely the base memory configuration of all(most?) of the above would be sufficient.
Agree with all Joseph said, with one note.
Not necessarily a mainline version is better than a non-mainline, actually it can be very likely be the opposite.
Why is that, need some explanation and understanding about how things works within Cisco. I'm a good witness about that as I have been both a devtest eng. and technical marketing eng. at the BU (business unit) that makes the midsize routers.
I'm talking eminently about the "BU" specifics trains like S was once, then SB, or XJ for voice and ISR routers, but not the the generic T thta spawns features across all the platforms almost.
The BU trains are the more thoughtfully tested trains of all. Why is that, because these falls directly under the responsibility of the same Engineering that designed the product in its entirety and enjoys the success or misfortunes of it, depending on the actual quality delivered.
These release often incorporate improvements that aren't visible but very important internally, like driver optimization, memory management, code streamlining etc. The objective of the BU is that your expensive router has software up to par with it, and the only way to do that is have in house software developers and testers.
Also, BU-specific trains are the only ones that are tested for performances too. If a release falls significantly in performances respect to the previous one under same circumstances, it is held until fixed.
In contrast, mainline and T development, that depends from what was once called "IOS technologies" BU, doesn't generally do performance testing, and for a good reason, they would have too many platforms and too many test cases.
When they adopt and merge the newer code from T trains and BU-specific trains into a new mainline (happens every two years or so), chances are something will not get quite right. Have you noticed that the release cisco ships with most routers now, 12.4(3) has gone thru revisions a-b-c-d-e-f-g-h-i-j ?
Well it's good that it got so much care, at the same time it shows that also mainline suffers of bugs like any other train!
Fortunately the mainline designation will will go away or so I'm told, hopefully the equation "mainline=good, non-mainline=buggy" will fade out with time, too much damage has been created by that, customers resisting to run good images just because these had some funny letters in the filename.
I hope I've been able to explain in summary why is better to run a "BU-specific" train on your router in most cases.
Paolo, from what I wrote, I didn't say mainline was better, only that it wasn't yet available on a couple of 7xxx platforms. However, honesty compels me that I, for one, often equate mainline as possibly more stable (more on that below). So, your explanation of BU-specific trains, and the care given to them, was very interesting, indeed!
You make an interesting point about customers that might equate "mainline=good, non-mainline=buggy" and being fearful of funny letters in the filename. For my part, with regard to stability, I'm more interested in where the IOS software is within its lifecycle, and what that lifecycle comprises. With a mainline frozen at x.x(1), by the time it gets to about x.x(y), where y is considered GD (something else going away? safeharbor replacement?), then I hope most issues (i.e. bugs) have been resolved.
I too have often avoided images with funny letters, but not so much over concern of stability, assuming they too are high on the patch level. I'm more concerned with their "interesting" feature sets; often offering much except something I would like to use.
For instance, I've worked on a 7304-NSE-100 with the 12.2SB train. Works like a champ, yet although it's not limited to just mainline 12.2 features, there are 12.3 and 12.4 features I would like to implement which it doesn't support.
Another consideration, I think about, how many others are using this platform or IOS? Here too, perhaps more usage will find more bugs, and those discovered, resolved faster. I'm not implying different levels of support service, what I have in mind, the more instances where a bug is seen, often provides more information that assists in its resolution. So, here too, a mainline release used more often could imply more stability (offset though by what you revealed about BU treatment).
Again, thank you for the additional "insider" insight, and as with many or your other posts, deserves a 5.
Thank for the appreciation. On this same track, I can add something more I'm afraid again doesn't go in the direction you might expect.
As you can image, cisco has internal quality metrics for software defects. Basically, charts with sev. 1,2,3 bugs mapped against consecutive releases of a train, let's say a mainline. One would expect new bugs found to decrease linearly over time. Well, is not quite so.
Anyone can very that: go in bug tool and search eg for sev 2 and sev 3 bugs (meaning VERY annoying), you will see that there are the same chances they're found into some like 12.x(2) and into 12.x(10). Why is that, very simple, for the bug discovered at 12.x(10), no customer had the situation triggering it before, or more often, no customer could be bothered to pursue the issue with the tac, so they just "workarounded" and forgot. So a bug has been quietly sitting there waiting, sometime for years.
So again I'm happy that the GD concept will go away. Not sure how it will replaced, but let's hope by something smart.
Yes, you're correct about bugs sometimes remaining around awhile. I've also seen (rarely) something broken in a later mainline patch which had been working fine in an earlier patch release causing us to revert back to the earlier. In one instance, recall it took about 6 patch releases before the introduced bug was corrected. These situations, though, were resolved by the time the release went GD. So, do hope there's some similar replacement.
Have you ever used IP CEF for load sharing two links of this size? I was looking at using per-packet sharing across the two links with two default routes out. What kind of memory requirements would i need for this?
Or is using CEF in this case not advisable?
I've never used CEF per-packet beyond dual E-1s, although I suspect it would handle your fastEs without an issue. However, unless most of your traffic is just between two hosts, normal CEF load balancing is probably "good enough" and avoids delivering packets out of sequence.
Paolo, nice of you to share all this useful information. In any case, this love or hate for letters is not without good reason. I have good experience with S and bad experience with T. Mainline so and so. But then again, the customer experience with every image has to do with the specific environment and what features exactly they need enabled on their devices. An image can work perfectly until you decide to enable something more.