Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
The ALU 7210 line is very similar to the 3600X and 920. 24x1G and 2x10G or 4x10G, support full MPLS, L2VPN, L3VPN, CES. I’ve posted about them before, we have thousands of them deployed in MPLS rings. They have a 2.5RU modular one now with 6 slots with 2x10G, 10x1G, and 1/10 combo modules. Its not all that impressive but will do 6x10G and 60x1G and has redundant control boards. I agree that Juniper never really pursued the market, the MX isn't a great fit and the ACX/BX are underwhelming. Phil From: Mark Tinka Sent: Wednesday, November 12, 2014 3:53 PM To: Eric Van Tol Cc: m...@xalto.net, juniper-nsp@puck.nether.net List On Wednesday, November 12, 2014 05:38:54 PM Eric Van Tol wrote: ME3600X is wonderful, but very expensive once you get the full feature set. Agree. We are waiting (rather impatiently at this point) for our first ASR920 to arrive to test out. This is supposed to be the replacement for the ME3400, but with MPLS. It fits us nicer than the ME3600X, as the footprint is much smaller and there are various models for port density. Interesting. I'm speaking with the SPAG BU on this platform, to see where it falls short of (or outperforms) the ME3600X/3800X. Odd - we tried to engage ALU and they said all their gear is layer-2 only. They were supposed to come to our office for a meet-and-greet, but never came. This is the second time we've tried to engage them with no success. Guess they are not interested in our business. ALU have some pretty good routers, actually. Their 7xxx series routers and switches are up there with the best. In fact, I find their subscriber management solutions to be quite interesting compared to Cisco and Juniper. I did some testing at their lab in Antwerp a few months ago, and was mighty impressed with some of the work they've done in mobile to wi-fi hand-off. Very good boxes and solutions, to be honest. It's just that in the metro, they still don't have anything close to the ME3600X (or ASR920). Agreed. ACX is just not there. It baffles me why Juniper has left this market untapped. The mid-range MX is just too expensive and too big for our deployments and the lack of LSR functionality in the EX won't work for us. Back when the MX80 was launching (c. 2009), I was speaking to the Juniper folk heading the project, and they promised a 1U MX80 with 20x or 40x Gig-E ports, and 2x or 4x 10Gbps uplinks, with all MX software features. How I still wish for such a box. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Verifying Juniper ECMP
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 masoodn...@gmail.com wrote: See inline, prefixed [Masood] ... On Thu, Apr 17, 2014 at 1:09 AM, John Neiberger jneiber...@gmail.comwrote: 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 jneiber...@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.bengh...@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 jneiber...@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: [j-nsp] Prepending customer AS results in AS23456
23456 was reserved as a compatibility ASN to sort of make things compatible
with 2-byte implementations. There is a lot of information on the interweb so
I wont go into detail here.
Phil
From: Markus
Sent: Wednesday, May 21, 2014 5:33 PM
To: juniper-nsp@puck.nether.net List
PS: On a second thought, of course as-path-prepend will make the session
get dropped by the remote router, because my AS is not first in the path
anymore. My mistake, so please ignore that.
I checked some more looking glasses in the meantime and I can see
my-upstream my-asn 22 at some of them. Only one looking glass showed
me my-upsteam my-asn 23456, so I'm thinking maybe everything is fine and
only this particular LG cannot display 4-byte ASN and uses 23456 instead?
Sorry for the noise in that case. :)
Am 21.05.2014 23:20, schrieb Markus:
Hi list!
I'm trying to prepend a customers 4-byte ASN to their prefixes. JunOS
12.3R2.5 on M7i. This is my config, simplified:
[routing-options static]
route a.a.a.a/22 {
next-hop b.b.b.b;
readvertise;
}
[policy-options]
policy-statement UPSTREAM-OUT {
term 1 {
from {
route-filter a.a.a.a/22 exact;
}
then {
as-path-expand 22;
}
}
UPSTREAM-OUT is applied as export to my upstream's BGP peer. So far so
good:
admin@router# run show route advertising-protocol bgp my-upstream-ip
Prefix Nexthop MED LclprefAS path
* a.a.a.a/22 Self 10 22 I
But when I check a public looking glass I can see that 22 becomes
23456:
3257 1299 my-upstream my-asn 23456
I changed as-path-expand to as-path-prepend and this resulted in the
BGP session to drop and I can see this in my log:
router rpd[1567]: bgp_read_v4_message:10289: NOTIFICATION received from
my-upstream-ip (External AS my-upstream): code 3 (Update Message Error)
subcode 11 (AS path attribute problem), Data: 40 02 0a 02 02 00
Does this maybe mean that my upstream routers software does not yet
support 4-byte ASNs?
I'm also doing the same to various peers and there it works fine. I can
see the path my-asn 22 in my peers looking glasses.
Thanks!
Markus
___
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
