Re: [j-nsp] 6VPE routes learned and hidden - ACX5048

Yep, that was it, thanks ! set routing-instances one routing-options auto-export family inet6 unicast set routing-instances three routing-options auto-export family inet6 unicast I had to do it in both vrf's. I tried it in one, and then the other, and route didn't show up... only when I did

Re: [j-nsp] MX104 capabilities question

Hi Saku, > I don't see how this makes it any less of a box, in my mind this makes > it superior box. You lost single PFE/linecard, which happens to be > only linecard you have. > In my mind fabricless single-linecard design is desirable, as it > reduces delay and costs significantly. Not only can

[j-nsp] Commit script portability between ELS and non-ELS platforms

Does anyone have any clever methods for probing Enhanced Layer 2 Software support from a commit script on QFX/EX in order to generate changes appropriate to the platform? Specifically looking for something beyond checking hardware and version numbers, or for pieces of config hierarchy that

Re: [j-nsp] 6VPE routes learned and hidden - ACX5048

So, you're trying to leak between local VRFs on the same ACX? With prefix 1234:5678:0:7::/64 originating in "three" and you want to leak locally into "one"? I know local leaking isn't possible on e.g. EX4550, but I don't know if that same limitation applies to the ACX. If you *are* able to

Re: [j-nsp] 6VPE routes learned and hidden - ACX5048

Next subtopic related to 6VPE in my ACX5048 please... this is done on one ACX5048... so both vrf "three" and "one" are on same ACX5048 PE i advertise a ipv6 prefix into a vrf named "three" with RT 1:1 and 3:3 i try to receive that same ipv6 prefix into a vrf named "one" with RT 1:1... it isn't

Re: [j-nsp] MX104 capabilities question

> So the next bump up (which is an investment no doubt) is the larger MX > series. The MX240 has two card slots available. Using 16x10G or 32x10G will > yield a nice port density. One school of thought is since the MX480 bare > chassis is not much more than that of the MX240, it makes more ROI

Re: [j-nsp] MX104 capabilities question

I thank everyone for their thoughts and comments, they do indeed jive with what I had already thought about the product. As long as the MX104 is capable of handling the 5 full table BGP peers (slow I understand) I think its worth rolling one as it has to be better them my Sup720CXL’s which

Re: [j-nsp] MX104 capabilities question

A lot of folks have responded to this so at the risk of belaboring the point, yes the MX104 is very slow to load the FIB or during a churn. But forwarding performance is solid! Port density is an issue. MX104 can hold up to 12 ports @10G and has no issues forming LAG's across each MIC or in

Re: [j-nsp] MX104 capabilities question

On 7 June 2016 at 17:43, Adam Vitkovsky wrote: > Alright but isn't running GRE tunnels over limited MTU with a need to > reassemble fragments rather special case? I mean those as separate datapoints.Typhoon will crap out at like 12Mpps of GRE, far cry from Trio. And

Re: [j-nsp] MX104 capabilities question

> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Tuesday, June 07, 2016 2:56 PM > To: Adam Vitkovsky > Cc: Ross Halliday; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] MX104 capabilities question > > On 7 June 2016 at 11:16, Adam Vitkovsky > wrote:¨ > > > These are

Re: [j-nsp] MX104 capabilities question

On 7 June 2016 at 11:16, Adam Vitkovsky wrote:¨ > These are all valid theoretical constrains. > Yet MX104/MX80 system capacity is 80Gbps and ASR9k1 is 120Gbps. Because ASR9k1 has 2 NPUs. > And as we all know if you shift from the ideal packet size and pure IP >

Re: [j-nsp] MX104 capabilities question

> Of Saku Ytti > Sent: Tuesday, June 07, 2016 7:02 AM > > On 7 June 2016 at 03:09, Ross Halliday > wrote: > > Hey, > > In my mind fabricless single-linecard design is desirable, as it reduces delay > and costs significantly. Not only can you omit fabric chip,

Re: [j-nsp] MX104 capabilities question

On 7 June 2016 at 03:09, Ross Halliday wrote: Hey, > The MX104 is a great value box, but lacks some features which make it a "big > boys" router. Aside from the RE, the control plane isn't as segregated as I > thought, leading to interesting bugs like