[j-nsp] JunsOS event for PPPoE interface acquiring address

[Alex K. via juniper-nsp]

Hi everybody.

An interesting question came across my desk - a customer of mine, is using
JunOS event policy (SRX to be exact), to capture change in his WAN IP
address and then populate it, in banch of other hierarchies.

The later logic worked as expected, but due to recent change, he switched
ISP and after  we set up his new PPPoE dialer, we encountered the
following: the event-policy above, most of the time discovers pp0.0
interface IP address is either 0.0.0.0/0 or not-existing/empty.

After a short investigation, we identified the culprit: the event-policy
currently redponds to the snmp_trap_link_up event and sometimes, realy
sometimes, pp0.0 reaches up-up state, before an IP address was assigned.
"show interfaces terse" shows the interface state and it IP addresses,
exactly as above. So the event-policy it seems, does nothing wrong.

What's probably happening, is PPP Auth is complete (or some other state,
Juniper decided it enough to bring PPP interface into up-up state), while
IPCP isn't complete yet. Since the interface up, snmp_trap_link_up kicks in
and that's how we end up here.

Now, I don't think Juniper are in breach of something here (say, RFC). In
my humble opinion, I can see the logic in declaring a PPP interface up,
after say PPP Auth is complete, before IPCP (or another NCP, for that
matter) acquired address. Feel free correct me if I'm wrong. What I'm
"really" after: *is there an event corresponding to an interface acquiring
IP address?*

Cause, as I've said, I can see the distinction between interface state and
acquiring address (think of ethernet and DHCP) but than, how we're supposed
to capture that distinction in JunOS event policy?

Feel free to share you thoughts.

Thank you in advance,
Alex.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX VC once again

[Alex K.]

Hello everyone,

I've got interesting question lately, which I'll glad to know community
opinion about.

We were discussing MX VC design alternatives and I voiced a view, often
encountered here, that unless you're prepared to take the whole VC down,
you probably should look for an alternate design options. Since it's
logical to expect one being able to isolate a box from a VC, perform
whatever maintenance you planned and get the box back in row - that becomes
the question.  Surprisingly, I don't have any documentation to support you
could not. At least, for the procedures I've checked.

