Mailing List Archive

Verifying Juniper ECMP
​I know that ECMP is, by default, based on a hash of source and destination
IP address, and I know that we can see the available paths by doing "show
route forwarding-table destination <prefix>", but is there a way to
determine which path a particular flow is using?

For those of you familiar with Cisco, I'm looking for an equivalent to
"show cef exact-route".

Thanks,
John​
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
Hi John,

as usual with Juniper it's ridiculously overcomplicated, David Roy wrote a fine article about that, at least for MX with DPC:
http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html


Olivier

Le 15 avr. 2014 à 04:01, John Neiberger <jneiberger@gmail.com> a écrit :
> ​I know that ECMP is, by default, based on a hash of source and destination
> IP address, and I know that we can see the available paths by doing "show
> route forwarding-table destination <prefix>", but is there a way to
> determine which path a particular flow is using?
>
> For those of you familiar with Cisco, I'm looking for an equivalent to
> "show cef exact-route".

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
Hello

Since 13.2 Jsim is now available also for MPC (at PFE level) but it is more complex and quite different as Jsim for DPC. I have to write a new blog about that... :)

David


 
David Roy
IP/MPLS NOC engineer - Orange France
Ph. : +33 2 99 87 64 72
Mob. : +33 6 85 52 22 13
SkypeID : davidroy.35
david.roy@orange.com
 
JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)


-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Olivier Benghozi
Sent: mardi 15 avril 2014 11:51
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Verifying Juniper ECMP

Hi John,

as usual with Juniper it's ridiculously overcomplicated, David Roy wrote a fine article about that, at least for MX with DPC:
http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html


Olivier

Le 15 avr. 2014 à 04:01, John Neiberger <jneiberger@gmail.com> a écrit :
> ​I know that ECMP is, by default, based on a hash of source and
> destination IP address, and I know that we can see the available paths
> by doing "show route forwarding-table destination <prefix>", but is
> there a way to determine which path a particular flow is using?
>
> For those of you familiar with Cisco, I'm looking for an equivalent to
> "show cef exact-route".

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
Holy cow. I never would have figured that one out, and the two Juniper
engineers I asked had no idea how to do it. I appreciate the help!

Thanks,
John


On Tue, Apr 15, 2014 at 3:50 AM, Olivier Benghozi <
olivier.benghozi@wifirst.fr> wrote:

> Hi John,
>
> as usual with Juniper it's ridiculously overcomplicated, David Roy wrote a
> fine article about that, at least for MX with DPC:
>
> http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
>
>
> Olivier
>
> Le 15 avr. 2014 à 04:01, John Neiberger <jneiberger@gmail.com> a écrit :
> > ​I know that ECMP is, by default, based on a hash of source and
> destination
> > IP address, and I know that we can see the available paths by doing "show
> > route forwarding-table destination <prefix>", but is there a way to
> > determine which path a particular flow is using?
> >
> > For those of you familiar with Cisco, I'm looking for an equivalent to
> > "show cef exact-route".
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
​Another question: if a link in a ECMP "bundle" goes down and then comes
back up later, do things end up hashed and balanced the same way they were
prior to the link going down, or is there some amount of randomness to it?
If I check a certain flow and see that it is hashed to a particular link,
is it a fair bet that it was hashed to that same link prior to the link
going down?

Thanks,
John​


On Tue, Apr 15, 2014 at 12:07 PM, John Neiberger <jneiberger@gmail.com>wrote:

> Holy cow. I never would have figured that one out, and the two Juniper
> engineers I asked had no idea how to do it. I appreciate the help!
>
> Thanks,
> John
>
>
> On Tue, Apr 15, 2014 at 3:50 AM, Olivier Benghozi <
> olivier.benghozi@wifirst.fr> wrote:
>
>> Hi John,
>>
>> as usual with Juniper it's ridiculously overcomplicated, David Roy wrote
>> a fine article about that, at least for MX with DPC:
>>
>> http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
>>
>>
>> Olivier
>>
>> Le 15 avr. 2014 à 04:01, John Neiberger <jneiberger@gmail.com> a écrit :
>> > ​I know that ECMP is, by default, based on a hash of source and
>> destination
>> > IP address, and I know that we can see the available paths by doing
>> "show
>> > route forwarding-table destination <prefix>", but is there a way to
>> > determine which path a particular flow is using?
>> >
>> > For those of you familiar with Cisco, I'm looking for an equivalent to
>> > "show cef exact-route".
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
See inline, prefixed [Masood] ...


