Re: [j-nsp] juniper.net down?
Loading fine from NZ, as is https://iam-signin.juniper.net & https://webdownload.juniper.net/ Being served off Akamai, so maybe a localised Akamai issue to you. www.juniper.net 23.43.144.179 assets.adobedtm.com 131.203.7.165 Data from cached requests only. consent.trustarc.com 54.192.177.98 d.la3-c2-ia2.salesforceliveagent.com 13.110.34.160 d.la3-c2-ph2.salesforceliveagent.com 13.110.37.32 juniper.secure.force.com 13.110.83.142 service.force.com 101.53.168.136 Data from cached requests only. www.youtube.com 172.217.24.46 On Wed, 19 Oct 2022 at 07:13, Aaron via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > juniper.net down? > > > > > > > > Aaron > > aar...@gvtc.com > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
Hi, Got things working in the end, thanks everyone for their help and patience. Also thanks @John Kristoff especially for the template at https://github.com/jtkristoff/junos/blob/master/flows.md it was very helpful. As I suspected I was doing something dumb, or rather a combination of the dumb. 1. I had initially tried to use fxp0 as my export interface, it seems this is not supported. 2. I then tried to use an interface in a VRF to export the flows, I think some additional config may be required for this ( https://kb.juniper.net/InfoCenter/index?page=content=KB28958). 3. It's always MTU... I suspect in one of my various config attempts flow's were being sent, but dropped because of the 1500 MTU on the flow collector and a larger MTU on the MX204 interface generating them. In the end I set up a new link-net on a new vlan interface attached to inet0 between the MX204 and netflow collector, set the inet mtu to 1500 and everything started working. Again thanks everyone for the help, I now have some really interesting flow stats to examine :) On Fri, 10 Apr 2020 at 07:10, John Kristoff wrote: > On Thu, 9 Apr 2020 06:20:00 + > Liam Farr wrote: > > > However I am getting export packet failures. > > Some loss of flows being exported may be unavoidable depending on > your configuration and environment. If you want to see fewer errors > you may just have to sample less frequently. The numbers reported in > your "accounting errors" don't seem that large. > > In my repo page were the example config is from you'll see a couple of > images at the bottom that show the difference between the two modes. I > was aware of the flex mode when I originally did this. I think at the > time I was under the impression that setting the memory pools manually > offered some desirable predictability. > > Looking back at my notes, I think it was when Juniper TAC told me this > that led me to that conclusion: "And regarding flex-flow-sizing; this > configuration results in a first-come-first-serve creation of flows. > Whichever flow comes first, that is allowed to occupy the flow-table if > there is space in the table. Otherwise, the flow is dropped and an > error count is created." Rightly or wrongly, I recall seeming to want > to ensure some amount of reasonable memory for both v4 and v6 flows. > > John > -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 On Fri, 10 Apr 2020 at 07:10, John Kristoff wrote: > On Thu, 9 Apr 2020 06:20:00 + > Liam Farr wrote: > > > However I am getting export packet failures. > > Some loss of flows being exported may be unavoidable depending on > your configuration and environment. If you want to see fewer errors > you may just have to sample less frequently. The numbers reported in > your "accounting errors" don't seem that large. > > In my repo page were the example config is from you'll see a couple of > images at the bottom that show the difference between the two modes. I > was aware of the flex mode when I originally did this. I think at the > time I was under the impression that setting the memory pools manually > offered some desirable predictability. > > Looking back at my notes, I think it was when Juniper TAC told me this > that led me to that conclusion: "And regarding flex-flow-sizing; this > configuration results in a first-come-first-serve creation of flows. > Whichever flow comes first, that is allowed to occupy the flow-table if > there is space in the table. Otherwise, the flow is dropped and an > error count is created." Rightly or wrongly, I recall seeming to want > to ensure some amount of reasonable memory for both v4 and v6 flows. > > John > -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
; +} +} +} +} +} +} +} I then ran a *> clear services accounting flow inline-jflow fpc-slot 0* But still getting export failures; > show services accounting errors inline-jflow fpc-slot 0 Error information FPC Slot: 0 Flow Creation Failures: 0 Route Record Lookup Failures: 0, AS Lookup Failures: 0 Export Packet Failures: 188 Memory Overload: No, Memory Alloc Fail Count: 0 IPv4: IPv4 Flow Creation Failures: 0 IPv4 Route Record Lookup Failures: 0, IPv4 AS Lookup Failures: 0 IPv4 Export Packet Failures: 183 IPv6: IPv6 Flow Creation Failures: 0 IPv6 Route Record Lookup Failures: 0, IPv6 AS Lookup Failures: 0 IPv6 Export Packet Failures: 5 Thoughts? On Thu, 9 Apr 2020 at 19:35, Timur Maryin wrote: > > > On 09-Apr-20 08:20, Liam Farr wrote: > > Hi, > > > > changed to a loopback address on one of the VRF's, > > ... > > > Not sure specifically what I am doing wrong here, it seems to be > collecting > > the flows ok, but exporting is the issue? > > > > I'd appreciate any advice or pointers thanks :) > > > maybe this? > > > https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/routing-instance-edit-forwarding-options-sampling.html > > -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
to be collecting the flows ok, but exporting is the issue? I'd appreciate any advice or pointers thanks :) On Thu, 9 Apr 2020 at 04:20, Tarko Tikan wrote: > hey, > > > Does one need to reboot the box if you switch to "flex-flow-sizing"? The > > documentation seems to say so if you're going from the old format to the > > new one. > > AFAIR no. You can verify via "show jnh 0 inline-services > flow-table-info" from the PFE shell. > > -- > tarko > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Netflow config for MX204
Hi, Just wondering is someone here has a working netflow config for a MX204 they might be able to share. Last time I did netflow on a Juniper router it was a J2320 -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper support offline?
I just messaged some local at Juniper NZ and they advised that +80025864737 is working for support. Seems to work from my 2D mobile here too. Cheers Liam On Sun, 26 Jan 2020 at 8:16 PM, Nathan Ward wrote: > Hi, > > Looks to me and colleagues of mine like Juniper support is offline. > > Last night, I was able to log in but trying to download an image got to > some stage of the redirect process and hung, then a please try again later > message. It persisted for the next few hours of me trying every now and > then. > > Today, I can’t log in at all - Invalid user/password. > Password reset process works, but, still doesn’t let me in. Different > browsers, cleared cache, all the usual “is it on at the wall sir” debugging. > > Hearing the same story for others. > > I’ve called both the NZ 00800 (international 800) and the US +1888 number. > The former says “call cannot be completed”. The US number says “high volume > of calls please leave a message”. > > We’re in New Zealand - unsure if that’s relevant. > > > Are others having these same issues? > > Any insight in to what’s going on? > It’s a long weekend here, so the local sales/SE/etc. folks I usually deal > with are likely not anywhere near their phones. > > -- > Nathan Ward > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN on QFX5200
Hi,
I'm running VXLAN with ingress-node-replication in prod, can you
explain what you mean by havoc?
e.g.
show vlans
VLAN-NAME {
interface xe-0/0/2.2;
no-arp-suppression;
vxlan {
vni 561;
encapsulate-inner-vlan;
ingress-node-replication;
}
}
show interfaces xe-0/0/2
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 2 {
encapsulation vlan-bridge;
vlan-id 2;
input-vlan-map pop;
output-vlan-map push;
}
Cheers
Liam
On Fri, 20 Sep 2019 at 08:49, Vincent Bernat wrote:
> ❦ 19 septembre 2019 16:25 -04, Andrey Kostin :
>
> > You can also try to use this scrips to generate configs for your
> > specific configuration:
> > https://github.com/JNPRAutomate/ansible-junos-evpn-vxlan/
>
> I would stay away from most of the random examples available on Internet
> (even ones from Juniper). For example, the above is using
> ingress-node-replication in the "vlan" directive. This will bring havoc
> in your network.
>
> Start with the following documentation which is correct:
> <
> https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/sg-005-cloud-data-center.pdf
> >
>
> Also, be sure to read the following page to know the limitations:
> <
> https://www.juniper.net/documentation/en_US/junos/topics/concept/vxlan-constraints-qfx-series.html
> >
>
> Notably, the QFX5200 is not able to route VXLANs.
> --
> Write clearly - don't sacrifice clarity for "efficiency".
> - The Elements of Programming Style (Kernighan & Plauger)
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Kind Regards
Liam Farr
Maxum Data
+64-9-950-5302
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hi,
Tried as follows;
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map pop;
output-vlan-map push;
family ccc;
}
liam@NA-QFX5110-1# show protocols l2circuit
neighbor 192.168.68.3 {
interface xe-0/0/9.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show interfaces xe-0/1/3
description "ISPCO-WN-PVE-1 C0/F3 enp6s0f1";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map push;
output-vlan-map pop;
family ccc;
}
liam@WN-MX204-1# show protocols l2circuit
neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
When I removed the l2circuit encapsulation altogether from both ends I got
an EM -- encapsulation mismatch on the l2circuit
I also tried encapsulation internetworking / ethernet-vlan / ethernet
At some point I did get mac learning both ways in that at the QFX end I
could see mac from the MX end, but haven't successfully managed to pass
icmp / ping.
NA-ARISTA#show mac address-table vlan 123
Mac Address Table
--
VlanMac Address TypePorts Moves Last Move
--- - - -
1233606.b737.b463DYNAMIC Et91 0:18:11 ago
1236c3b.6bf0.9b0fDYNAMIC Et41 8:55:37 ago
Total Mac Addresses for this criterion: 2
Multicast Mac Address Table
--
VlanMac Address TypePorts
--- -
Total Mac Addresses for this criterion: 0
I've got an option to borrow a QFX-5110 tomorrow and set it up in a bit
better of a LAB config with a MX I have locally, where I can break things a
bit more without affecting prod traffic. That might be the go and rebuild
some l2circuits from scratch.
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html
*(QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4600) When VLAN bridge
encapsulation is enabled on a CE connected interface, the switch drops
packets if both flexible Ethernet services and VLAN CCC encapsulations are
configured on the same logical interface. Only one can be configured, not
both. For example:set interfaces xe-0/0/18 encapsulation
flexible-ethernet-services, or set interfaces xe-0/0/18 encapsulation
vlan-ccc.*
As mentioned the above might be causing me issues, as I did have some sub
interfaces running vlan-bridge alongside the vlan-ccc interface on xe-0/0/9.
On Fri, 19 Jul 2019 at 02:20, Heng Chai, Tan wrote:
> Try Alain's recommendation. I completely forgot about the input/output
> vlan part. You should have it on the MX as well, so that VLAN 123 would be
> transmitted over the l2circuit.
>
> xe- {
> description
> flexible-vlan-tagging;
> mtu 9216;
> encapsulation flexible-ethernet-services;
> unit 123 {
> description
> encapsulation vlan-ccc;
> no-traps;
> vlan-id 123;
> input-vlan-map pop;
> output-vlan-map push;
> }
>
>
> Heng Chai, Tan
>
>
>
--
Kind Regards
Liam Farr
Maxum Data
+64-9-950-5302
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hi,
That removed my ability to run bridge interfaces on xe-0/0/9, which might
cause me some design issues further down the track for production
deployments.
Applied this config, but same result.
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
vlan-tagging;
mtu 9216;
encapsulation vlan-ccc;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
On the MX end I can learn both MAC's, the NA/QFX test equip and the
WN/MX204 test equip (I have a HV connected to the QFX end for testing
running OVS and a test router VM).
root@WLG-PVE-1:~# ovs-appctl fdb/show vmbr0 | grep 123
4 123 36:06:b7:37:b4:630
5 123 6c:3b:6b:f0:9b:0f0
root@WLG-PVE-1:~#
But on the QFX end I'm not learning any mac back out the interface facing
the l2tunnel (should be learning a mac on Et9 from the MX side, but only
learning a mac on Et4 which is the QFX test device).
NA-ARISTA#show vlan 123
VLAN Name StatusPorts
- -
---
123 VLAN0123 activeEt4, Et9
NA-ARISTA#show mac address-table vlan 123
Mac Address Table
--
VlanMac Address TypePorts Moves Last Move
--- - - -
1236c3b.6bf0.9b0fDYNAMIC Et41 8:18:08 ago
Total Mac Addresses for this criterion: 1
Multicast Mac Address Table
--
VlanMac Address TypePorts
--- -
Total Mac Addresses for this criterion: 0
On Fri, 19 Jul 2019 at 02:02, Heng Chai, Tan wrote:
> Try below on QFX5110 terminating l2circuit. Last I remember the
> flexible-vlan-tagging + flexible-ethernet-services behaves oddly on the
> QFX5110.
>
> delete interfaces xe-0/0/9 flexible-vlan-tagging
> set interfaces xe-0/0/9 vlan-tagging
> set interfaces xe-0/0/9 encapsulation vlan-ccc
>
> Heng Chai, Tan
>
> On 18-07-19 9:48 PM, Liam Farr wrote:
> > Hi,
> >
> > Not sure if I'm "doing the dumb" or Junos bug or limitation of the QFX /
> > Trident 2+ chip-set.
> >
> > Trying to do a basic l2circuit as follows
> >
> > VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp > QFX-5110
> > l2circuit / ldp > VLAN Tagged Interface
> >
> > What I am seeing is traffic going Test Device > QFX-5110 > QFX-5110 >
> MX204
> >> Test Device arrives fine.
> > Return path from Test Device > MX204 > QFX-5110 > QFX-5110 > Test Device
> is
> > broken.
> >
> >
> > Config is as follows
> >
> > *MX204 Port facing test device on VLAN tag 123*
> >
> > liam@WN-MX204-1# show interfaces xe-0/1/3
> > description "WN-PVE-1 C0/F3 enp6s0f1";
> > flexible-vlan-tagging;
> > mtu 9216;
> > encapsulation flexible-ethernet-services;
> > unit 123 {
> > encapsulation vlan-ccc;
> > vlan-id 123;
> > family ccc;
> > }
> >
> > MPLS port facing intermediate / transit QFX (MS)
> >
> > liam@WN-MX204-1# show interfaces xe-0/1/1
> > description "OTN MS";
> > mtu 9216;
> > unit 0 {
> > family inet {
> > address 172.16.130.2/30;
> > }
> > family mpls;
> > }
> >
> > liam@WN-MX204-1# show interfaces lo0
> > unit 0 {
> > family inet {
> > address 127.0.0.1/32;
> > address 192.168.68.3/32;
> > }
> > }
> >
> > liam@WN-MX204-1# show protocols l2circuit
> > neighbor 192.168.68.5 {
> > interface xe-0/1/3.123 {
> > virtual-circuit-id 123;
> > control-word;
> > encapsulation-type ethernet-vlan;
> > ignore-mtu-mismatch;
> > pseudowire-status-tlv;
> > }
> > }
> >
> > liam@WN-MX204-1# show protocols ldp
> > interface xe-0/1/1.0;
> > interface lo0.0;
> >
> > liam@WN-MX204-1# show protocols mpls
> > path-mtu {
> > rsvp mtu-signaling;
> > }
> > ipv6-tunneling;
> > icmp-tunneling;
> > optimize-timer 60;
> > label-switched-path wn-mx-to-na-qfx-test {
> > from 192.168.68.3;
> > to 192.168.68.5;
> > adaptive;
> > fast-reroute;
> > primary anypath;
> > }
> > path anypath;
> > interface xe-0/1/1.0;
> >
> > liam@WN-MX204-1# show protocols ospf
> > traffic-engineering;
> > area 0.0.0.0 {
> > inter
[j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
or connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failure OL -- no outgoing label IB -- TDM incompatible bitrate NC -- intf encaps not CCC/TCCTM -- TDM misconfiguration BK -- Backup Connection ST -- Standby Connection CB -- rcvd cell-bundle size bad SP -- Static Pseudowire LD -- local site signaled down RS -- remote site standby RD -- remote site signaled down HS -- Hot-standby Connection XX -- unknown Legend for interface status Up -- operational Dn -- down Neighbor: 192.168.68.3 Interface Type St Time last up # Up trans xe-0/0/9.123(vc 123) rmt Up Jul 18 21:05:02 2019 1 Remote PE: 192.168.68.3, Negotiated control-word: Yes (Null) Incoming label: 73, Outgoing label: 95 Negotiated PW status TLV: Yes local PW status code: 0x, Neighbor PW status code: 0x Local interface: xe-0/0/9.123, Status: Up, Encapsulation: VLAN Flow Label Transmit: No, Flow Label Receive: No L2 Circuit is up on the MX liam@WN-MX204-1> show l2circuit connections Layer-2 Circuit Connections: Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failure OL -- no outgoing label IB -- TDM incompatible bitrate NC -- intf encaps not CCC/TCCTM -- TDM misconfiguration BK -- Backup Connection ST -- Standby Connection CB -- rcvd cell-bundle size bad SP -- Static Pseudowire LD -- local site signaled down RS -- remote site standby RD -- remote site signaled down HS -- Hot-standby Connection XX -- unknown Legend for interface status Up -- operational Dn -- down Neighbor: 192.168.68.5 Interface Type St Time last up # Up trans xe-0/1/3.123(vc 123) rmt Up Jul 19 01:03:21 2019 1 Remote PE: 192.168.68.5, Negotiated control-word: Yes (Null) Incoming label: 95, Outgoing label: 73 Negotiated PW status TLV: Yes local PW status code: 0x, Neighbor PW status code: 0x Local interface: xe-0/1/3.123, Status: Up, Encapsulation: VLAN Flow Label Transmit: No, Flow Label Receive: No On the* MX end test equipment *I can see the MAC address learned from the *QFX end test equipment*, however on the *QFX end test equipment* I cannot see the MAC address of the* MX end test equipment*. The MX's and QFX's are running Junos: 18.4R1-S3.1 Not sure if I just have this configured wrong, or a QFX chippie limitation or a Junos bug. Any help / pointers would be appreciated :) -- Kind Regards Liam Farr Maxum Data +64-9-950-5302 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
