[c-nsp] Recommendation for small GBit router

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20120111/b6afa585/attachment.sig>