On Thu, Apr 17, 2014 at 1:09 AM, John Neiberger <jneiberger@gmail.com>wrote:

> ​Another question: if a link in a ECMP "bundle" goes down and then comes
> back up later, do things end up hashed and balanced the same way they were
> prior to the link going down, or is there some amount of randomness to it?
>

[Masood] You may not see traffic balanced instantly, because existing flow
will NOT move to the newly added member. Only new flows will get hashed
across the members and then new member will have his fair share of good
luck :) However, the following things may happen and make load balancing
more fun:

1. incorrect load balancing by aggregate next hops
2. incorrect packet hash computation
3. insufficient variance in the packet flow
4. incorrect pattern selection

You may look for "Adaptive Load Balancing", a Juniper method to balance
traffic across LAG members (that focus more on the weights, the bandwidth
and packet stream of link) but that has it's on pros and cons.


> If I check a certain flow and see that it is hashed to a particular link,
> is it a fair bet that it was hashed to that same link prior to the link
> going down?
>

[Masood] AFAIK, #Junos does not keep track of it and I wonder if any other
vendor would do that.


>
> Thanks,
> John​
>
>
> On Tue, Apr 15, 2014 at 12:07 PM, John Neiberger <jneiberger@gmail.com
> >wrote:
>
> > Holy cow. I never would have figured that one out, and the two Juniper
> > engineers I asked had no idea how to do it. I appreciate the help!
> >
> > Thanks,
> > John
> >
> >
> > On Tue, Apr 15, 2014 at 3:50 AM, Olivier Benghozi <
> > olivier.benghozi@wifirst.fr> wrote:
> >
> >> Hi John,
> >>
> >> as usual with Juniper it's ridiculously overcomplicated, David Roy wrote
> >> a fine article about that, at least for MX with DPC:
> >>
> >>
> http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
> >>
> >>
> >> Olivier
> >>
> >> Le 15 avr. 2014 à 04:01, John Neiberger <jneiberger@gmail.com> a écrit
> :
> >> > ​I know that ECMP is, by default, based on a hash of source and
> >> destination
> >> > IP address, and I know that we can see the available paths by doing
> >> "show
> >> > route forwarding-table destination <prefix>", but is there a way to
> >> > determine which path a particular flow is using?
> >> >
> >> > For those of you familiar with Cisco, I'm looking for an equivalent to
> >> > "show cef exact-route".
> >>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
Hi,

Just noticed this thread because I had similar questions. Follow-up questions inline:

On Apr 19, 2014, at 3:54 AM, Masood Ahmad Shah <masoodnt10@gmail.com> wrote:

> See inline, prefixed [Masood] ...
>
>
> On Thu, Apr 17, 2014 at 1:09 AM, John Neiberger <jneiberger@gmail.com>wrote:
>
>> ​Another question: if a link in a ECMP "bundle" goes down and then comes
>> back up later, do things end up hashed and balanced the same way they were
>> prior to the link going down, or is there some amount of randomness to it?
>>
>
> [Masood] You may not see traffic balanced instantly, because existing flow
> will NOT move to the newly added member. Only new flows will get hashed
> across the members and then new member will have his fair share of good
> luck :) However, the following things may happen and make load balancing
> more fun:
>
> 1. incorrect load balancing by aggregate next hops
> 2. incorrect packet hash computation
> 3. insufficient variance in the packet flow
> 4. incorrect pattern selection
>

So let's say I'm standing up a set of servers downstream from the device that are all handling TCP traffic for a single VIP and advertising that IP upstream. If I stood up a new device, I'd expect that if the hash was stateless, packets going to pre-existing servers would now go to the new device, breaking those TCP sessions. Are you saying that's not the case? If so, does that mean that the flow-to-next-hop mappings are cached?

If true, this is actually good news, and I'd love to see if someone from Juniper can verify that this is the case across most/all Juniper platforms (MX, EX, T, ...) or point me to docs that show how different platforms handle ECMP internally.