Hence, I'll glad to know is there any procedures/experience out there, that
ultimately states that you cannot do X, without talking the whole VC down.
Especially for practical reasons (documentation wise on such occasions, you
don't have to).

Thank you.
Alex.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anyone uses Adaptive Load Balancing?

[Alex K.]

Hello Michael,

Thank you for sharing your experience. It's really useful.

Alex.

בתאריך 20 בנוב' 2017 17:11,‏ "Michael Hare" <michael.h...@wisc.edu> כתב:

> Alex-
>
> I've used it AS wide in 14.1 for ~2+ years without observing any negative
> side effects.  My main driver was a connector's SAN replication MPLS
> service across an Nx10 bundle mixed with regular IP traffic with the SAN
> wanting to be one big flow.
>
> -Michael
>
> >>-Original Message-
> >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> >>Of Alex K.
> >>Sent: Saturday, November 18, 2017 1:09 AM
> >>To: serge vautour <sergervaut...@gmail.com>
> >>Cc: juniper-nsp <juniper-nsp@puck.nether.net>
> >>Subject: Re: [j-nsp] Anyone uses Adaptive Load Balancing?
> >>
> >>Hello Serge and thank you.
> >>
> >>Yes, there are indeed, not that many cases for ALB. That's why I turned
> to
> >>community.
> >>
> >>Thank you for sharing your experience.
> >>
> >>בתאריך 18 בנוב' 2017 1:41 AM,‏ "serge vautour"
> >><sergervaut...@gmail.com>
> >>כתב:
> >>
> >>> Hello,
> >>>
> >>> We have been using it for a while. Works great. We have a few small
> links
> >>> in a LAG bundle with a small number of fat flows over them. Without
> >>> adaptive LAG the flows would sometimes hash on the same link. With
> >>adaptive
> >>> LAG they are always split.
> >>>
> >>> I agree that there probably aren't many use cases for this. We ran into
> >>> one and this solution worked.
> >>>
> >>> Serge
> >>>
> >>>
> >>> On Fri, Nov 17, 2017 at 6:36 PM, Alex K. <nsp.li...@gmail.com> wrote:
> >>>
> >>>> Hello everyone,
> >>>>
> >>>> A customer of mine, is looking forward for a technology able to load
> >>>> balance a traffic across a LAG.
> >>>>
> >>>> The LAG in question comprised of Ethernet link and can grow from a few
> >>>> links (4) to say, 20 - as required bandwidth grows. The gear is MX
> boxes.
> >>>>
> >>>> Since I'm familiar with adaptive load balancing but never used it
> myself,
> >>>> I'll glad if someone here can share his/her experience using it? Can
> it
> >>>> deliver pretty good load balancing across a LAG between routers? Is it
> >>>> stable? Is there any caveats one should avoid? Anything else we should
> >>>> consider, before deploying this thing into production? Feel free to
> share
> >>>> (off list/on list) your experience and everything else you think
> relevant.
> >>>>
> >>>> Thank you.
> >>>> ___
> >>>> 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: [j-nsp] Anyone uses Adaptive Load Balancing?

[Alex K.]

Hello Daniel,

Thank you. My scenario close to yours, hence I glad to know this thing
really works.

Alex.

בתאריך 25 בנוב' 2017 9:36 AM,‏ "Daniel Rohan" <dro...@gmail.com> כתב:

Same.  Worked fine on 4x10Gb ring with large research flows.

On Mon, Nov 20, 2017 at 7:11 AM, Michael Hare <michael.h...@wisc.edu> wrote:

> Alex-
>
> I've used it AS wide in 14.1 for ~2+ years without observing any negative
> side effects.  My main driver was a connector's SAN replication MPLS
> service across an Nx10 bundle mixed with regular IP traffic with the SAN
> wanting to be one big flow.
>
> -Michael
>
> >>-Original Message-
> >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> >>Of Alex K.
> >>Sent: Saturday, November 18, 2017 1:09 AM
> >>To: serge vautour <sergervaut...@gmail.com>
> >>Cc: juniper-nsp <juniper-nsp@puck.nether.net>
> >>Subject: Re: [j-nsp] Anyone uses Adaptive Load Balancing?
> >>
> >>Hello Serge and thank you.
> >>
> >>Yes, there are indeed, not that many cases for ALB. That's why I turned
> to
> >>community.
> >>
> >>Thank you for sharing your experience.
> >>
> >>בתאריך 18 בנוב' 2017 1:41 AM,‏ "serge vautour"
> >><sergervaut...@gmail.com>
> >>כתב:
> >>
> >>> Hello,
> >>>
> >>> We have been using it for a while. Works great. We have a few small
> links
> >>> in a LAG bundle with a small number of fat flows over them. Without
> >>> adaptive LAG the flows would sometimes hash on the same link. With
> >>adaptive
> >>> LAG they are always split.
> >>>
> >>> I agree that there probably aren't many use cases for this. We ran into
> >>> one and this solution worked.
> >>>
> >>> Serge
> >>>
> >>>
> >>> On Fri, Nov 17, 2017 at 6:36 PM, Alex K. <nsp.li...@gmail.com> wrote:
> >>>
> >>>> Hello everyone,
> >>>>
> >>>> A customer of mine, is looking forward for a technology able to load
> >>>> balance a traffic across a LAG.
> >>>>
> >>>> The LAG in question comprised of Ethernet link and can grow from a few
> >>>> links (4) to say, 20 - as required bandwidth grows. The gear is MX
> boxes.
> >>>>
> >>>> Since I'm familiar with adaptive load balancing but never used it
> myself,
> >>>> I'll glad if someone here can share his/her experience using it? Can
> it
> >>>> deliver pretty good load balancing across a LAG between routers? Is it
> >>>> stable? Is there any caveats one should avoid? Anything else we should
> >>>> consider, before deploying this thing into production? Feel free to
> share
> >>>> (off list/on list) your experience and everything else you think
> relevant.
> >>>>
> >>>> Thank you.
> >>>> ___
> >>>> 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: [j-nsp] Anyone uses Adaptive Load Balancing?

[Alex K.]

Hello Serge and thank you.

Yes, there are indeed, not that many cases for ALB. That's why I turned to
community.

Thank you for sharing your experience.

בתאריך 18 בנוב' 2017 1:41 AM,‏ "serge vautour" <sergervaut...@gmail.com>
כתב:

> Hello,
>
> We have been using it for a while. Works great. We have a few small links
> in a LAG bundle with a small number of fat flows over them. Without
> adaptive LAG the flows would sometimes hash on the same link. With adaptive
> LAG they are always split.
>
> I agree that there probably aren't many use cases for this. We ran into
> one and this solution worked.
>
> Serge
>
>
> On Fri, Nov 17, 2017 at 6:36 PM, Alex K. <nsp.li...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> A customer of mine, is looking forward for a technology able to load
>> balance a traffic across a LAG.
>>
>> The LAG in question comprised of Ethernet link and can grow from a few
>> links (4) to say, 20 - as required bandwidth grows. The gear is MX boxes.
>>
>> Since I'm familiar with adaptive load balancing but never used it myself,
>> I'll glad if someone here can share his/her experience using it? Can it
>> deliver pretty good load balancing across a LAG between routers? Is it
>> stable? Is there any caveats one should avoid? Anything else we should
>> consider, before deploying this thing into production? Feel free to share
>> (off list/on list) your experience and everything else you think relevant.
>>
>> Thank you.
>> ___
>> 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] MACsec over a service provider

[Alex K.]

Sure.

But it depends on the exact circuit you have (on the exact equipment and
settings your carrier uses). Since MACSec is true point-to-point protocol,
carriers' equipment may interpret its' packets (say EAPOL), as destined for
itself - instead of forwarding it thru the pseudo wire.

