I can't speak for jnpr but, in general, this allows for better
scalability. When designing a forwarding engine you're always at the
mercy of what technology has to offer today, or in jnpr's case,
something like 2 years ago. For example, building a (programmable or
even hard-coded) 40Gbps forwarding engine (and its associated memory)
with any amount of features is quite challenging when some of these
features are often enabled on the RX side and others on the TX side.
Staying within a cycle budget in order to maintain "good enough"
performance with both ingress and egress features on a *single*
forwarding engine is typically not possible at 40Gbps in my experience.
So, having two forwarding engines can allow the following:
1. You can store L2 rewrites (for nexthop) on TX side (split decap/encap
chains)
2. Again, allows you to split input and output features which allows
more simultaneous features to be supported at 40Gbps
3. I believe there are also features (eg GRE and MPLS/VPN deagg??) that
need to or must be done on the TX side.
4. I'm sure there's other stuff I'm missing too...
However, I believe one of the challenges this creates is maintaining a
reasonable power budget that will allow a large box with lots of 40Gbps
LCs to be properly cooled in a 19" rack.
Thanks,
Chris
> -----Original Message-----
> From: Saku Ytti [mailto:saku+juniper-nsp@ytti.fi]
> Sent: Tuesday, April 23, 2002 12:23 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] T640 and two route lookups
>
>
> Hello,
>
> Can someone explain why T640 does two route lookups?
>
> ingress PIC -> ingress PFE (route lookup to determine egress PFE) ->
> egress PFE (route lookup to determine egress PIC) -> egress PIC.
>
> Why not save both information at once?
>
> --
> ++ytti
>
>
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:35 EDT