> You may look for "Adaptive Load Balancing", a Juniper method to balance
> traffic across LAG members (that focus more on the weights, the bandwidth
> and packet stream of link) but that has it's on pros and cons.
>
>
>> If I check a certain flow and see that it is hashed to a particular link,
>> is it a fair bet that it was hashed to that same link prior to the link
>> going down?
>>
>
> [Masood] AFAIK, #Junos does not keep track of it and I wonder if any other
> vendor would do that.
>
>

I'd expect that even without tracking, a stateless hashing algorithm would come up with the same answer giving the same input. So as long as the next-hops are identical and the incoming packet has the same src/dst address and ports, the outgoing next-hop shouldn't change. The question here, based on the above comment, is whether this hashing is, in fact, stateless, or not.

Followup question: Does Juniper have a doc that lists the different maximum number of paths available for ECMP on various platforms?

Thanks,

-C


>>
>> Thanks,
>> John​
>>
>>
>> On Tue, Apr 15, 2014 at 12:07 PM, John Neiberger <jneiberger@gmail.com
>>> wrote:
>>
>>> Holy cow. I never would have figured that one out, and the two Juniper
>>> engineers I asked had no idea how to do it. I appreciate the help!
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On Tue, Apr 15, 2014 at 3:50 AM, Olivier Benghozi <
>>> olivier.benghozi@wifirst.fr> wrote:
>>>
>>>> Hi John,
>>>>
>>>> as usual with Juniper it's ridiculously overcomplicated, David Roy wrote
>>>> a fine article about that, at least for MX with DPC:
>>>>
>>>>
>> http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
>>>>
>>>>
>>>> Olivier
>>>>
>>>> Le 15 avr. 2014 à 04:01, John Neiberger <jneiberger@gmail.com> a écrit
>> :
>>>>> ​I know that ECMP is, by default, based on a hash of source and
>>>> destination
>>>>> IP address, and I know that we can see the available paths by doing
>>>> "show
>>>>> route forwarding-table destination <prefix>", but is there a way to
>>>>> determine which path a particular flow is using?
>>>>>
>>>>> For those of you familiar with Cisco, I'm looking for an equivalent to
>>>>> "show cef exact-route".
>>>>
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>>
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
Hey Chris, I have done a bit of testing with ECMP.


It is absolutely stateless with no caching. If you add new links existing flows will be rebalanced across them immediately. This is whether it is standard L3 ECMP or an aggregate bundle, it works the same in either case. Also like you said given the same input criteria traffic will output to the same link. The exception is if you are using adaptive load balancing where it will tweak the hash in real time based on interface load to try and spread traffic more evenly when you have large flows.


Most of the platforms have 64-way ECMP. You have to explicitly configure it as 16, 32, or 64. I am not aware of a single doc listing maximums, but the “maximum-ecmp” command has some info.


Phil









From: Chris Woodfield
Sent: ‎Friday‎, ‎August‎ ‎8‎, ‎2014 ‎4‎:‎56‎ ‎PM
To: Masood Ahmad Shah
Cc: juniper-nsp@puck.nether.net List





Hi,

Just noticed this thread because I had similar questions. Follow-up questions inline:

On Apr 19, 2014, at 3:54 AM, Masood Ahmad Shah <masoodnt10@gmail.com> wrote:

> See inline, prefixed [Masood] ...
>
>
> On Thu, Apr 17, 2014 at 1:09 AM, John Neiberger <jneiberger@gmail.com>wrote:
>
>> ​Another question: if a link in a ECMP "bundle" goes down and then comes
>> back up later, do things end up hashed and balanced the same way they were
>> prior to the link going down, or is there some amount of randomness to it?
>>
>
> [Masood] You may not see traffic balanced instantly, because existing flow
> will NOT move to the newly added member. Only new flows will get hashed
> across the members and then new member will have his fair share of good
> luck :) However, the following things may happen and make load balancing
> more fun:
>
> 1. incorrect load balancing by aggregate next hops
> 2. incorrect packet hash computation
> 3. insufficient variance in the packet flow
> 4. incorrect pattern selection
>

So let's say I'm standing up a set of servers downstream from the device that are all handling TCP traffic for a single VIP and advertising that IP upstream. If I stood up a new device, I'd expect that if the hash was stateless, packets going to pre-existing servers would now go to the new device, breaking those TCP sessions. Are you saying that's not the case? If so, does that mean that the flow-to-next-hop mappings are cached?

If true, this is actually good news, and I'd love to see if someone from Juniper can verify that this is the case across most/all Juniper platforms (MX, EX, T, ...) or point me to docs that show how different platforms handle ECMP internally.

