[j-nsp] Limit on interfaces in bundle

Jesper Skriver jesper at skriver.dk
Fri Oct 30 06:35:02 EDT 2015


On Fri, Oct 30, 2015 at 02:44:44AM +0200, Saku Ytti wrote:
> On 30 October 2015 at 00:54, Cydon Satyr <cydonsatyr at gmail.com> wrote:
> 
> > Adam I believe that is correct. If I remember this, if it's something other
> > than 0x4/0x6 Trio chip looks at bits after first 12 bytes; if it's
> > 0x0800/0x86dd it still load balances this packet based on IPv4/IPv6 rules,
> > and if it's 0x8100 it skips up to two vlan headers and again checks for real
> > ethertype.  If it's something other than this it stops and just load
> > balances used MPLS tags.
> 
> Wouldn't this fall in the  SADDR range, where both 0x0800 and 0x86dd
> would be acceptable values for all Pv4/IPv6/ETH, making it completely
> unviable way to discriminate.
> There isn't really super good way to duck-type in LSR transit. Frankly
> MPLS would have done well to specify multiple ethertypes, MPLS-IP,
> MPLS-ETH, MPLS-UNSPECIFIED, this could be introduced post-fact, by
> making 8847 MPLS-UNSPECIFIED.

That would not be practical to implement for a router, implementations
typically have the L2 header cached and the L3 forwarding
constructs just point to a rewrite object that contain the
appropriate L2 encap for the next-hop selected by L3.

What you are proposing means that a single L3 object needs to
point to different L2 rewrite objects depending on what L2 encap
was on the packet when received.  Many architectures just cannot
do that, and for others it would for sure come at a performance
penalty.

/Jesper


More information about the juniper-nsp mailing list