Mailing List Archive

MPLS load balancing hash-key
Hi,

What will happen if I configure load-balancing with hash-key as
follows:

forwarding-options {
hash-key {
family inet {
layer-3;
layer-4;
}
family mpls {
label-1;
label-2;
}
}
}

Will the router take into account the IP layer when it receives
MPLS packet on ingress interface?
Thanks in advance,
Adam.

-----------------------------------------------------------------------------
"26 maja Dzie? Matki - wy?lij kwiaty." Poczta Kwiatowa dor?cza kwiaty
pod wskazany adres na ca?ym ?wiecie. < http://pasaz.wp.pl/app/vsmp.po?s=46 >
MPLS load balancing hash-key [ In reply to ]
No.

MPLS packets are hashed using only the MPLS hash key. MPLS packets
are not further inspected to determine if the encapsulated data is
an IP packet or something else.

Similarly, IP packets are hashed using only the IP hash key.



-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Adam Szymajda
Sent: Tuesday, May 20, 2003 6:57 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MPLS load balancing hash-key


Hi,

What will happen if I configure load-balancing with hash-key as
follows:

forwarding-options {
hash-key {
family inet {
layer-3;
layer-4;
}
family mpls {
label-1;
label-2;
}
}
}

Will the router take into account the IP layer when it receives
MPLS packet on ingress interface?
Thanks in advance,
Adam.

----------------------------------------------------------------------------
-
"26 maja Dzie? Matki - wy?lij kwiaty." Poczta Kwiatowa dor?cza kwiaty
pod wskazany adres na ca?ym ?wiecie. < http://pasaz.wp.pl/app/vsmp.po?s=46 >


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
MPLS load balancing hash-key [ In reply to ]
On Tue, May 20, 2003 at 07:04:28AM -0700, Paul Goyette wrote:
> No.
>
> MPLS packets are hashed using only the MPLS hash key. MPLS packets
> are not further inspected to determine if the encapsulated data is
> an IP packet or something else.

...which sucks. :) Other vendor's equipment is actually looking beyound the
shim header and uses IP header data for LB hash (not sure about non-IP).
Other vendor's bucket algorithm does not always provide nice load spreading,
too, but it's still better that Juniper's one (especially when there's not
enough egress labels for the algorithm to start working acceptably). (I'm
*not* advocating the other vendor, don't get me wrong). But hey - you can't
have your cake and eat it, too (which is a shame anyway). ;)

> Similarly, IP packets are hashed using only the IP hash key.
>
>
>
> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Adam Szymajda
> Sent: Tuesday, May 20, 2003 6:57 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] MPLS load balancing hash-key
>
>
> Hi,
>
> What will happen if I configure load-balancing with hash-key as
> follows:
>
> forwarding-options {
> hash-key {
> family inet {
> layer-3;
> layer-4;
> }
> family mpls {
> label-1;
> label-2;
> }
> }
> }
>
> Will the router take into account the IP layer when it receives
> MPLS packet on ingress interface?
> Thanks in advance,
> Adam.
---end quoted text---

SY,
--
D.K.
MPLS load balancing hash-key [ In reply to ]
On Thu, May 22, 2003 at 02:27:45PM +1000, Dmitri Kalintsev wrote:
| On Tue, May 20, 2003 at 07:04:28AM -0700, Paul Goyette wrote:
| > No.
| >
| > MPLS packets are hashed using only the MPLS hash key. MPLS packets
| > are not further inspected to determine if the encapsulated data is
| > an IP packet or something else.
|
| ...which sucks. :) Other vendor's equipment is actually looking beyound the
| shim header and uses IP header data for LB hash (not sure about non-IP).
| Other vendor's bucket algorithm does not always provide nice load spreading,
| too, but it's still better that Juniper's one (especially when there's not
| enough egress labels for the algorithm to start working acceptably). (I'm
| *not* advocating the other vendor, don't get me wrong). But hey - you can't
| have your cake and eat it, too (which is a shame anyway). ;)

which will draw up the question:
how does a core LSR really know that the payload is IPv4 ?
crawling through the stack and looking to 0x45 - 0x4f
after a label with BOS bit set alike fingerprints, gives a
high likelyhood that the payload is indeed IPv4, however you'll
never _know_;

if you need MPLS-deep-crawling functionality for load balancing
purposes pls talk to your local sales team, they can give you
our view plus our roadmap in this space;

/hannes
MPLS load balancing hash-key [ In reply to ]
On Sun, May 25, 2003 at 05:11:18PM +0200, Hannes Gredler wrote:
> | > No.
> | > MPLS packets are hashed using only the MPLS hash key. MPLS packets
> | > are not further inspected to determine if the encapsulated data is
> | > an IP packet or something else.
> | ...which sucks. :) Other vendor's equipment is actually looking beyound the
> | shim header and uses IP header data for LB hash (not sure about non-IP).
> | Other vendor's bucket algorithm does not always provide nice load spreading,
> | too, but it's still better that Juniper's one (especially when there's not
> | enough egress labels for the algorithm to start working acceptably). (I'm
> | *not* advocating the other vendor, don't get me wrong). But hey - you can't
> | have your cake and eat it, too (which is a shame anyway). ;)
>
> which will draw up the question: how does a core LSR really know that the
> payload is IPv4 ? crawling through the stack and looking to 0x45 - 0x4f
> after a label with BOS bit set alike fingerprints, gives a high likelyhood
> that the payload is indeed IPv4, however you'll never _know_;

Um, how about looking deep enough to see the IP header checksum (and
verifying it, of course)? This will improve the probability of hitting the
IP packet immensly. Not sure if current ASIC architecture would allow for
this, though - necessary details seem to have slipped from my mind.

> if you need MPLS-deep-crawling functionality for load balancing purposes
> pls talk to your local sales team, they can give you our view plus our
> roadmap in this space;

There where I needed this we were lucky enough to have just enough egress
labels to make it work, so I'm not desperate at the moment.

It would be interesting to hear although how it is proposed to be handled in
the future, so I will use your invitation to contact my local team and ask
them. :)

>
> /hannes
---end quoted text---

SY,
--
D.K.