 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
11 messages in net.nether.puck.cisco-nsp[c-nsp] Re: 7500 PPPoE dCEF aggregation| From | Sent On | Attachments |
|---|---|---|
| Joe Maimon | Jan 16, 2005 2:48 pm | |
| Niels Bakker | Jan 16, 2005 4:14 pm | |
| Joe Maimon | Jan 16, 2005 4:29 pm | |
| Gert Doering | Jan 17, 2005 12:05 pm | |
| Oliver Boehmer (oboehmer) | Jan 17, 2005 12:28 pm | |
| Gert Doering | Jan 17, 2005 3:20 pm | |
| Rodney Dunn | Jan 17, 2005 5:08 pm | |
| Rodney Dunn | Jan 17, 2005 5:10 pm | |
| Joe Maimon | Jan 17, 2005 5:13 pm | |
| Robert E.Seastrom | Jan 18, 2005 10:28 am | |
| Rodney Dunn | Jan 18, 2005 10:54 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | [c-nsp] Re: 7500 PPPoE dCEF aggregation | Actions... |
|---|---|---|
| From: | Rodney Dunn (rod...@cisco.com) | |
| Date: | Jan 18, 2005 10:54:07 am | |
| List: | net.nether.puck.cisco-nsp | |
On Tue, Jan 18, 2005 at 10:28:45AM -0500, Robert E.Seastrom wrote:
Rodney Dunn <rodunn at cisco.com> writes:
There is a 2048 IDB limit on the 75xx and it will most likely never be increased. There are multiple reasons why this box is not recommended for broadband aggregation. ... If it were me looking for a platform to do broadband aggregation I would not look at the 75xx for this purpose.
72xx/G1, 7301, 10k are the most commonly used boxes for this space that I have seen.
It's not as if the features aren't included, though as you mentioned, testing may be a bit spotty... As with every other platform, it's a matter of calibrating one's expectations properly and understanding the limitations of the kit that you're rolling out.
100% agree from the scalability perspective. It's when something doesn't work technically that it gets more complicated. If it works and can be used I'm for having it work in any deployment scenario.
It's clear we are not there but in a perfect world if you can configure it it should work and be fully supported by the vendor up to certain scalability limits of course. I'm talking more about the base functionality.
For example, I've had splendid success with 7505/rsp1 and 7010/rsp7k in proto-wimax proof-of-concept networks and in the lab -- the application is naturally low-bandwidth and in any event, 75-100 customers would be a huge number to have connected at once. For that niche, it's hard to beat the price/performance of above-cited boxes, even going with something like RouterOS on commodity Intel hardware (not supporting Radius attribute 242 (Ascend-Data-Filter) was decidedly a big minus, and 11 (Filter-Id) is not an acceptable substitute).
What this requires on the part of the technical team is a close working relationship with the financial folks. It also requires trust between the two teams. The basic proposition is "I can save you 90% on your startup equipment costs IFF you understand that this is NOT a solution 'to grow with', but rather a solution 'to get some revenue with', and that once there is revenue-generating traffic on the network, an upgrade of the equipment will be required in fairly short order, but at least your business model has been somewhat validated before you go spending big money on the real iron".
Can you put that on the web so I can use it as a reference? :)
Rodney
---Rob