> You may look for "Adaptive Load Balancing", a Juniper method to balance
> traffic across LAG members (that focus more on the weights, the bandwidth
> and packet stream of link) but that has it's on pros and cons.
>
>
>> If I check a certain flow and see that it is hashed to a particular link,
>> is it a fair bet that it was hashed to that same link prior to the link
>> going down?
>>
>
> [Masood] AFAIK, #Junos does not keep track of it and I wonder if any other
> vendor would do that.
>
>

I'd expect that even without tracking, a stateless hashing algorithm would come up with the same answer giving the same input. So as long as the next-hops are identical and the incoming packet has the same src/dst address and ports, the outgoing next-hop shouldn't change. The question here, based on the above comment, is whether this hashing is, in fact, stateless, or not.

Followup question: Does Juniper have a doc that lists the different maximum number of paths available for ECMP on various platforms?

Thanks,

-C


>>
>> Thanks,
>> John​
>>
>>
>> On Tue, Apr 15, 2014 at 12:07 PM, John Neiberger <jneiberger@gmail.com
>>> wrote:
>>
>>> Holy cow. I never would have figured that one out, and the two Juniper
>>> engineers I asked had no idea how to do it. I appreciate the help!
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On Tue, Apr 15, 2014 at 3:50 AM, Olivier Benghozi <
>>> olivier.benghozi@wifirst.fr> wrote:
>>>
>>>> Hi John,
>>>>
>>>> as usual with Juniper it's ridiculously overcomplicated, David Roy wrote
>>>> a fine article about that, at least for MX with DPC:
>>>>
>>>>
>> http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
>>>>
>>>>
>>>> Olivier
>>>>
>>>> Le 15 avr. 2014 à 04:01, John Neiberger <jneiberger@gmail.com> a écrit
>> :
>>>>> ​I know that ECMP is, by default, based on a hash of source and
>>>> destination
>>>>> IP address, and I know that we can see the available paths by doing
>>>> "show
>>>>> route forwarding-table destination <prefix>", but is there a way to
>>>>> determine which path a particular flow is using?
>>>>>
>>>>> For those of you familiar with Cisco, I'm looking for an equivalent to
>>>>> "show cef exact-route".
>>>>
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>>
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
oh man... this might be the answer to a long standing problem i've been
having with the EX4500's at my core. they do BGP to a bunch of proxy
machines (exabgp) that advertise the same /32 (as a VIP). once every so
often (becoming more often as traffic grows), a TCP packet is forwarded by
the EX to one of the machines which has no knowledge of the original flow.
that machine of course sends back a RST and breaks the whole flow.

i've done exhaustive packet captures for juniper on this, thinking that
somehow the EX was actually duplicating a packet incorrectly out one
interface. but this stateless ECMP rehash for all flows every time a new
flow is added or taken away makes a lot more sense to me, and also really
sucks if true.

case 2014-0123-0781, if anyone at juniper is listening. that case is
_still_ open.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
I've learned that the EX platform only allows 8 equal-cost routes. How many proxies are in your setup?

The behavior you're describing should only happen when one of the ECMP routes is either withdrawn or a new route is advertised.

Followup question: is the flow-hashing algorithm on the EX platform a consistent hash (ring hash)? If so, only flows that were being mapped to the withdrawn route, or that would be hashed to the new route, would be affected. If it's not a consistent hash, then all flows would be re-mapped to new routes whenever there's a change in the available next-hops.

-C

On Aug 9, 2014, at 9:00 AM, ryanL <ryan.landry@gmail.com> wrote:

> oh man... this might be the answer to a long standing problem i've been having with the EX4500's at my core. they do BGP to a bunch of proxy machines (exabgp) that advertise the same /32 (as a VIP). once every so often (becoming more often as traffic grows), a TCP packet is forwarded by the EX to one of the machines which has no knowledge of the original flow. that machine of course sends back a RST and breaks the whole flow.
>
> i've done exhaustive packet captures for juniper on this, thinking that somehow the EX was actually duplicating a packet incorrectly out one interface. but this stateless ECMP rehash for all flows every time a new flow is added or taken away makes a lot more sense to me, and also really sucks if true.
>
> case 2014-0123-0781, if anyone at juniper is listening. that case is _still_ open.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
> i've done exhaustive packet captures for juniper on this, thinking that
> somehow the EX was actually duplicating a packet incorrectly out one
> interface. but this stateless ECMP rehash for all flows every time a new
> flow is added or taken away makes a lot more sense to me, and also really
> sucks if true.