As far as I remember the deployment, most of the circuits were fine with
regular (i.e. LAN) MACSec. But some required the WAN flavor. Hence wouldn't
have worked with J-gear. Anyhow, I glad you were able to sort it out.

Best regards,
Alex.

בתאריך 18 בנוב' 2017 1:43 AM,‏ "Chuck Anderson" <c...@wpi.edu> כתב:

In the end I discovered that CCC, l2circuit, etc. work fine for
transporting regular MACsec, no need for "WAN MACsec" or special
commands to forward dot1x frames.

I also got this to work with 2 links at the same time between the same
2 switches.  The problem I was having was related to using 1g SFP's in
EX-UM-4X4SFP in the EX4300-48P.  You have to turn off auto-neg and
force the speed to 1g.  You also have to restart the PIC or reboot
after changing an optic from 10gig to 1gig or vice versa.

On Fri, Nov 17, 2017 at 11:25:23PM +, Alex K. wrote:
> * As long as you have pure p2p links, you should be fine - Juniper gear
> meant.
>
> בתאריך 18 בנוב' 2017 1:20 AM,‏ "Alex K." <nsp.li...@gmail.com> כתב:
>
> > Yes,
> >
> > But unfortunately (as far as j-nsp is considered), using Ciscos' gear.
> >
> > Cisco has a special flavor of MACSec, intended to address that issue
> > exactly - they call it WAN MACSes. We was able to use across many
different
> > SP circuits. As long as you have pure p2p links (real or stimulated),
you
> > should be fine. Unfortunately, I'm not aware of any similar Juniper
> > technique.
> >
> > Best regards,
> > Alex.
> >
> > בתאריך 27 באוק' 2017 5:23 PM,‏ "Chuck Anderson" <c...@wpi.edu> כתב:
> >
> > Has anyone been able to run MACsec over a service provider's Ethernet
> > Private Line (or even just a 802.1q vlan)?  I'm looking at using 10gig
> > ports on the EX4300 or the EX4600/QFX5100-24Q with the MACsec uplink
> > module.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anyone uses Adaptive Load Balancing?

[Alex K.]

Hello Giuliano and thank you.

It would be MPLS traffic and Juniper facing Juniper.

בתאריך 18 בנוב' 2017 1:08 AM,‏ "Giuliano C. Medalha" <giuli...@wztech.com.br>
כתב:

> Alex
>
> What type of traffic ?
>
> MX is very good for load balance because of TRIO chipset ... that is able
> to strip down the frames and the packets ... necessary for the hash of LAG
> circuits
>
> Is IP traffic or MPLS traffic ?
>
> Maybe on new boxes like mx10003 and mx204 you can create high capacity LAG
> links using 100G qsfp28 interfaces.
>
> We are using it in a lot os cases ... is very stable ... but is necessary
> to do a deep study fot the correct number of interfaces, config, hash, mpc
> (hw), and junos version that you can find with your SM.
>
> Will be juniper with juniper or other brand ?
>
> Att
>
> Giuliano C. Medalha
> WZTECH NETWORKS
> +55 (17) 98112-5394 <+55%2017%2098112-5394>
> giuli...@wztech.com.br
> _
> From: Alex K. <nsp.li...@gmail.com>
> Sent: Friday, November 17, 2017 20:37
> Subject: [j-nsp] Anyone uses Adaptive Load Balancing?
> To: juniper-nsp <juniper-nsp@puck.nether.net>
>
>
> Hello everyone,
>
> A customer of mine, is looking forward for a technology able to load
> balance a traffic across a LAG.
>
> The LAG in question comprised of Ethernet link and can grow from a few
> links (4) to say, 20 - as required bandwidth grows. The gear is MX boxes.
>
> Since I'm familiar with adaptive load balancing but never used it myself,
> I'll glad if someone here can share his/her experience using it? Can it
> deliver pretty good load balancing across a LAG between routers? Is it
> stable? Is there any caveats one should avoid? Anything else we should
> consider, before deploying this thing into production? Feel free to share
> (off list/on list) your experience and everything else you think relevant.
>
> Thank you.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> WZTECH is registered trademark of WZTECH NETWORKS.
> Copyright © 2017 WZTECH NETWORKS. All Rights Reserved.
>
> IMPORTANTE:
> As informações deste e-mail e o conteúdo dos eventuais documentos anexos
> são confidenciais e para conhecimento exclusivo do destinatário. Se o
> leitor desta mensagem não for o seu destinatário, fica desde já notificado
> de que não poderá divulgar, distribuir ou, sob qualquer forma, dar
> conhecimento a terceiros das informações e do conteúdo dos documentos
> anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo
> este e-mail ou telefonando ao mesmo, e em seguida apague-o.
>
> CONFIDENTIALITY NOTICE:
> The information transmitted in this email message and any attachments are
> solely for the intended recipient and may contain confidential or
> privileged information. If you are not the intended recipient, any review,
> transmission, dissemination or other use of this information is prohibited.
> If you have received this communication in error, please notify the sender
> immediately and delete the material from any computer, including any copies.
>
>
>
> WZTECH is registered trademark of WZTECH NETWORKS.
> Copyright © 2017 WZTECH NETWORKS. All Rights Reserved.
>
>
> IMPORTANTE:
> As informações deste e-mail e o conteúdo dos eventuais documentos anexos
> são confidenciais e para conhecimento exclusivo do destinatário. Se o
> leitor desta mensagem não for o seu destinatário, fica desde já notificado
> de que não poderá divulgar, distribuir ou, sob qualquer forma, dar
> conhecimento a terceiros das informações e do conteúdo dos documentos
> anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo
> este e-mail ou telefonando ao mesmo, e em seguida apague-o.
>
>
> CONFIDENTIALITY NOTICE:
> The information transmitted in this email message and any attachments are
> solely for the intended recipient and may contain confidential or
> privileged information. If you are not the intended recipient, any review,
> transmission, dissemination or other use of this information is prohibited.
> If you have received this communication in error, please notify the sender
> immediately and delete the material from any computer, including any copies.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MACsec over a service provider

[Alex K.]

* As long as you have pure p2p links, you should be fine - Juniper gear
meant.

בתאריך 18 בנוב' 2017 1:20 AM,‏ "Alex K." <nsp.li...@gmail.com> כתב:

> Yes,
>
> But unfortunately (as far as j-nsp is considered), using Ciscos' gear.
>
> Cisco has a special flavor of MACSec, intended to address that issue
> exactly - they call it WAN MACSes. We was able to use across many different
> SP circuits. As long as you have pure p2p links (real or stimulated), you
> should be fine. Unfortunately, I'm not aware of any similar Juniper
> technique.
>
> Best regards,
> Alex.
>
> בתאריך 27 באוק' 2017 5:23 PM,‏ "Chuck Anderson" <c...@wpi.edu> כתב:
>
> Has anyone been able to run MACsec over a service provider's Ethernet
> Private Line (or even just a 802.1q vlan)?  I'm looking at using 10gig
> ports on the EX4300 or the EX4600/QFX5100-24Q with the MACsec uplink
> module.
> ___
> 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] MACsec over a service provider

[Alex K.]

Yes,

But unfortunately (as far as j-nsp is considered), using Ciscos' gear.

Cisco has a special flavor of MACSec, intended to address that issue
exactly - they call it WAN MACSes. We was able to use across many different
SP circuits. As long as you have pure p2p links (real or stimulated), you
should be fine. Unfortunately, I'm not aware of any similar Juniper
technique.

Best regards,
Alex.

בתאריך 27 באוק' 2017 5:23 PM,‏ "Chuck Anderson"  כתב:

Has anyone been able to run MACsec over a service provider's Ethernet
Private Line (or even just a 802.1q vlan)?  I'm looking at using 10gig
ports on the EX4300 or the EX4600/QFX5100-24Q with the MACsec uplink
module.
___
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

[j-nsp] Anyone uses Adaptive Load Balancing?

[Alex K.]

Hello everyone,

A customer of mine, is looking forward for a technology able to load
balance a traffic across a LAG.

The LAG in question comprised of Ethernet link and can grow from a few
links (4) to say, 20 - as required bandwidth grows. The gear is MX boxes.

Since I'm familiar with adaptive load balancing but never used it myself,
I'll glad if someone here can share his/her experience using it? Can it
deliver pretty good load balancing across a LAG between routers? Is it
stable? Is there any caveats one should avoid? Anything else we should
consider, before deploying this thing into production? Feel free to share
(off list/on list) your experience and everything else you think relevant.

Thank you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[Alex K.]

*Chris*

בתאריך 28 בנוב' 2016 10:08 PM,‏ "Alex K." <nsp.li...@gmail.com> כתב:

> Thank you Tim,
>
> But it's not as easy. There seems to be no easy explanation, hence I'm
> interested in a trace option that will shed a little bit more light, on how
> EX process the packet.
>
> בתאריך 28 בנוב' 2016 9:53 PM,‏ "Chris Morrow" <morr...@ops-netman.net>
> כתב:
>
>> At Mon, 28 Nov 2016 19:17:41 +,
>> "Alex K." <nsp.li...@gmail.com> wrote:
>> >
>> > Thank you Tim and Chris,
>> >
>> > But correct me if I'm wrong - those are not quite the same thing.
>> >
>> > There's no doubt packets are reaching the box (I have PC connected
>> directly
>> > to the switch).
>> >
>> > The difference between traffic monitoring/mirroring and Ciscos' debug,
>> is
>> > that with debug you follow the path a packet takes.
>> >
>> > Traffic monitoring can be a really helpful first step (as I've said,
>> there
>> > virtually no doubt the packets are reaching the RE), but my question is
>> > about - what's next?
>> >
>> > Assumed you see only echo requsts and no replies (by "monitor traffic",
>> for
>> > example), is there is a trace option to show why an EX decided it
>> shouldn't
>> > answer with reply (from its own address)?
>>
>> honestly it's not that hard to tell what went wrong:
>>   1) route back to the source is broken/unknown
>>   b) loopback filter dropped inbound packet
>>   z) ... that's it.
>>
>> or that's been my experience.
>>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[Alex K.]

Thank you Tim,

But it's not as easy. There seems to be no easy explanation, hence I'm
interested in a trace option that will shed a little bit more light, on how
EX process the packet.

בתאריך 28 בנוב' 2016 9:53 PM,‏ "Chris Morrow" <morr...@ops-netman.net> כתב:

> At Mon, 28 Nov 2016 19:17:41 +,
> "Alex K." <nsp.li...@gmail.com> wrote:
> >
> > Thank you Tim and Chris,
> >
> > But correct me if I'm wrong - those are not quite the same thing.
> >
> > There's no doubt packets are reaching the box (I have PC connected
> directly
> > to the switch).
> >
> > The difference between traffic monitoring/mirroring and Ciscos' debug, is
> > that with debug you follow the path a packet takes.
> >
> > Traffic monitoring can be a really helpful first step (as I've said,
> there
> > virtually no doubt the packets are reaching the RE), but my question is
> > about - what's next?
> >
> > Assumed you see only echo requsts and no replies (by "monitor traffic",
> for
> > example), is there is a trace option to show why an EX decided it
> shouldn't
> > answer with reply (from its own address)?
>
> honestly it's not that hard to tell what went wrong:
>   1) route back to the source is broken/unknown
>   b) loopback filter dropped inbound packet
>   z) ... that's it.
>
> or that's been my experience.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[Alex K.]

Thank you Tim and Chris,

But correct me if I'm wrong - those are not quite the same thing.

There's no doubt packets are reaching the box (I have PC connected directly
to the switch).

The difference between traffic monitoring/mirroring and Ciscos' debug, is
that with debug you follow the path a packet takes.

Traffic monitoring can be a really helpful first step (as I've said, there
virtually no doubt the packets are reaching the RE), but my question is
about - what's next?

Assumed you see only echo requsts and no replies (by "monitor traffic", for
example), is there is a trace option to show why an EX decided it shouldn't
answer with reply (from its own address)?

בתאריך 28 בנוב' 2016 8:45 PM,‏ "Tim Jackson" <jackson@gmail.com> כתב:

> monitor traffic interface ge-0/0/0 size  no-resolve layer2-headers
> extensive
>
> --
> Tim
>
> On Mon, Nov 28, 2016 at 12:43 PM, Alex K. <nsp.li...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> By any chance - is there an equivalent for Ciscos' "debug ip packet"
>> command in Juniper?
>>
>> I'm fully aware that there is a complete distinction between forwarding
>> layer and control layer, in those devices - But,  I'm taking specifically
>> about traffic TARGETING the box itself.
>>
>> I'm troubleshooting a strange behavior by Juniper EX line. It's a compex
>> topology but the issue is very simple: under certain circumstances, an EX
>> stop responding even to pings to its own addresses, even from directly
>> connected interfaces.
>>
>> I'm fully aware that I can mirror a port on those machines (and such), but
>> mirroring alone, will not answer the million dollar question - why?
>>
>> Since there is no doubt that packets are reaching the box (packets don't
>> leak from a directly connected cable, with PC on its other end) - I was
>> hoping, Juniper might have provided us with a trace option, for following
>> the packet inside the box?
>>
>> Anyone know such trace option?
>>
>>
>> Any suggestions will be welcomed.
>> ___
>> 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

[j-nsp] Debug ip packet equivalent for directed at RE traffic

[Alex K.]

Hello everyone,

By any chance - is there an equivalent for Ciscos' "debug ip packet"
command in Juniper?

I'm fully aware that there is a complete distinction between forwarding
layer and control layer, in those devices - But,  I'm taking specifically
about traffic TARGETING the box itself.

I'm troubleshooting a strange behavior by Juniper EX line. It's a compex
topology but the issue is very simple: under certain circumstances, an EX
stop responding even to pings to its own addresses, even from directly
connected interfaces.

I'm fully aware that I can mirror a port on those machines (and such), but
mirroring alone, will not answer the million dollar question - why?

Since there is no doubt that packets are reaching the box (packets don't
leak from a directly connected cable, with PC on its other end) - I was
hoping, Juniper might have provided us with a trace option, for following
the packet inside the box?

Anyone know such trace option?


Any suggestions will be welcomed.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Encrypted MPLS between MXes

[Alex K.]

Yes, sounds great.

But as far as Juniper documentation is concerned, MIC-3D-20GE-SFP-E only
supports MACSec.

Am I missing something?
בתאריך 27 במרץ 2016 21:32,‏ "Tim Jackson"  כתב:

