[j-nsp] What's the latest code you're running on a mx?

Tue May 25 13:55:31 EDT 2010

Hello,

I for one am happy to hear this. We're very close to deploying a new MPLS network all on MX960s. We did heavy testing on 10.0R2 earlier this year. Our lab gear has all been updated to 10.0R3 and so far everything seems to work. We're running:

-IGP: OSPF (1 area 0, no TED) with OSPF LFA
-L2VPN, VPLS, L3VPN with BGP signaling
-LDP for transport LSPs
-No RSVP
-Simple Core QoS model with edge BA pbit classifiers

Some interesting things to note:

-OSPF LFA: I had to open a case with JTAC on this. The "traceroute mpls ldp" command uses both the primary and backup LFA paths. JTAC thinks this is a problem with the traceroute command and not OSPF LFA. When I simulate traffic through the network, it does always appear to use the primary LFA path only. I wish I new their ECMP algorithm to know for sure...

-no-tunnel-services: I can consistently get the box to core dump by creating a VPLS Routing Instance without no-tunnel-services, adding no-tunnel-services and then doing a commit full. Case pending. Work around: using groups to make sure parameters like no-tunnel-services are always on first time around.

-l3vpn-composite: This is suppose to add efficiencies for L3VPN but it breaks VPLS & L2VPN. PR opened in 10.0R2. I don't think it's fixed yet.

-Egress PE custom MPLS exp Classifier is broke for VPLS & L3VPN. As a workaround, you have to apply your classifier like so:

show configuration class-of-service routing-instances 
all {
    classifiers {
        exp mpls-core-classifier;
    }
}

Otherwise the default MPLS exp classifier is used. 

-We wanted to put fxp0 in a dedicated Logical System to solve return route problems (some traffic is InBand, some is Out of Band via fxp0 - don't ask). This solves the routing problem but breaks NSR. 

Everything else seems to be working as expected. The problems listed above are somewhat minor and we can work around them. 10.0R3 did core dump a few times during a training session. We had 8 people all making config changes at the same time in the same "edit". JTAC is analyzing. It's the only item that's making me a bit nervous. I'm hoping to limit simultaneous access (edit exclusive) in Prod to limit this.

Does anyone else have anything to share? I'd certain like to know if there's anybody else beating up 10.0R3 in the lab or running it in Prod. If we have a similar setup, I'd even be willing to replicate a problem anyone else might be having. Ping me off list if necessary.

Thanks,
Serge

----- Original Message ----
From: David Ball <davidtball at gmail.com>
To: mtinka at globaltransit.net
Cc: Richard A Steenbergen <ras at e-gerbil.net>; juniper-nsp at puck.nether.net
Sent: Tue, May 25, 2010 12:58:06 PM
Subject: Re: [j-nsp] What's the latest code you're running on a mx?

  Just a followup on this thread.  I've been testing 10.0R3.10 in the
lab with MX240, 480 and T640 and have had (somewhat surprisingly) good
results.  L2VPN, L2ckt, BGP-signalled VPLS (all w/QoS), L3VPN, LDP &
RSVP w/FRR (haven't tested much TE yet, mind you), even dabbled in
loop-free alternates (on the MX240 only), and haven't hit any
show-stoppers *yet*.  We're definitely SP-focused, not enterprise, so
YMMV.  They've even fixed (?) the functionality which broke (?) around
late 9.2 to early 9.3 timeframe which prevented you from doing 802.1p
BA classification on an outer VLAN tag if you were removing the outer
tag on ingress (they added a flag somewhere where you can specify
'inner' if you need to).

  It's said to have several fixes for the now infamous KRT Queue
issues as well, which have been discussed at length on the list.  I'm
cautiously optimistic about that one.

  That said....everything works in the lab, right?

David

On 1 May 2010 12:57, Mark Tinka <mtinka at globaltransit.net> wrote:
> On Sunday 02 May 2010 01:31:44 am Richard A Steenbergen
> wrote:
>
>> Don't try to compare code between platforms, they're
>>  entirely different beasts. :) In my experience the
>>  answer for EX is almost always "run the latest and
>>  greatest", and our deployment tests w/EX8216s and 10.1S1
>>  have actually been much better than I expected.
>>
>> In the end it all comes down to which features are you
>>  using, and what expectations do you have from your
>>  router. Layer 2 is dirt simple, hell even Foundry
>>  managed to mostly get that one right, so I have no doubt
>>  that if your configuration and network are simple enough
>>  you'll probably never see an issue. Try running a full
>>  routing service provider config with bgp isis mpls rsvp
>>  l2circuits firewalls etc and it's completely different
>>  story. :)
>
> I probably should have stated that "any platform" was
> confined to the latter case you describe, service provider
> routing and friends.
>
> We've had luck running code on core and edge switches in
> pure Layer 2 mode that have brought other networks to tears
> when Layer 3 services are turned on. Code stability
> requirements between either paradigm is sufficiently
> distinguishable, most times :-).
>
> Even though the platforms have some key differences, I'd be
> just as cautious running JUNOS 10.x on the M320, T640, M10i,
> e.t.c., as much as I would on the MX. But I guess this goes
> without saying for many :-).
>
> Cheers,
>
> Mark.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp