Re: [j-nsp] MX80 upgrade path 18.4R

[Brian Johnson]

I agree with Tobias. If the unit is in production, expect some interruption in 
services as this type of install is the most disruptive, but should be doable 
within a maintenance window.

- Brian

> On Jun 14, 2020, at 4:59 AM, Tobias Heister  wrote:
> 
> Hi,
> 
> On 14.06.2020 10:50, Robert Hass wrote:
>> I have old MX80 running 10.4R14.2.
>> I would like to upgrade it to 18.4R.
>> But what upgrade I should use ?
>> 10.4R -> 15.1R and to 18.4R ?
> 
> There are probably official upgrade pathes taking a dozen intermediate steps 
> (three LTS releases at a time or something like that is officially supported, 
> and starting from $some version in the 16/17 all releases are considered 
> LTS). As The MX80 takes ages to do just one upgrade this would take days. 
> Also it could be quite hard to actually get intermediate releases for the 
> older steps (JTAC typically has them on request)
> 
> I would suggest to backup the config do a usb reinstall to the target release 
> and reapply the config.
> 
> -- 
> regards
> Tobias
> ___
> 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] Rate selectability on MPC7E-MRATE

[Brian Johnson]

Still… All of my points are valid.

- Brian


> On May 6, 2020, at 1:48 PM, Joe Horton  wrote:
> 
> Brian,
> 
> I'm not sure who you team is, but the other guys are correct.  You can 
> provision the addition ports using port mode.
> Just enabling the 100G ports does not disable the use of the additional 40G.  
> Been there done that, fully supported.
> If you've got something specific from your team or JTAC otherwise, and don't 
> feel right sharing it on the forum, feel free to reach out directly.
> 
> Joe
> 
> 
> On 5/6/20, 1:45 PM, "juniper-nsp on behalf of Brian Johnson" 
>  <mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
> brian.john...@netgeek.us <mailto:brian.john...@netgeek.us>> wrote:
> 
>[External Email. Be cautious of content]
> 
> 
>Several points.
> 
>1. Configuration examples explaining how something is configured are not 
> supposed to imply that this is how you should configure it or even that the 
> exact configuration is valid. The example configuration could allow for 
> over-subscription if port 5 were added at 100G.
> 
>2. The MPC7 card can be RTU licensed to 50% and 75% of the ports. Not 
> following licensing restrictions on port usage will void support.
> 
>3. Junos will let you configure all kinds of things that will either not 
> work or break later. It’s a feature. ;)
> 
>4. Be sure you fully understand what you are doing before implementing it 
> and checking with Juniper to be sure it is a supported configuration is not a 
> bad idea when there is a cloudy understanding of the features. I work with 
> customers all of the time on the Juniper MX product line and this card is 
> still very misunderstood (even by me occasionally).
> 
>My advice would be to validate what you are doing with JTAC before 
> implementing In production.
> 
>- Brian
> 
>> On May 6, 2020, at 12:47 PM, Tobias Heister  wrote:
>> 
>> On 06.05.2020 18:24, Brian Johnson wrote:
>>> A wise man once told me… “Just because you can do something, doesn’t mean 
>>> you should”. More specific, “Just because you can do it in the Junos 
>>> config, doesn’t mean it’s supported.” Junipers licensing “honor system” 
>>> required honorable intentions. ;)
>> 
>> I would say it is supported. Even the documentation has an example where one 
>> port of the group is 100GE and two others are 10GE:
>> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-at-port-level
>> 
>> Also with MPC7 its not like its honor based to only use 240G per PFE ... its 
>> a hard limit ;)
>> 
>> If you run in PIC Mode with 100GE set, than in deed the other ports are 
>> disabled:
>> "For example, if you choose to configure PIC 0 at 100-Gbps speed, only ports 
>> 2 and 5 of PIC 0 operate at 100-Gbps speed, while the other ports of the PIC 
>> are disabled."
>> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-on-mpc7e-multi-rate-to-enable-different-port-speeds
>> 
>> I mean what else should it do, there are only two 100GE Ports per PFE anyway 
>> ;)
>> 
>> --
>> Kind Regards
>> Tobias Heister
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!UcKakRO5p3-uKQPwDTlCL8Nb20WMoMb5O4S2qhF853FKOIdf_Ypfj7LNl-UZ_HqQ$
>>  
>> <https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!UcKakRO5p3-uKQPwDTlCL8Nb20WMoMb5O4S2qhF853FKOIdf_Ypfj7LNl-UZ_HqQ$>
> 
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net 
> <mailto:juniper-nsp@puck.nether.net>
>
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!UcKakRO5p3-uKQPwDTlCL8Nb20WMoMb5O4S2qhF853FKOIdf_Ypfj7LNl-UZ_HqQ$
>  
> <https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!UcKakRO5p3-uKQPwDTlCL8Nb20WMoMb5O4S2qhF853FKOIdf_Ypfj7LNl-UZ_HqQ$>
> 
> 
> Juniper Business Use Only

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

Re: [j-nsp] Rate selectability on MPC7E-MRATE

[Brian Johnson]

Several points.

1. Configuration examples explaining how something is configured are not 
supposed to imply that this is how you should configure it or even that the 
exact configuration is valid. The example configuration could allow for 
over-subscription if port 5 were added at 100G.

2. The MPC7 card can be RTU licensed to 50% and 75% of the ports. Not following 
licensing restrictions on port usage will void support.

3. Junos will let you configure all kinds of things that will either not work 
or break later. It’s a feature. ;)

4. Be sure you fully understand what you are doing before implementing it and 
checking with Juniper to be sure it is a supported configuration is not a bad 
idea when there is a cloudy understanding of the features. I work with 
customers all of the time on the Juniper MX product line and this card is still 
very misunderstood (even by me occasionally).

My advice would be to validate what you are doing with JTAC before implementing 
In production.

- Brian

> On May 6, 2020, at 12:47 PM, Tobias Heister  wrote:
> 
> On 06.05.2020 18:24, Brian Johnson wrote:
>> A wise man once told me… “Just because you can do something, doesn’t mean 
>> you should”. More specific, “Just because you can do it in the Junos config, 
>> doesn’t mean it’s supported.” Junipers licensing “honor system” required 
>> honorable intentions. ;)
> 
> I would say it is supported. Even the documentation has an example where one 
> port of the group is 100GE and two others are 10GE:
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-at-port-level
> 
> Also with MPC7 its not like its honor based to only use 240G per PFE ... its 
> a hard limit ;)
> 
> If you run in PIC Mode with 100GE set, than in deed the other ports are 
> disabled:
> "For example, if you choose to configure PIC 0 at 100-Gbps speed, only ports 
> 2 and 5 of PIC 0 operate at 100-Gbps speed, while the other ports of the PIC 
> are disabled."
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-on-mpc7e-multi-rate-to-enable-different-port-speeds
> 
> I mean what else should it do, there are only two 100GE Ports per PFE anyway 
> ;)
> 
> -- 
> Kind Regards
> Tobias Heister
> ___
> 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] Rate selectability on MPC7E-MRATE

[Brian Johnson]

A wise man once told me… “Just because you can do something, doesn’t mean you 
should”. More specific, “Just because you can do it in the Junos config, 
doesn’t mean it’s supported.” Junipers licensing “honor system” required 
honorable intentions. ;)

Have fun!

- Brian

> On May 6, 2020, at 11:03 AM, Chris Wopat  wrote:
> 
> On Wed, May 6, 2020 at 9:41 AM Brian Johnson  wrote:
>> 
>> So you have a 4x10G breakout and a 100G QSFP28 in the same group of 3 
>> interfaces and they are all working? Just because I can install and 
>> configure the optics, doesn’t mean they will function. This would conflict 
>> with what is coming from Juniper Product teams.
>> 
>> To be clear, I realize that the ports do not “disappear” because you insert 
>> the QSP28 into the port group, just that they will not work. :)
> 
> We've been this with MPC7s, works fine. You can squeeze the 240g out
> of each PIC just fine, you simply cannot oversub.
> 
>fpc 7 {
>pic 0 {
>port 2 {
>speed 100g;
>}
>port 4 {
>speed 10g;
>}
>port 5 {
>speed 100g;
>}
>}
>}
> 
> ports 4 and 5 in same 'group of 3', et-7/05 up at 100g and
> xe-7/0/4:[0-3] up at 10g.

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

Re: [j-nsp] Rate selectability on MPC7E-MRATE

[Brian Johnson]

So you have a 4x10G breakout and a 100G QSFP28 in the same group of 3 
interfaces and they are all working? Just because I can install and configure 
the optics, doesn’t mean they will function. This would conflict with what is 
coming from Juniper Product teams.

To be clear, I realize that the ports do not “disappear” because you insert the 
QSP28 into the port group, just that they will not work. :)

- Brian

> On May 6, 2020, at 9:14 AM, sth...@nethelp.no wrote:
> 
>> 2. If you put a 100G optic in the QSFP28 port, the other 2 QSFP ports are 
>> not available. So 100G per group with a QSFP28 in them. Assuming only 100G 
>> QSFPs in use, the card will do 400G total.
> 
> Yes. But you can have 8 x 10G in addition in the form of 2 x 40G with
> breakout. This is from one of our routers with an MPC7E-MRATE card:
> 
> xe-3/0/0:0  down  down
> xe-3/0/0:1  down  down
> xe-3/0/0:2  down  down
> xe-3/0/0:3  down  down
> et-3/0/2upup
> et-3/0/5upup
> xe-3/1/0:0  down  down
> xe-3/1/0:1  down  down
> xe-3/1/0:2  down  down
> xe-3/1/0:3  down  down
> et-3/1/2upup
> et-3/1/5updown
> 
> and the corresponding chassis config is:
> 
> pic 0 {
>port 0 {
>speed 10g;
>}
>port 2 {
>speed 100g;
>}
>port 5 {
>speed 100g;
>}
> }
> pic 1 {
>port 0 {
>speed 10g;
>}
>port 2 {
>speed 100g;
>}
>port 5 {
>speed 100g;
>}
> }
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

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

Re: [j-nsp] Rate selectability on MPC7E-MRATE

[Brian Johnson]

FYI this is a more complex question….

From my understanding, you need to look at the card as 4 groups of 3 ports (2 
QSFP+ and 1 QSFP28). Here are your options:

1. All 3 ports can be used at 40G or 4x10G in any combination. So 120G per 
group or 480G per card. This is the maximum for the card.
2. If you put a 100G optic in the QSFP28 port, the other 2 QSFP ports are not 
available. So 100G per group with a QSFP28 in them. Assuming only 100G QSFPs in 
use, the card will do 400G total.

You can mix what each group does to get anywhere from 400G to 480G of capacity 
from the card.

Correct me if you know better.

- Brian

> On May 6, 2020, at 7:06 AM, sth...@nethelp.no wrote:
> 
>> we have some MX-Routers (MX480 and MX960) with MPC7E-MRATE
>> linecards. As
>> far as i know, one PFE supports 240G each. Is it possible to use both
>> 100G ports and in addititon 14x 10G ports on a single PFE  ?
>> With the following configuration, i got an error "FPC 5 PIC 1 Invalid
>> port profile configuration":
> 
> You can't oversubscribe the capacity of the MPC7 card. See
> 
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/preventing-oversubscription-active-physical-ports.html#id-supported-active-physical-ports-for-configuring-rate-selectability-to-prevent
> 
> for permitted port configurations. Note "Oversubscription of Packet
> Forwarding Engine capacity is not supported."
> 
> Steinar Haug, Nethelp consulting, sth...@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

Re: [j-nsp] Prioritize route advertisement

[Brian Johnson]

If you have inconsistent MTUs throughout your implementation, you can cause 
fragmentation and this will lead to re-transmittals.

In other words… it will be slower, possibly extremely slow depending on the 
volume.

- Brian


Brian Johnson
br...@sdjohnsons.us

> On Apr 6, 2020, at 10:16 AM, Jason Lixfeld  wrote:
> 
> Is it possible it’s related to the MTU change itself?  I only mention it 
> because I ran into a convergence issue between a MX10K3 and a JRR200 in the 
> lab when I was timing convergence speeds.  It took many minutes for the JRR 
> to receive the full table.  It turned out to be a lower MTU on an 
> intermediate device in the lab core.  Once that was fixed, the JRR receive 
> the full table in less than a minute.
> 
>> On Apr 6, 2020, at 11:05 AM, Gustavo Santos  wrote:
>> 
>> Hi,
>> 
>> We have a MX10003 as peering router with over 400 BGP sessions. Last week
>> we had to change MTU from one Interface and after change, the router took
>> about 20 minutes to advertise routes some of our transit providers.
>> 
>> Is there a way to prioritize advertisement on some BGP sessions above
>> others? I tried the
>> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-prioritization.html
>> 
>> 
>> The first time I noticed that behavior and with that event , this options
>> did not worked as expected.
>> 
>> The question is if there is a way to work around this change that behavior?
>> 
>> Regards.
>> ___
>> 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] EX2300 Code

[Brian Johnson]

Always use the JTAC recommends version unless you have a specific feature you 
need that is not supported in that version.

https://kb.juniper.net/InfoCenter/index?page=content=KB21476 


Thus... 15.1X53-D591 or 18.2R3-S2 should be good to go.

- Brian

> On Dec 9, 2019, at 5:15 AM, William  wrote:
> 
> Hi,
> 
> I am in the process of getting our first stack of EX2300s ready for
> production, can anyone recommend any specific versions of junos to run
> on them?
> 
> I'm not taking advantage of any advance features, just after something
> stable :)
> 
> Cheers,
> 
> William
> ___
> 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] Ramp up old MX480

[Brian Johnson]

Do you know if you have the enhanced mid-plane? If not, it’s a chassis upgrade 
to install MPC3 or better line cards.

- Brian

> On Aug 28, 2019, at 3:15 AM, john doe  wrote:
> 
> Hi!
> 
> I need to bump one of my MX480 with better line cards so it can live in the
> DFZ another year or so :) Services running are MPLS/RSVP, DFZ and so on.
> 
> Existing is:
> RE-S-1800x2
> MX-SCB
> DPCE-R linecards
> 
> I'm thinking refurbished hw. I only need 10G-ports, what MPC generation
> would be suitable to swap to? Do I need to change SCB? Is the RE ok?
> 
> Johan
> ___
> 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] QFX5100 NAT

[Brian Johnson]

NAT is not a supported feature on the QFX platform.

- Brian

> On Sep 6, 2018, at 2:15 PM, Brendan Mannella  wrote:
> 
> Trying to do NAT on a QFX5100 and cannot find where its configured.
> Googling around i see its supported but none of the configuration examples
> work for it.
> ___
> 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] Which versions of Space support Spotlight

[Brian Johnson]

Check out this link: 
https://www.juniper.net/documentation/en_US/release-independent/spotlight-secure/information-products/pathway-pages/spotlight-secure/index.html
 


- Brian

> On Jun 24, 2018, at 6:24 AM, M Abdeljawad via juniper-nsp 
>  wrote:
> 
> 
> Hi
> 
> 
> 
> 
> I need to know which versions of junos space support for the spotlight?
> 
> 
> 
> 
> Thanks
> ___
> 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] Juniper SRX 58K cluster IPv6 enable

[Brian Johnson]

>From my experience... Any change of the mode on a protocol requires a reboot 
>of JunOS. Correct?

- Brian J.

Sent from my iPhone
Please excuse typos

> On Feb 20, 2018, at 5:59 AM, Ola Thoresen  wrote:
> 
>> On 20. feb. 2018 11:10, Imran Kamal wrote:
>> Hi all,
>> 
>> Can anyone please confirm once I enable "IPv6 Flow mode", do I need to
>> reboot both SRX 58K boxes at the time or one after another?
>> 
>> The firewall cluster in production and we can't afford any outage window at
>> the moment
> 
> 
> 
> I have not tested it on 58k spcifically, but on other SRX-clusters, and you 
> need to reboot both nodes.
> 
> However, you can reboot them one after each other, and ensure that you 
> failover all redundancy groups gracefully between the reboots.
> 
> So I would suggest enabling IPv6 flow mode, then reboot the secondary node. 
> After it comes back up, failover all redundancy groups to the already 
> rebooted node. Then reboot the former primary node.
> 
> Then you can decide whether you want to fail back to the old primary again 
> after the second reboot.
> 
> But no matter what you do - I would do this in a service window. It SHOULD 
> work without any traffic interruptions, but better to be safe than sorry.
> 
> 
> /Ola (T)
> 
> ___
> 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] Need Assistance

[Brian Johnson]

Completely agree. Unless you want all BGP routes to have a better preference 
than all OSPF routes. The route policy is a scalpel, the protocol preference is 
a hammer.

- Brian


> On Nov 7, 2017, at 7:26 AM, Julian Seifert  wrote:
> 
> Hi,
> 
> wouldn't it be more preferable(less general impact  than completely changing 
> protocol preferene value) to set the routepreference for this specific route 
> to <10 in the BGP import policy? 
> 
> set policy-options policy-statement BGP-IMPORT term set-Pref from 
> route-filter 172.16.0.0/16 exact
> set policy-options policy-statement BGP-IMPORT term set-Pref then preference 9
> 
> kind regards,
> 
> Julian
> 
> 
> 
> Von: juniper-nsp  im Auftrag von Vincent 
> Bernat 
> Gesendet: Dienstag, 7. November 2017 07:00
> An: sameer mughal
> Cc: juniper-nsp@puck.nether.net
> Betreff: Re: [j-nsp] Need Assistance
> 
> ❦  7 novembre 2017 10:52 +0500, sameer mughal  :
> 
>> Hi All,
>> 
>> Kindly review below routes, can anyone please help me to prefer BGP over
>> OSPF internal route?
>> What will be the configuration, please?
> 
> set protocols ospf preference 180
> --
> Make sure your code "does nothing" gracefully.
>- The Elements of Programming Style (Kernighan & Plauger)
> ___
> 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] srx event-options

[Brian Johnson]

Diogo,

I believe he is shutting down his external interface when a neighbor on the 
internal interface is down.

Alex: This script looks interesting and I'd like to see the final solution when 
you get it.

Thanks.

- Brian


 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Diogo Montagner
 Sent: Monday, March 18, 2013 7:25 AM
 To: Luca Salvatore
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] srx event-options
 
 I think you need to review your logic. How do you expect the OSPF adjacency
 to come up if you have shutdown the interface ?
 
 On Monday, 18 March 2013, Luca Salvatore wrote:
 
  I'm playing around with some event-options on a SRX.  I'm trying to make
  the SRX shutdown an interface when a specific OSPF neighbour is detected
 as
  down, then bring the interface back up once OSPF has re-established.
 
 
  I have this:
 
  [edit event-options]
  lsalvatore@FWL001# show
  policy shutdown_internet_if_core_down {
  events rpd_ospf_nbrdown;
  attributes-match {
  rpd_ospf_nbrdown.neighbor-address matches 10.255.255.86;
  }
  then {
  execute-commands {
  commands {
  set interface ge-0/0/3 disable;
  commit;
  }
  }
  }
  }
  policy bring_up_internet_when_core_is_back {
  events rpd_ospf_nbrup;
  attributes-match {
  rpd_ospf_nbrup.neighbor-address matches 10.255.255.86;
  }
  then {
  execute-commands {
  commands {
  delete interface ge-0/0/3 disable;
  commit;
  }
  }
 
  Should this work?  I haven't been able to test it yet but it seems like it
  may do what I need.
  Luca
 
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
  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

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

Re: [j-nsp] Problems with Link Aggregation

[Brian Johnson]

Filippo,

Can you send the output of show lacp interface ae0?

Thanks 

- Brian

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Filippo Cugini
 Sent: Wednesday, March 06, 2013 8:16 AM
 To: juniper-nsp@puck.nether.net
 Cc: andrea.sgambell...@libero.it
 Subject: [j-nsp] Problems with Link Aggregation
 
 Hi,
 
 we configured the link-aggregation on two switches EX3200 with JUNOS
 software 10.0R4.7.
 We configured the aggregated interface (ae0), containing three ge
 interfaces (ge-0/0/12, ge-0/0/14, ge-0/0/16).
 At the operational level, the state of the aggregated interface (show
 interfaces ae0 extensive) shows that the link is up at 3000mbps.
 
 However, when we send traffic on the aggregated link, just one ge works,
 and we experience packet loss when we exceed the throughput of
 1000mbps.
 Indeed, the statistics of all interfaces show that only the ge-0/0/12 is
 utilized to forward the data traffic, while the other two interfaces
 send and receive only signaling packets.
 
 Any suggestions?
 
 This is our one-side configuration:
 
 
 chassis {
  aggregated-devices {
  ethernet {
  device-count 1;
  }
  }
 }
 
 interfaces {
  ge-0/0/12 {
  ether-options {
  802.3ad ae0;
  }
  }
  ge-0/0/14 {
  ether-options {
  802.3ad ae0;
  }
  }
  ge-0/0/16 {
  ether-options {
  802.3ad ae0;
  }
  }
 
 ...
 
  ae0 {
  aggregated-ether-options {
  minimum-links 2;
  lacp {
  active;
  }
  }
  unit 0 {
  family inet {
 address 10.255.255.2/30;
  }
  }
  }
 
 }
 
 
 ___
 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] J-web on MX5 router

[Brian Johnson]

Ben,

The only reason I'm thinking about it right now is to give access to some 
people who might want a pretty interface to look at stats. I doubt any 
significant configuration would be done using J-Web (NO CONFIGURATION done by 
those who NEED the J-Web interface).

Is there any reason to believe that J-Web will not be developed for this 
platform? How long does it take for this type of release?

- Brian


 -Original Message-
 From: Ben Dale [mailto:bd...@comlinx.com.au]
 Sent: Sunday, March 03, 2013 6:44 PM
 To: Brian Johnson
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] J-web on MX5 router
 
 It doesn't look like there is a build for the PowerPC-based MXs - but it is
 available on the higher end boxes though seems to be some sort of tax^W
 license required:
 JWEB-1-LTU
 
 I'm struggling to come up with a single reason why you'd want to though -
 using the J-Web to drive an MX would be like playing a piano wearing oven
 mitts.. while submerged in treacle.
 
 On 04/03/2013, at 9:32 AM, Brian Johnson bjohn...@drtel.com wrote:
 
  Simple question, but can the J-web software be installed on the MX5
 platform?
 
  Thank you.
 
  - Brian
 
 
  ___
  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] J-web on MX5 router

[Brian Johnson]

On that note I'll start a new thread on SNMP for MX series...

- Brian

From: Tomasz Mikołajek [mailto:tmikola...@gmail.com]
Sent: Monday, March 04, 2013 8:57 AM
To: Brian Johnson
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] J-web on MX5 router