"stateless ECMP rehash for all flows every time a new link (not flow)
is added or taken away" is *exactly* what I would expect (and want) to
happen. How do you expect ECMP to work in the presence of links added
or removed?

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
i've got 6 machines advertising the same /32 at the moment, and bgp is
typically quite stable in this setup.

sorry, i somehow misinterpreted (perhaps too hopefully) that the addition
or removal of _flows_ would potentially cause a rehash, not just the
addition or removal of a physical or logical path. back to the drawing
board i go.


On Sat, Aug 9, 2014 at 9:23 AM, Chris Woodfield <rekoil@semihuman.com>
wrote:

> I've learned that the EX platform only allows 8 equal-cost routes. How
> many proxies are in your setup?
>
> The behavior you're describing should only happen when one of the ECMP
> routes is either withdrawn or a new route is advertised.
>
> Followup question: is the flow-hashing algorithm on the EX platform a
> consistent hash (ring hash)? If so, only flows that were being mapped to
> the withdrawn route, or that would be hashed to the new route, would be
> affected. If it's not a consistent hash, then all flows would be re-mapped
> to new routes whenever there's a change in the available next-hops.
>
> -C
>
> On Aug 9, 2014, at 9:00 AM, ryanL <ryan.landry@gmail.com> wrote:
>
> oh man... this might be the answer to a long standing problem i've been
> having with the EX4500's at my core. they do BGP to a bunch of proxy
> machines (exabgp) that advertise the same /32 (as a VIP). once every so
> often (becoming more often as traffic grows), a TCP packet is forwarded by
> the EX to one of the machines which has no knowledge of the original flow.
> that machine of course sends back a RST and breaks the whole flow.
>
> i've done exhaustive packet captures for juniper on this, thinking that
> somehow the EX was actually duplicating a packet incorrectly out one
> interface. but this stateless ECMP rehash for all flows every time a new
> flow is added or taken away makes a lot more sense to me, and also really
> sucks if true.
>
> case 2014-0123-0781, if anyone at juniper is listening. that case is
> _still_ open.
>
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
yeah, see my follow up. got a little excited...


On Sat, Aug 9, 2014 at 9:34 AM, <sthaug@nethelp.no> wrote:

> > i've done exhaustive packet captures for juniper on this, thinking that
> > somehow the EX was actually duplicating a packet incorrectly out one
> > interface. but this stateless ECMP rehash for all flows every time a new
> > flow is added or taken away makes a lot more sense to me, and also really
> > sucks if true.
>
> "stateless ECMP rehash for all flows every time a new link (not flow)
> is added or taken away" is *exactly* what I would expect (and want) to
> happen. How do you expect ECMP to work in the presence of links added
> or removed?
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Verifying Juniper ECMP [ In reply to ]
hi ,
As per my knowledge, In present condition , Whenever you will remove
or add any link or logical link in Ex router , it will rehash again and
flow is always expected to move. They have not implementation of consistant
hashing in Ex-series. but in new releases of s/w for Mx series, they had
implemented consistant hashing feature. Where if one of link goes down
still other flow in other links will be impacted.
And regarding to flow, where exactly it is taking path, I have a suggestion
,
If you apply firewall filter for appropriate source address for counting
that, you can found out for where it it going.

Regards
Gaurav goel


On Sat, Aug 9, 2014 at 10:04 PM, ryanL <ryan.landry@gmail.com> wrote:

> yeah, see my follow up. got a little excited...
>
>
> On Sat, Aug 9, 2014 at 9:34 AM, <sthaug@nethelp.no> wrote:
>
> > > i've done exhaustive packet captures for juniper on this, thinking that
> > > somehow the EX was actually duplicating a packet incorrectly out one
> > > interface. but this stateless ECMP rehash for all flows every time a
> new
> > > flow is added or taken away makes a lot more sense to me, and also
> really
> > > sucks if true.
> >
> > "stateless ECMP rehash for all flows every time a new link (not flow)
> > is added or taken away" is *exactly* what I would expect (and want) to
> > happen. How do you expect ECMP to work in the presence of links added
> > or removed?
> >
> > Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp