On Wednesday, January 11, 2012 04:28:55 AM Andrew Hoyos wrote: > IIRC, there is two different versions of the CER, the > "CER" and "CER-RT", the latter having 1.5mil v4 FIB.
That, then, could be it. When we were looking at Brocade back in 2009, there was only the CER2000 and the CES2000. The CES2000 only handled 8,000 v4 entries in the FIB (although the latest documentation suggests 32,000 entries for v4 and 8,000 entries for v6), while the CER2000 was, as mentioned before, 512,000. Perhaps the hardware has since been revised. To be fair, we haven't looked at Brocade since we settled on the ME3600X. In our initial requirements, we thought needing a large FIB would be great as we extended IP/MPLS into the Access, to have end-to-end MPLS forwarding, but later on, we figured that it's really not that necessary. One option was to use the MPLS Default Route Label feature, but after much thought and planning, we just ended up originating a regular IP default route toward our ME3600X's from our route reflectors. As the route reflectors do not run MPLS, there was no outgoing MPLS label attached to the next-hop address of that default route, i.e., the route reflector. So traffic to the Internet from customers in the Access is MPLS-switched through the Access network. When it hits the Aggregation network (Juniper M320's, T320's and MX480's today), it finds that no label is assigned to the route reflector route. At that point, IP forwarding occurs, and since PHP happened before the packet got to the Aggregation routers, the Aggregation routers now impose a new MPLS label on to the IP packet because they contain the full BGP routing table, which means they have MPLS FEC's. In the end, traffic never has to go to the route reflectors after the last hop ME3600X in the Access ring. Pretty cool. Totally negates the need for a device with a large FIB in the Access, without restricting IP/MPLS forwarding flexibility. Of course, it means customers that need a full BGP routing table from you would need to run eBGP Multi-Hop. While I don't particularly fancy eBGP Multi-Hop, it's a small price to pay for the overall benefit. One thing to note - unlike Junos and IOS XR, IOS and IOS XE will, by default, assign a label to a route that is coming from a box which does not run MPLS, even though there won't be an outoging label assigned to it. Junos and IOS XR will not assign any labels to any routes that come from boxes not running MPLS. So no extra tweaking is needed to have this functionality. Not sure how an IOS or IOS XE box would perform in this topology without manually configuring label assignments/bindings, as our Aggregation testing has centred around Junos and IOS XR - but one would be able to make it work either way. If needed, all the knobs are there :-). Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