Hello.
Brian, maybe use Cacti to have interface stats.
Tomek.
2013/3/4 Brian Johnson bjohn...@drtel.commailto:bjohn...@drtel.com
Ben,

The only reason I'm thinking about it right now is to give access to some 
people who might want a pretty interface to look at stats. I doubt any 
significant configuration would be done using J-Web (NO CONFIGURATION done by 
those who NEED the J-Web interface).

Is there any reason to believe that J-Web will not be developed for this 
platform? How long does it take for this type of release?

- Brian


 -Original Message-
 From: Ben Dale [mailto:bd...@comlinx.com.aumailto:bd...@comlinx.com.au]
 Sent: Sunday, March 03, 2013 6:44 PM
 To: Brian Johnson
 Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] J-web on MX5 router

 It doesn't look like there is a build for the PowerPC-based MXs - but it is
 available on the higher end boxes though seems to be some sort of tax^W
 license required:
 JWEB-1-LTU

 I'm struggling to come up with a single reason why you'd want to though -
 using the J-Web to drive an MX would be like playing a piano wearing oven
 mitts.. while submerged in treacle.

 On 04/03/2013, at 9:32 AM, Brian Johnson 
 bjohn...@drtel.commailto:bjohn...@drtel.com wrote:

  Simple question, but can the J-web software be installed on the MX5
 platform?
 
  Thank you.
 
  - Brian
 
 
  ___
  juniper-nsp mailing list 
  juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 


___
juniper-nsp mailing list 
juniper-nsp@puck.nether.netmailto: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] MX Series MIBS

[Brian Johnson]

I am having a difficult time determining what MIBs to monitor on my new Juniper 
MX routers. I come from a Cisco shop and know how to monitor CPU, memory and 
(of course) interface stats. I'm having no issues with monitoring interfaces, 
but cannot determine what MIBs to monitor for CPU and memory usage.

I am using Cacti and could not find a good template for MX routers out there. 
I'd be willing to build and share if anyone can tell me what important system 
mibs to graph and supply the mibs for the MX5 through MX80 units.

Thanks

- Brian



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

Re: [j-nsp] MX Series MIBS

[Brian Johnson]

Josh,

I have looked through these MIBs and am still at a loss for which to use to 
create Cacti graphs for system status (CPU usage, memory usage, etc...)  
similar to the ones provided by Cacti for Cisco devices.

Any advice on this front? Is anyone else graphing this type of data with Cacti 
(or other SNMP utilities) on the MX5 platform?

Thanks

- Brian


 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Josh Hoppes
 Sent: Monday, March 04, 2013 10:16 AM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] MX Series MIBS
 
 A full set of MIBs are available here:
 http://www.juniper.net/techpubs/en_US/junos11.4/topics/concept/juniper
 -specific-mibs-junos-nm.html
 
 This MIB is is probably the one you want:
 http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/mibs
 /mib-jnx-chassis.txt
 
 They are versioned, I just linked to 11.4 as we are using that release
 but I would make sure to use the one applicable for your deployment.
 
 On Mon, Mar 4, 2013 at 9:09 AM, Brian Johnson bjohn...@drtel.com
 wrote:
  I am having a difficult time determining what MIBs to monitor on my new
 Juniper MX routers. I come from a Cisco shop and know how to monitor CPU,
 memory and (of course) interface stats. I'm having no issues with monitoring
 interfaces, but cannot determine what MIBs to monitor for CPU and memory
 usage.
 
  I am using Cacti and could not find a good template for MX routers out
 there. I'd be willing to build and share if anyone can tell me what important
 system mibs to graph and supply the mibs for the MX5 through MX80 units.
 
  Thanks
 
  - Brian
 
 
 
  ___
  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

[j-nsp] J-web on MX5 router

[Brian Johnson]

Simple question, but can the J-web software be installed on the MX5 platform?

Thank you.

- Brian


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