> That's good news to hear.. Today EX4600 was my solution, and it actually
> works quite well.
>
> On Sun, Mar 27, 2016, 1:27 PM Saku Ytti  wrote:
>
>> On 27 March 2016 at 21:12, Tim Jackson  wrote:
>> > Run EX4600s as your P routers, and encrypt w/ MACSec on them.
>>
>> IIRC next-gen Trio does MacSec, so all ports will support it.
>>
>> --
>>   ++ytti
>>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Encrypted MPLS between MXes

[Alex K.]

Hello everyone,

I was just wondering if there's a new way to encrypt MPLS traffic between
MX boxes without the good old encrypted GRE?

MPLS over encrypted MACSec links, encrypted internal tunnels between
logical systems, everything goes. If that was your network, what's the
craziest idea you'd go with?

Is at 2016, we're still stuck with MPLS over GRE over IPSec, to encrypt
MPLS traffic?

Feel free to share your thoughts.

Thank you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPC4D-32*GE Major Alarms

[Alex K.]

Hello Timur,

Thank you.

Unfortunately, we ran those test to no avail. Since all the MX says is
"major alarms at fpc x", it is seems that document intended for those
specific errors it covers.

I really wish Juniper will correct that message and put a proper
documentation in place. Owning such powerful box, usually at important
junctions of your network, with such amateur messages as troubleshooting
triggers, sometimes seems to me as owning a Porsche with controls taken
from Ford model T.

Definitely not good starting point when the time comes for deciding on new
boxes for your network.
בתאריך 17 בפבר' 2016 17:12,‏ "Timur Maryin" <timamar...@mail.ru> כתב:

> Hi Alex,
>
> Maybe this
> http://kb.juniper.net/KB23173 ?
>
>
> On 16-Feb-16 10:31, Alex K. wrote:
>
> As for the documentation, let begin with some knowledge base article
>> outlining initial steps for alarms troubleshooting steps for MX. I'd like
>> to read that one, to begin with.
>>
>>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPC4D-32*GE Major Alarms

[Alex K.]

Hello Steven,

Thank you for answering.

To begin with, we already replaced the MPC. The alarm still get raised at
random intervals. Besides the alarm, there's no preceding or trailing
errors. There's another MX960 configured exactly alike, dealing with the
2nd half of our end users, which never had such errors. The alarm however,
seems to cut the cumulative traffic passing through that MPC by half.
Traffic levels are restored be restarting that MPC. So I seriously doubt
that's a s/w issue.

As I said, I neither against nor for,  adding another case for JTAC to deal
with. Obviously, there might be something new and complicated going on out
there.

As for the documentation, let begin with some knowledge base article
outlining initial steps for alarms troubleshooting steps for MX. I'd like
to read that one, to begin with.

Thank you.
On 16 Feb 2016 10:15 a.m., "Steven Wong" <sw...@juniper.net> wrote:

> Hi Alex,
>
> When there is an alarm raised on the FPC, there must be an issue. If the
> issue is an obvious one, for example, sensor failure, you can always see
> that from the messages log and that should be good enough to determine if
> the board should be replaced or not. Unfortunately, there are some non
> obvious cases. Taking the MX as an example, we do have some monitor logic
> in the box to monitor different parts of the FPC. If something goes wrong,
> for example, an ASIC status doesn’t look good, we will raise an alarm to
> alert the customer as that might have impact on the traffic. However, there
> is no way for us to tell the customer what to do as the “abnormal state” is
> just a result of something bad - either sw bug or a hw failure. That’s why
> we need to get a case opened for JTAC to analyze what’s wrong. If you
> replace the board, most of the time, you can fix the problem for sure.
> However, as you could expect, if the issue was indeed caused by a sw bug,
> it might just come again. That’s why Diogo suggested a JTAC case to check
> that up.
>
> If you see that our document is not good enough to tell what to do when we
> see an alarm. Please do point it out and let us know. We will try to
> improve that.
>
> Thanks,
> Steven
>
>
>
> On 16/2/16 15:59, "juniper-nsp on behalf of Alex K." <
> juniper-nsp-boun...@puck.nether.net on behalf of nsp.li...@gmail.com>
> wrote:
>
> >Hello Diogo,
> >
> >Thank you for answering. Unfortunately, in my humble opinion, Juniper has
> >no clear procedure for us to follow.
> >
> >The cumulative effect of all the test we ran and those you and others
> >courteously pointed out, is basically none. This in my opinion, due the
> the
> >very fact that Juniper has no clear procedure published, to deal with
> those
> >kind of errors. Yes, there are some procedures out there for dealing with
> >clearly defined hardware errors but those are few. Recently, I was dealing
> >with some hardware related issues on some Cisco gear and I can clearly see
> >now the plenty of documented hardware show commands and such on Ciscos'
> >side and the lack of such for Juniper.
> >
> >I maybe wrong, but that sees to me as like Juniper would like me to add a
> >case for their JTAC pile, for every issue. Nevermind the fact that we all
> >have replacement stock available and could replace every part by
> ourselves,
> >given we have a way to recognize the faulty part.
> >
> >I have nothing for or against opening a case with JTAC, besides it's
> proven
> >to be a relic of the past. Many other vendors recognized a long time ago,
> >there's professional force out there and it works quite well. In fact, I
> >can hardly remember a case I was forced to open with Cisco, since I wasn't
> >sure what hardware part need replacement. And this given that we have much
> >more Cisco gear.
> >
> >Anyhow, I'll welcome any additional ideas from everyone.
> >
> >Thank you.
> >On 14 Feb 2016 11:04 a.m., "Diogo Montagner" <diogo.montag...@gmail.com>
> >wrote:
> >
> >> That should give you some indication of which subsystem is having
> problem.
> >>
> >> Also, check if there are no core-dumps generated fornthe FPC.
> >>
> >> Without additional information will be very hard to pinpoint where to
> look.
> >>
> >> On Sunday, 14 February 2016, Alex K. <nsp.li...@gmail.com> wrote:
> >>
> >>> Hello Diogo,
> >>>
> >>> I'm currently not on site, so I'll definitely try it when I'll get
> there.
> >>> Now I'm considering a plan of actions. What should I look for in that
> >>> command?
> >>>
> >>> T

