Re: [j-nsp] QFX5100 NAT
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
[j-nsp] QFX5100 NAT
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
Re: [j-nsp] qfx5100 software upgrades and virtual-chassis
> On Sep 6, 2018, at 1:47 PM, Richard McGovern wrote: > > Louis, for reason (I assume some issue) is TAC saying that a host-upgrade > solves something? I also assume from Junos SW point of view, you plan to > stay with 14.1X53-D43, yes? > Yes (Supposedly). And Yes. I'm not convinced, but they won't troubleshoot the case further until I do. SNMP counters and descriptions aren't being updated for AE interfaces >9. I troubleshot this to the actual switch. For example in bytes is 48, it doesn't change. If I look at the counters for the physical interface, they update as expected. Also, the >9 is wierd. AE0-9 work as expected. AE10-? don't update properly. This is only for SNMP. If you look at the interface counters under 'show interface', they update as expected. The correct description is also shown. I tried restarting SNMP and it didn't make a difference. Also worth noting is that this oddity/problem doesn't appear to impact the flow of traffic through the box, nor the ability of the AE interface to function in any way (such as LACP failover). > BTW, in the future solution to this is to perform Host Upgrade at same time > as Junos Upgrade, using the force-host option - > https://www.juniper.net/documentation/en_US/junos/topics/task/installation/qfx-series-software-upgrading-cli.html > Yes, I've been made aware of that now. :-) Thanks. -- Louis Kowolowskilou...@cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] qfx5100 software upgrades and virtual-chassis
Louis, for reason (I assume some issue) is TAC saying that a host-upgrade solves something? I also assume from Junos SW point of view, you plan to stay with 14.1X53-D43, yes? BTW, in the future solution to this is to perform Host Upgrade at same time as Junos Upgrade, using the force-host option - https://www.juniper.net/documentation/en_US/junos/topics/task/installation/qfx-series-software-upgrading-cli.html Best of luck, Rich On 9/6/18, 2:23 PM, "Louis Kowolowski" wrote: > On Sep 6, 2018, at 1:11 PM, Nitzan Tzelniker wrote: > > If you cant afford taking down the whole VC do not work with VC > This is my philosophy with VC > Do MC-LAG or EVPN in these environment (even with VC just to increase the number of ports ) > This is now my philosophy as well. Just working on cleaning up the mess w/as little impact as I can. > Regarding the host they dont have to be the same unless there is a known issue > > From https://www.juniper.net/documentation/en_US/junos/topics/task/installation/qfx-series-software-upgrading.html > However, pay attention to these notes regarding Junos OS and Host OS versions: > • The Junos OS and Host OS versions do not need to be the same. > • During an ISSU, the Host OS cannot be upgraded. > • Upgrading the Host OS is not required for every software upgrade, as noted above. > Yes, and clarification from JTAC is that they need to be the same major version, which doesn't sound unreasonable. -- Louis Kowolowskilou...@cryptomonkeys.org Cryptomonkeys: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cryptomonkeys.com_=DwIFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=cViNvWbwxCvdnmDGDIbWYLiUsu8nisqLYXmd-x445bc=SwXGavYoXMX7_3ONE2EFDbM6qqRplmC0qoQHLrDr_HI=TRlgGH-vOckvzTgRz3rVHAdHuIz4wUvhYEmam8MKFas= Making life more interesting for people since 1977 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] qfx5100 software upgrades and virtual-chassis
> On Sep 6, 2018, at 1:11 PM, Nitzan Tzelniker > wrote: > > If you cant afford taking down the whole VC do not work with VC > This is my philosophy with VC > Do MC-LAG or EVPN in these environment (even with VC just to increase the > number of ports ) > This is now my philosophy as well. Just working on cleaning up the mess w/as little impact as I can. > Regarding the host they dont have to be the same unless there is a known > issue > > From > https://www.juniper.net/documentation/en_US/junos/topics/task/installation/qfx-series-software-upgrading.html > > However, pay attention to these notes regarding Junos OS and Host OS versions: > • The Junos OS and Host OS versions do not need to be the same. > • During an ISSU, the Host OS cannot be upgraded. > • Upgrading the Host OS is not required for every software upgrade, as > noted above. > Yes, and clarification from JTAC is that they need to be the same major version, which doesn't sound unreasonable. -- Louis Kowolowskilou...@cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] qfx5100 software upgrades and virtual-chassis
If you cant afford taking down the whole VC do not work with VC This is my philosophy with VC Do MC-LAG or EVPN in these environment (even with VC just to increase the number of ports ) Regarding the host they dont have to be the same unless there is a known issue From https://www.juniper.net/documentation/en_US/junos/topics/task/installation/qfx-series-software-upgrading.html However, pay attention to these notes regarding Junos OS and Host OS versions: - The Junos OS and Host OS versions do not need to be the same. - During an ISSU, the Host OS cannot be upgraded. - Upgrading the Host OS is not required for every software upgrade, as noted above. Nitzan On Thu, Sep 6, 2018 at 8:10 PM Louis Kowolowski wrote: > It seems reasonable, and no worse than the situation now, with mis-matched > versions. I don't see why the host software would have anything to do with > VC, seems like it should just be handling VM operations, and doing > hardware-passthrough... > > > > On Sep 6, 2018, at 12:01 PM, Chuck Anderson wrote: > > > > Logically, why couldn't you isolate one member at a time, do the > upgrade, then rejoin it to the VC? > > > > On Thu, Sep 06, 2018 at 11:12:59AM -0500, Louis Kowolowski wrote: > >> I currently have a 6 node VC of qfx5100. All are running 14.1X53-D43.7 > and host software 13.2X51-D38. In discussions with JTAC, they claim that > upgrading the host software to match the VM, it requires a reboot of *all* > nodes in the VC at the same time. > >> > >> Has anybody else had to deal with this? Are there any work-arounds? > Taking the whole thing down is extremely awkward. Can we do a rolling > upgrade (manually, I know ISSU/NSSU doesn't handle this) and stay > operational? We are working on a plan to re-architect this into 2x 3 node > VC and MC-LAG them together, but it would be nice to be able to fix this > more short-term. > > -- > Louis Kowolowskilou...@cryptomonkeys.org > Cryptomonkeys: > http://www.cryptomonkeys.com/ > > Making life more interesting for people since 1977 > > ___ > 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 software upgrades and virtual-chassis
It seems reasonable, and no worse than the situation now, with mis-matched versions. I don't see why the host software would have anything to do with VC, seems like it should just be handling VM operations, and doing hardware-passthrough... > On Sep 6, 2018, at 12:01 PM, Chuck Anderson wrote: > > Logically, why couldn't you isolate one member at a time, do the upgrade, > then rejoin it to the VC? > > On Thu, Sep 06, 2018 at 11:12:59AM -0500, Louis Kowolowski wrote: >> I currently have a 6 node VC of qfx5100. All are running 14.1X53-D43.7 and >> host software 13.2X51-D38. In discussions with JTAC, they claim that >> upgrading the host software to match the VM, it requires a reboot of *all* >> nodes in the VC at the same time. >> >> Has anybody else had to deal with this? Are there any work-arounds? Taking >> the whole thing down is extremely awkward. Can we do a rolling upgrade >> (manually, I know ISSU/NSSU doesn't handle this) and stay operational? We >> are working on a plan to re-architect this into 2x 3 node VC and MC-LAG them >> together, but it would be nice to be able to fix this more short-term. -- Louis Kowolowskilou...@cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] qfx5100 software upgrades and virtual-chassis
Logically, why couldn't you isolate one member at a time, do the upgrade, then rejoin it to the VC? On Thu, Sep 06, 2018 at 11:12:59AM -0500, Louis Kowolowski wrote: > I currently have a 6 node VC of qfx5100. All are running 14.1X53-D43.7 and > host software 13.2X51-D38. In discussions with JTAC, they claim that > upgrading the host software to match the VM, it requires a reboot of *all* > nodes in the VC at the same time. > > Has anybody else had to deal with this? Are there any work-arounds? Taking > the whole thing down is extremely awkward. Can we do a rolling upgrade > (manually, I know ISSU/NSSU doesn't handle this) and stay operational? We are > working on a plan to re-architect this into 2x 3 node VC and MC-LAG them > together, but it would be nice to be able to fix this more short-term. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] flow sampling aggregated interfaces
Flow sampling works on the address-family of layer3 subinterface, so it's under the "unit x family y", whether the unit is on an ae or a physical layer1/2 interface (since you want to sample all the traffic): set interfaces ae4 unit 0 family inet sampling input set interfaces ae5 unit 0 family inet sampling input ... However the inline sampling «engine» must be activated on both fpc under chassis, and you'll probably activate it on all fpc of your chassis using an apply-group: set groups chassis-fpc-netflow chassis fpc <*> sampling-instance sample-1 set groups chassis-fpc-netflow chassis fpc <*> inline-services flex-flow-sizing set chassis fpc 0 apply-groups chassis-fpc-netflow set chassis fpc 1 apply-groups chassis-fpc-netflow set chassis fpc 2 apply-groups chassis-fpc-netflow ... Flex-flow-sizing exists since 15.1F5, with previous versions you must partition statically and manually the inline-sampling space. > Le 6 sept. 2018 à 17:53, Nelson, Brian a écrit : > > With an MX480 running 15.1, can flow sampling be configured on an > aggregated interface? > All the examples I find are only applied to logical units of physical > interfaces. The documentation implies an ae interface is supported. > > Since the aggregated interfaces use physical interfaces from mic/fpc 0/0 > and 1/0, will I have to configure the same sampling instance on both fpc? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] qfx5100 software upgrades and virtual-chassis
I currently have a 6 node VC of qfx5100. All are running 14.1X53-D43.7 and host software 13.2X51-D38. In discussions with JTAC, they claim that upgrading the host software to match the VM, it requires a reboot of *all* nodes in the VC at the same time. Has anybody else had to deal with this? Are there any work-arounds? Taking the whole thing down is extremely awkward. Can we do a rolling upgrade (manually, I know ISSU/NSSU doesn't handle this) and stay operational? We are working on a plan to re-architect this into 2x 3 node VC and MC-LAG them together, but it would be nice to be able to fix this more short-term. -- Louis Kowolowskilou...@cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] flow sampling aggregated interfaces
With an MX480 running 15.1, can flow sampling be configured on an aggregated interface? All the examples I find are only applied to logical units of physical interfaces. The documentation implies an ae interface is supported. Since the aggregated interfaces use physical interfaces from mic/fpc 0/0 and 1/0, will I have to configure the same sampling instance on both fpc? thanks Brian Nelson ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