Re: [j-nsp] MPC4D-32*GE Major Alarms

[Alex K.]

Hello Diogo,

Thank you for answering. Unfortunately, in my humble opinion, Juniper has
no clear procedure for us to follow.

The cumulative effect of all the test we ran and those you and others
courteously pointed out, is basically none. This in my opinion, due the the
very fact that Juniper has no clear procedure published, to deal with those
kind of errors. Yes, there are some procedures out there for dealing with
clearly defined hardware errors but those are few. Recently, I was dealing
with some hardware related issues on some Cisco gear and I can clearly see
now the plenty of documented hardware show commands and such on Ciscos'
side and the lack of such for Juniper.

I maybe wrong, but that sees to me as like Juniper would like me to add a
case for their JTAC pile, for every issue. Nevermind the fact that we all
have replacement stock available and could replace every part by ourselves,
given we have a way to recognize the faulty part.

I have nothing for or against opening a case with JTAC, besides it's proven
to be a relic of the past. Many other vendors recognized a long time ago,
there's professional force out there and it works quite well. In fact, I
can hardly remember a case I was forced to open with Cisco, since I wasn't
sure what hardware part need replacement. And this given that we have much
more Cisco gear.

Anyhow, I'll welcome any additional ideas from everyone.

Thank you.
On 14 Feb 2016 11:04 a.m., "Diogo Montagner" <diogo.montag...@gmail.com>
wrote:

> That should give you some indication of which subsystem is having problem.
>
> Also, check if there are no core-dumps generated fornthe FPC.
>
> Without additional information will be very hard to pinpoint where to look.
>
> On Sunday, 14 February 2016, Alex K. <nsp.li...@gmail.com> wrote:
>
>> Hello Diogo,
>>
>> I'm currently not on site, so I'll definitely try it when I'll get there.
>> Now I'm considering a plan of actions. What should I look for in that
>> command?
>>
>> Thank you.
>> On 14 Feb 2016 10:00, "Diogo Montagner" <diogo.montag...@gmail.com>
>> wrote:
>>
>>> Alex,
>>>
>>> What do you see in the show nvram at the FPC shell ?
>>>
>>> Do you have a case open with JTAC ?
>>>
>>> Thanks
>>>
>>> On Sunday, 14 February 2016, Alex K. <nsp.li...@gmail.com> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> For some time now, one of my customers are getting "major alarms" from
>>>> the
>>>> MPC mentioned above on one of their MX960s.
>>>>
>>>> The issue is that nothing more than that message (+alarm) seems to be
>>>> present. Nothing preceding that error, neither in "log messages" nor in
>>>> "chassisd". There seems to be output rate drop, at the time of those
>>>> incidents till the MPC get restarted (by the appropriate network team)
>>>> and
>>>> than everything gets back to normal.
>>>>
>>>> It's worth mentioning that they have a second MX960 serving the other
>>>> half
>>>> of their end-users, but configured exactly the same - which never had
>>>> that
>>>> issue (therefore it's probably not traffic related).
>>>>
>>>> They are running 12.3R6.6. The linecard was already replaced. There is
>>>> seems to be no trace options available for monitoring MPCs and their
>>>> internal status and Juniper web site lacks potential explanations and
>>>> leads, therefore I'm addressing the community -  any advice for getting
>>>> to
>>>> the bottom of this, will be welcomed! Additionally, any experience with
>>>> troubleshooting similar hardware issues might be as helpful as any
>>>> advice.
>>>>
>>>> Thank you.
>>>> ___
>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>
>>>
>>> --
>>> ./diogo -montagner
>>> JNCIE-SP 0x41A
>>>
>>
>
> --
> ./diogo -montagner
> JNCIE-SP 0x41A
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPC4D-32*GE Major Alarms

[Alex K.]

Hello Diogo,

I'm currently not on site, so I'll definitely try it when I'll get there.
Now I'm considering a plan of actions. What should I look for in that
command?

Thank you.
On 14 Feb 2016 10:00, "Diogo Montagner" <diogo.montag...@gmail.com> wrote:

> Alex,
>
> What do you see in the show nvram at the FPC shell ?
>
> Do you have a case open with JTAC ?
>
> Thanks
>
> On Sunday, 14 February 2016, Alex K. <nsp.li...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> For some time now, one of my customers are getting "major alarms" from the
>> MPC mentioned above on one of their MX960s.
>>
>> The issue is that nothing more than that message (+alarm) seems to be
>> present. Nothing preceding that error, neither in "log messages" nor in
>> "chassisd". There seems to be output rate drop, at the time of those
>> incidents till the MPC get restarted (by the appropriate network team) and
>> than everything gets back to normal.
>>
>> It's worth mentioning that they have a second MX960 serving the other half
>> of their end-users, but configured exactly the same - which never had that
>> issue (therefore it's probably not traffic related).
>>
>> They are running 12.3R6.6. The linecard was already replaced. There is
>> seems to be no trace options available for monitoring MPCs and their
>> internal status and Juniper web site lacks potential explanations and
>> leads, therefore I'm addressing the community -  any advice for getting to
>> the bottom of this, will be welcomed! Additionally, any experience with
>> troubleshooting similar hardware issues might be as helpful as any advice.
>>
>> Thank you.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
> --
> ./diogo -montagner
> JNCIE-SP 0x41A
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPC4D-32*GE Major Alarms

[Alex K.]

Hello Masood,

This problem probably isn't transient, since the output rate from that
linecard is cut in half (and restored after MPC get restarted).

I was thinking in the direction you mentioned but CRC errors at the fabric
should be indeed, transient in nature but they're "seem to persist" till
MPC restart. And if I recall correctly, no PFE related errors were present
(maybe I was trying other show commands, you are welcomed to point out the
ones you thought of).

Thank you.
On 14 Feb 2016 10:08 a.m., "Masood Ahmad Shah" <masoodn...@gmail.com> wrote:

> Some of the alarms are transient (should generate Syslog trap though), and
> they generate a Chassis alarm upon occurrence (i.e. PFE<>Fabric plane took
> a hit of CRC errors and then got recovered through fabric healing).
> Sometimes Chassis does not clear alarm when the transient state gets
> cleared and that requires a reboot treatment to the RE (yeah Routing engine
> :)
>
> I think chassisd (a daemon) not getting signaled from the relevant other
> processes when the states get cleared.
>
> On Sun, Feb 14, 2016 at 6:39 PM, Alex K. <nsp.li...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> For some time now, one of my customers are getting "major alarms" from the
>> MPC mentioned above on one of their MX960s.
>>
>> The issue is that nothing more than that message (+alarm) seems to be
>> present. Nothing preceding that error, neither in "log messages" nor in
>> "chassisd". There seems to be output rate drop, at the time of those
>> incidents till the MPC get restarted (by the appropriate network team) and
>> than everything gets back to normal.
>>
>> It's worth mentioning that they have a second MX960 serving the other half
>> of their end-users, but configured exactly the same - which never had that
>> issue (therefore it's probably not traffic related).
>>
>> They are running 12.3R6.6. The linecard was already replaced. There is
>> seems to be no trace options available for monitoring MPCs and their
>> internal status and Juniper web site lacks potential explanations and
>> leads, therefore I'm addressing the community -  any advice for getting to
>> the bottom of this, will be welcomed! Additionally, any experience with
>> troubleshooting similar hardware issues might be as helpful as any advice.
>>
>> Thank you.
>> ___
>> 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

[j-nsp] MPC4D-32*GE Major Alarms

[Alex K.]

Hello everyone,

For some time now, one of my customers are getting "major alarms" from the
MPC mentioned above on one of their MX960s.

The issue is that nothing more than that message (+alarm) seems to be
present. Nothing preceding that error, neither in "log messages" nor in
"chassisd". There seems to be output rate drop, at the time of those
incidents till the MPC get restarted (by the appropriate network team) and
than everything gets back to normal.

It's worth mentioning that they have a second MX960 serving the other half
of their end-users, but configured exactly the same - which never had that
issue (therefore it's probably not traffic related).

They are running 12.3R6.6. The linecard was already replaced. There is
seems to be no trace options available for monitoring MPCs and their
internal status and Juniper web site lacks potential explanations and
leads, therefore I'm addressing the community -  any advice for getting to
the bottom of this, will be welcomed! Additionally, any experience with
troubleshooting similar hardware issues might be as helpful as any advice.

Thank you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX240 for route-reflector?

[Alex K.]

Hello all,

One of my colleagues suggested using SRX240 us a route-reflector in our
network.

Since I've never seen SRX in such deployment, I'll be glad to know your
opinion on that.

The requirements are - MPLS VPN, L2VPN support (both VPLS and Pseudo wires)
and multicast VRFs support. It is worth mentioning, the network comprised
of both Cisco and Juniper gear.

Every thought on the subject will be welcomed.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp