Re: [j-nsp] proxy-arp on EVPN irb

[Chuck Anderson via juniper-nsp]

On Wed, Dec 13, 2023 at 03:58:00PM +, Jackson, William via juniper-nsp 
wrote:
> We have had to send to the clients via DHCP a set of /32 host routes to 
> circumvent this problem.

If you are able to configure the clients with /32 routes via DHCP, why
don't you just configure the clients with the proper netmask/gateway
via DHCP to begin with.  Then you won't need the abomination of
proxy-arp.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX304 - Edge Router

[Chuck Anderson via juniper-nsp]

On Wed, Oct 25, 2023 at 03:12:29PM +0200, Mark Tinka via juniper-nsp wrote:
> On 10/25/23 10:57, Sebastian Wiesinger via juniper-nsp wrote:
> > Yeah it depends. Our MX204 also needed licenses for subscriber
> > managment. Some options would produce a license warning and some other
> > stuff just failed silently which was worse. Also noone at Juniper
> > seemed to know WHICH licenses we needed for our usecase.
> >
> > In the end our license list looked like this:
> >
> > subscriber-accounting
> > subscriber-authentication
> > subscriber-address-assignment
> > subscriber-vlan
> > subscriber-ip
> > scale-subscriber
> > scale-l2tp
> > l2tp-inline-lns
> >
> > So yeah.. that wasn't a nice experience at all.
> 
> Subscriber Management has always required real licenses on the MX since 
> it started shipping BNG code.
> 
> You got 1,000 subscribers as standard, and then needed an enforceable 
> license after that.

This caused us heartburn for our Campus LAN when we upgraded as we had
been using "forwarding-options helpers bootp" and were told that it
was deprecated and we needed to move to "forwarding-options
dhcp-relay" which is a BNG feature that requires a subscriber
license--a ridiculous requirement for a Campus LAN.  It turns out that
"helpers bootp" still worked, and may still work today, but I'm no
longer working in that environment so I'm not sure.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multirate SFP+ in EX?

[Chuck Anderson via juniper-nsp]

Not sure, but if there is a way, it might be configured under "set chassis pic 
...", perhaps something like this:

sst chassis pic fpc-slot 0 pic-slot 1 port 0 speed 10g


On Mon, Feb 13, 2023 at 09:23:10AM -0600, Chris Adams via juniper-nsp wrote:
> I have an old Juniper EX4500 (working on replacing it), and some
> FiberStore 10G/1G SFP+ modules (SFP-10GSR-85).  When I put the SFP+ in
> the EX, it sees it as a 1G module (so interface ge-0/0/X), but the other
> end is 10G.  Is there a way to force the EX end to 10G with the
> multirate SFP+?  I see set ether-options speed, but it'll only go to 1g
> on the ge-foo interface; I can set xe-foo ether-options speed 10g but it
> is ignored (since the EX doesn't think it has an xe-foo interface).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cannot program filter pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries

[Chuck Anderson via juniper-nsp]

On Fri, Oct 14, 2022 at 01:50:55PM -0400, Jonathen Landis wrote:
> On Thu, Oct 13, 2022 at 9:59 AM Saku Ytti via juniper-nsp 
>  wrote:
> > I lost a fight with JTAC about whether the TCAM exhausting filter
> should be a commit failure or not.
> 
> In lieu of failing the commit, would it make sense for TCAM exhaustion to
> trigger a system/chassis alarm? Or display a parameter in either the
> operational command output, or even comments in the "show configuration"
> output beside the filter. I don't recall if these logs repeat, or are only
> shown after a commit operation, so I could see them getting missed as well.

An alarm is a good idea.  The messages have not repeated in my
scenario.  They only appear on bootup, or when new hardware is
inserted (e.g. insert an optic, Junos creates the interface and tries
to program the filters and fails.)

> > I think you're gonna need JTAC.

Already engaged.  The current theory is IP Source Guard filters are
filling up the Dynamic filter slices, leaving no slices available to
program a Class-of-Service Dynamic filter group.

Also, it appears that when Junos was changed to support DHCP Snooping,
Dynamic ARP Inspection, and IP Source Guard on trunk ports, even
though trunk ports are in "trusted" mode by default, the switch is
learning bindings on the trusted trunk ports (i.e. the uplink) and
then *programming them into TCAM* at least for IPSG.  If this is true,
then Junos has created a situation where one cannot deploy IPSG
effectively unless the switch can scale to the number of entries
needed for an entire *VLAN* which may have thousands of hosts, rather
than just the access ports on a single switch stack which would
normally have only hundreds of hosts or less.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cannot program filter pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries

[Chuck Anderson via juniper-nsp]

It's an internal filter created by class-of-service.  The one I chose does have 
a complaint, I just didn't paste the entire log originally.  Here are a few 
lines earlier:

Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-623-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-624-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-624-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-626-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries

VFP apparently means:

VFP groups: VLAN Filter Processor - pre-ingress Content Aware processor (the 
first thing in the Broadcom Ingress pipeline). It has maximum 1024 entries. FIP 
snooping filters for example, belong to this group. 

Apparently my QoS config is too complex, which is amusing since it is basically 
the ezqos-voip template config provided by Juniper:

groups {
ezqos-voip {
class-of-service {
classifiers {
dscp ezqos-dscp-classifier {
import default;
forwarding-class ezqos-voice-fc {
loss-priority low code-points 101110;
}
forwarding-class ezqos-control-fc {
loss-priority low code-points [ 11 011000 011010 
111000 ];
}
forwarding-class ezqos-video-fc {
loss-priority low code-points 100010;
}
}
}
forwarding-classes {
class ezqos-best-effort queue-num 0;
class ezqos-video-fc queue-num 4;
class ezqos-voice-fc queue-num 5;
class ezqos-control-fc queue-num 7;
}
scheduler-maps {
ezqos-voip-sched-maps {
forwarding-class ezqos-voice-fc scheduler 
ezqos-voice-scheduler;
forwarding-class ezqos-control-fc scheduler 
ezqos-control-scheduler;
forwarding-class ezqos-video-fc scheduler 
ezqos-video-scheduler;
forwarding-class ezqos-best-effort scheduler 
ezqos-data-scheduler;
}
}
schedulers {
ezqos-voice-scheduler {
buffer-size percent 20;
priority strict-high;
}
ezqos-control-scheduler {
buffer-size percent 10;
priority strict-high;
}
ezqos-video-scheduler {
transmit-rate percent 70;
buffer-size percent 20;
priority low;
}
ezqos-data-scheduler {
transmit-rate {
remainder;
}
buffer-size {
remainder;
}
priority low;
}
}
}
}
}
apply-groups ezqos-voip;
class-of-service {
interfaces {
ge-* {
scheduler-map ezqos-voip-sched-maps;
unit 0 {
classifiers {
dscp ezqos-dscp-classifier;
}
}
}
mge-* {
scheduler-map ezqos-voip-sched-maps;
unit 0 {
classifiers {
dscp ezqos-dscp-classifier;
}
}
}
ae* {
unit 0 {
rewrite-rules {
dscp ezqos-dscp-rewrite;
}
}
}
}
rewrite-rules {
dscp ezqos-dscp-rewrite {
forwarding-class ezqos-voice-fc {
loss-priority low code-point 101110;
}
forwarding-class ezqos-video-fc {
loss-priority low code-point 100010;
}
}
}
}


On Thu, Oct 13, 2022 at 09:39:42AM +0300, Saku Ytti wrote:
> You chose a filter which doesn't seem to complain about TCAM in the
> initial post. Two filters just state 'not programmed' Others about
> TCAM? Could you choose another filter which complains about TCAM?
> 
> But certainly that output confirms 'Programmed: NO', just not entirely
> clear why. Maybe TCAM issue, maybe invalid bind-point, maybe invalid
> match, maybe invalid action. I am not familiar with the VFP_IL2L3_COS
> type filter.
> 
> Is this filter you created? What are the terms you expect it to have?
> Single term to accept ether-type 0x8100? What actions? What is the
> bind point?
> 
> 
> 
> On Wed, 12 Oct 2022 at 21:36, Chuck Ande

Re: [j-nsp] Cannot program filter pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries

[Chuck Anderson via juniper-nsp]

 Implicit Filters from DOT1XD = 0
Number of Implicit Filters from DYNAMIC SERVICES = 0
Number of Implicit Filters from LPDFD = 0
Number of Implicit Filters from Propagated Config = 0
Number of Implicit Filters from RPD = 0
Number of Implicit Filters from unknown = 0
Number of Implicit Filters from unknown = 49
Number of Implicit Filters from LI_DFCD = 0
Number of Implicit Filters from ESWD = 0
Number of Implicit Filters from ESWD EVB = 0
Number of Implicit Filters from PPMD = 0
Number of Implicit Filters from SPD = 0
Number of Implicit Filters from RMOPD = 0
Number of Implicit Filters from unknown = 0
Number of Implicit Filters from UACD = 0
Number of Implicit Filters from MCOS = 0
Number of Implicit Filters from RMPSD = 0
Number of Implicit Filters from DHCP L2 DAI = 1
Number of Implicit Filters from OPENFLOWD = 0
Number of Implicit Filters from VMOND = 0
Number of Implicit Filters from DHCP IPV6 = 1
Number of Implicit Filters from DHCP ICMPV6 = 1
Number of Implicit Filters from JDHCPD L3 TAG = 2
Number of Implicit Filters from BBE1 = 0
Number of Implicit Filters from BBE1_LI = 0
Number of Implicit Filters from BBE1_BGF = 0
Number of Implicit Filters from URL-FILTERD = 0
Number of Implicit Filters from URL 2 FILTERD = 0
Number of Implicit Filters from TWAMP = 0
Number of Implicit Filters from CAED-GLOBAL = 0
Number of Implicit Filters from IDS_FILTER = 0
Number of Implicit Filters from RTLOGD = 0
Number of Implicit Filters from CAED-LOCAL = 0


FPC0(ex4300-48mp vty)# show filter statistcs
Filter Manager Statistics:
  0 program filter add
  0 program filter delete
  0 program filter change
  0 filter log get
   2291 filter counter get
  0 filter counter reset
  0 filter log clear
  0 filter dcu stats get
  0 filter scu stats get
  0 rpf stats get
  0 prefix action stats get
  0 prefix action stats clear
385 filter apply
  2 policer
  0 three-color policer
  0 hierarchical policer
  0 global msg
  0 prefix specifc action
  0 timer
  0 notify owner id
 13 filter head
 47 filter term
 14 filter state
  0 multicast statistics support

Filter Manager Errors:
  0 program filter add
  0 program filter delete
  0 program filter change
  0 filter log get
  0 filter counter get
  0 filter counter reset
  0 filter log clear
  0 filter dcu stats get
  0 filter scu stats get
  0 rpf stats get
  0 prefix action stats get
  0 prefix action stats clear
  0 filter apply
  0 policer
  0 three-color policer
  0 hierarchical policer
  0 global msg
  0 prefix specifc action
  0 timer
  0 notify owner id
  0 filter head
  0 filter term
  0 filter state
  0 multicast statistics support

More details extracted from the full "show filter hw all" output:

==
Filter index   : 46137374
==

- Filter name  : pfe-cos-cl-624-5-1
Filter index = 46137374
Optimization flag: 0x0
Filter notify host id = 0
Pfe Mask = 0x0
jnh inst = 0x0
Filter properties: None
Filter state = CONSISTENT
term cos-cl-624-5-1
term priority 0
ethertype  
 33024 

then
accept

+ Hardware Instance : 1
  + Hardware key (struct brcm_dfw_hw_key_t):
- Type  : VFP_IL2L3_COS
- Vlan id   : 0
- Direction : ingress
- Protocol  : 35 (L2 Bridge)
- Port class id : 0
- Class id  : 0
- Loopback  : 0
- Port  : 0(xe-1)
- Vlan tag  : 0
- Non-overflow  : 1
  + FP usage info (struct brcm_dfw_fp_t):
- Group   : VFP IL2L3 COS group (143)
- My Mac  : 00:00:00:00:00:00
- Loopback Reference Count: 
- IFL Type: unknown (0)
+ List of tcam entries: [ total: 0; ]
- Pipe: 0; []
+ List of ranges  : [ total: 0; ]
- Pipe: 0 []
+ List of interface match entries : [ total: 0; ]
- Pipe: 0 []
+ List of dot1q-tag match entries : [ total: 0; ]
- Pipe: 0 []
- List of l3 ifl index entries: [ total: 0; ]
+ List of vfp tcam entries: [ total: 0; ]
- Pipe: 0 []
  + Misc info (struct brcm_dfw_misc_info_t):
- List of  : [ total: 0; ]
  + Bind point info (union brcm_dfw_bind_point_info_t):
- No grouping possible
  + Programmed: NO
  + BD ID : 500
  + Total TCAM entries available: 512
  + Total TCAM entries needed   : 1
  + Term Expansion:
- Term1: will expand to 1 term : Name "cos-cl-624-5-1"
  + Term TCAM entry requirements:
- Term1: needs 1 TCAM entry  : Name "cos-cl-624-5-1"
  + Total TCAM entries available: 512
  + Total TCAM e

[j-nsp] Cannot program filter pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries

[Chuck Anderson via juniper-nsp]

Has anyone seen these errors and know what the cause is?

Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-624-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-626-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-631-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-632-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-632-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-633-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-633-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-634-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-634-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-638-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-638-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-647-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-647-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-656-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-656-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-657-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-657-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-655-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-652-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-652-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-653-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-653-5-1" 
is NOT programmed in HW
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Cannot program filter 
pfe-cos-cl-654-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
Oct 11 21:41:02  ex4300-48mp fpc0 DFWE ERROR DFW: Filter : "pfe-cos-cl-654-5-1" 
is NOT programmed in HW

There is plenty of TCAM space for IRACL/IPACL entries, so this seems to be some 
issue with a different TCAM partition?

ex4300-48mp> show pfe filter hw summary 

Slot 0

Unit:0:
GroupGroup-ID   Allocated  Used   Free
---
> Ingress filter groups:
  iRACL group33 2048   1148   900
  iPACL group25 51212 500
> Egress filter groups:

Slot 1

Unit:0:
GroupGroup-ID   Allocated  Used   Free
---
> Ingress filter groups:
  iRACL group33 2048   1148   900
  iPACL group25 51212 500
> Egress filter groups:

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

Re: [j-nsp] port-mirror with source inside routing-instance type vrf

[Chuck Anderson via juniper-nsp]

Did you try creating a static ARP entry for the port mirroring destination?

interfaces {
xe-0/0/4:2 {
vlan-tagging;
mtu 9192;
encapsulation flexible-ethernet-services;
unit 3124 {
description "mirror test";
vlan-id 3124;
family inet {
no-redirects;
no-neighbor-learn;
address 10.235.43.0/31 {
arp 10.235.43.1 mac 02:02:02:02:02:02;
}
}
}
}
}

On Tue, Oct 11, 2022 at 02:37:47PM +, Michael Hare via juniper-nsp wrote:
> show interfaces xe-0/0/4:2 | no-more 
> enable;
> vlan-tagging;
> mtu 9192;
> encapsulation flexible-ethernet-services;
> ...
> ...
> unit 3124 {
> description "mirror test";
> vlan-id 3124;
> family inet {
> address 10.235.43.0/31;
> }
> }
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Outgrowing a QFX5100

[Chuck Anderson via juniper-nsp]

Why would you want DHCP snooping or dot1x on a campus core router? Those 
functions are typically implemented at the access layer switches connected 
directly to end users.

On Fri, Sep 16, 2022 at 03:11:22PM -0400, Jason Healy via juniper-nsp wrote:
> We're a small school campus that's been running a QFX 5100 as our core 
> switch/router for several years.  It's been a good piece of equipment but we 
> continue to hit weird limitations and I'm wondering if we're pushing the 
> platform too hard.
>
> Does the MX line handle all the layer-2 stuff that the QFX has, like DHCP 
> snooping, vlan firewall filters, or even dot1x?  Coming from the switching 
> family, I wasn't sure how prevalent those features are on the layer-3 
> equipment, or if they're configured in some totally different way.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RPD coring today?

[Chuck Anderson via juniper-nsp]

On Sat, Sep 17, 2022 at 06:21:51PM -0400, Jared Mauch via juniper-nsp wrote:
> Anyone else see their RPD start to core today?  Seeing something weird, 
> unclear if it’s local to my network or otherwise but two devices at the same 
> time seem to be having trouble, so puzzling.
> 
> Running 20.4R3.8

What does this show:

show system core-dump core-file-info /path/to/corefile
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] set-style config output format is missing some aspects of the configuration

[Chuck Anderson via juniper-nsp]

"show configuration | display set" is missing some aspects of the
configuration, namely annotations (comments).  What else is it
missing?  Would Juniper please consider making the entire
configuration representable in set-style format, including
annotations?

It is handy for example to annotate prefix-list items, but you can
apply annotate on almost any part of the configuration:

--
{master:0}[edit]
user@router# edit policy-options prefix-list FOO

{master:0}[edit policy-options prefix-list FOO]
user@router# show
10.1.1.1/32;
20.2.2.2/32;
30.3.3.3/32;

{master:0}[edit policy-options prefix-list FOO]
user@router# annotate 10.1.1.1/32 "server 1"

{master:0}[edit policy-options prefix-list FOO]
user@router# annotate 20.2.2.2/32 "peer 2"

{master:0}[edit policy-options prefix-list FOO]
user@router# annotate 30.3.3.3/32 "bad guy 3"

{master:0}[edit policy-options prefix-list FOO]
user@router# show
/* server 1 */
10.1.1.1/32;
/* peer 2 */
20.2.2.2/32;
/* bad guy 3 */
30.3.3.3/32;

{master:0}[edit]
user@router# top

{master:0}[edit]
user@router# show | find FOO
prefix-list FOO {
/* server 1 */
10.1.1.1/32;
/* peer 2 */
20.2.2.2/32;
/* bad guy 3 */
30.3.3.3/32;
}
}

{master:0}[edit]
user@router# show policy-options prefix-list FOO | display set
set policy-options prefix-list FOO 10.1.1.1/32
set policy-options prefix-list FOO 20.2.2.2/32
set policy-options prefix-list FOO 30.3.3.3/32
--

Tagging configuration items with "deactivate" or "protect" does show
up in set-style:

--
{master:0}[edit]
user@router# edit policy-options prefix-list FOO

{master:0}[edit policy-options prefix-list FOO]
user@router# deactivate 20.2.2.2/32

{master:0}[edit policy-options prefix-list FOO]
user@router# protect 30.3.3.3/32

{master:0}[edit policy-options prefix-list FOO]
user@router# show
/* server 1 */
10.1.1.1/32;
/* peer 2 */
inactive: 20.2.2.2/32;
/* bad guy 3 */
protect: 30.3.3.3/32;

{master:0}[edit policy-options prefix-list FOO]
user@router# show | display set
set policy-options prefix-list FOO 10.1.1.1/32
set policy-options prefix-list FOO 20.2.2.2/32
deactivate policy-options prefix-list FOO 20.2.2.2/32
set policy-options prefix-list FOO 30.3.3.3/32
protect policy-options prefix-list FOO 30.3.3.3/32
--

So why not "annotate"?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX VC as part of EVPN - redundancy not working

[Chuck Anderson via juniper-nsp]

I recommend you do not use VC at all, and instead use ESI-LAG for the 
server-facing links.

On Mon, Oct 04, 2021 at 11:43:23AM +, Giovanni Bellac via juniper-nsp wrote:
> Date: Mon, 4 Oct 2021 11:43:23 + (UTC)
> From: Giovanni Bellac 
> To: "juniper-nsp@puck.nether.net" 
> Subject: QFX VC as part of EVPN - redundancy not working
> Return-Path: 
> 
> Hi all,
> I am using a QFX5100 2-member-VC as a L2 gateway in a centrally routed 
> EVPN/VXLAN setup. It seems that the VC redundancy does not work in this 
> configuration properly. For test purposes I am promoting the backup-RE as 
> master-RE and afterwards restarting the old master-RE (now backup-RE). While 
> restarting the backup-RE member the connection to the servers is always lost. 
> The servers are connected to both members via LACP.
> I have tried several JunOS versions (21.1.R1, 20.4R2-S2, 20.2R2-S3, 
> 19.4R3-S3) but the results are always the same.
> 
> Any suggestions to get this work as intended?
> Kind regardsGiovanni
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ISSU offlined mpc - why?

[Chuck Anderson via juniper-nsp]

On Wed, Sep 01, 2021 at 09:44:08AM -0700, Mike via juniper-nsp wrote:
> "Unified ISSU is supported with Junos OS Release 17.4R1 for MX Series 
> routers with MPC-3D-16XGE-SFPP"
> 
>      my expectations were that the card would stay online and there 
> would be little to no operational impact, but this clearly wasn't the 
> case. I am just wondering if anyone can tell me why this might have been 
> the case and in the future what steps I would need to take to ensure 
> this both otherwise stays on the air during a future software update?

Eventually during the ISSU process, the line card software needs to be
upgraded.  During that part, each line card goes offline one at a
time.  If you have multiple line cards, design your network such that
redundant network paths are connected across different cards to
prevent a total outage when each line card is upgraded one-by-one.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Looking for Hints: Best Practices to PUSH prefix-list on MX platform with 16.x and UP

[Chuck Anderson via juniper-nsp]

I've done this with perl scripts and the Juniper NETCONF libraries.  I
make the changes inside a configuration group which is inherited into
the actual prefix-list(s), then lock down the account so it is only
able to make changes to that configuration group.

groups {
AUTO-PREFIX-LIST {
policy-options {
prefix-list AUTO-FOO {
...
prefix-list AUTO-BAR {
...
prefix-list AUTO-BAZ {
...
system {
login {
class AUTO-PREFIX-LIST {
permissions [ configure view view-configuration ];
allow-commands junoscript;
allow-configuration "(groups AUTO-PREFIX-LIST policy-options 
.*)";

On Thu, Aug 12, 2021 at 02:41:10PM -0400, Alain Hebert via juniper-nsp wrote:
> Context
> 
>      I'm looking for a *simple* & safe way to manage daily IRR changes 
> from my customers...
> 
>      Right now its a simple script that push changes using command lines 
> thru SSH...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] upgrading an antique 240

[Chuck Anderson via juniper-nsp]

In my experience 17.3R3-Sx also works with RE-2000, original SCB-MX,
and MPC line cards, although I don't know about support for DPC cards.

On Fri, Jul 16, 2021 at 10:57:19AM -0400, Alain Hebert via juniper-nsp wrote:
>      Boot using a USB key and the proper image.
> 
>          junos-install-media-usb-mx-x86-32-16.2R2.8.img
> 
>      Upgraded a RE-S-2000 engine from 11.x to 16.2.

> >> Good point! TSB16735 says last version of Junos to support SCB-MX960 is 
> >> 16.2
> >>
> >>> Junos 17.3R3-S10
> >>> Junos 18.4R2-S5
> >>> Junos 19.3R3-S2
> >>> Junos 19.4R3-S3
> > so which steps to get from 14 to 16.2?  15.x 16.2?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 and QSFP+ breakouts

[Chuck Anderson]

On Fri, Apr 30, 2021 at 09:21:13PM +, Ross Halliday wrote:
> Do FS QSFP+ breakout DACs and AOCs work on this platform? Is there some magic 
> sauce firmware I'm too daft to find?
> 
> (I've talked to JTAC, of course they blame the third-party transceiver)

Did you try disabling auto-negotiation?

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

Re: [j-nsp] Jumbo frames / mismatch MTU

[Chuck Anderson]

On Fri, Apr 23, 2021 at 01:23:32PM +, Matthew Crocker wrote:
> The SRX devices are limited to an MTU of 1600 due to the TLS carrier they are 
> using to connect back to the  QFX.
> 
> I need to support 9K frames from one ACX to another over this network.  The 
> QFX is configured for MTU of 9192 on all interfaces.  When I configure a 
> couple ACXs with 9192 MTU the OSPF & LDP sessions go away.
> 
> I can ping ACX to ACX with 9k packets just fine.


> Everything is working.  If I ‘set mtu 9192’ everything breaks

Just set the IP MTU in addition to the physical L2 "mtu".  That way
you don't have to care about calculating any possible differences
caused by encapsulation overhead:

set interface ... family inet mtu 9000

But how are you planning on overcoming the 1600 limitation on the TLS carrier?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [EXT] MX routers and DAC cables?

[Chuck Anderson]

I've used SFP+ DACs on MX, EX and QFX without problems.  I have not tried QSFP 
DACs on MX, but they work on EX/QFX.

On Fri, Jun 12, 2020 at 01:39:11PM -0500, Chris Adams wrote:
> Is anybody using DAC cables on MX routers?  We have a customer with an
> MX10003 connected to EX4600 switches with 40G DAC cables (Juniper parts,
> not third-party).  Upon upgrading the router JUNOS to 18.2R3-S3, none of
> the interfaces with a DAC cable would come up on the router end.
> 
> JTAC's response was that no DAC cables are supported on any MX routers.
> 
> That seems a little odd to me... I thought DAC cables are a part of the
> various specs, so saying they're not supported is saying those aren't
> actually Ethernet ports to me.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Wishing for clarification on how dhcp-relay works with multiple server addresses

[Chuck Anderson]

On Fri, Jun 12, 2020 at 08:44:48AM +0300, Matti Saarinen wrote:
> Chuck Anderson  wrote:
> 
> > On Thu, Jun 11, 2020 at 08:40:23AM +0300, Matti Saarinen wrote:
> >> We have a setup where one set of DHCP servers deliver IP configuration
> >> to clients and another set of DHCP servers deliver the PXE options. This
> >
> > Don't do that. Clients do not aggregate DHCP options from different
> > responses--they pick ONE DHCP server to bind to and use the info from
> > that one only. That's how the DHCP spec is written.
> 
> Actually, this setup has been working for years. I suppose the PXE code
> is more flexible in that matter. In any case, it worries me that we have
> been relying on a feature that may change without any notice when NIC
> firmwares are updated.
> 
> Back to my question:
> 
> Based on the forum responses[1] I'd say we have to live with the
> situation where we need to run dhcp-relay without forward-only on
> interfaces connecting networks needing PXE. The annoying issue is that
> every interface without forward-only eats one scale-subsrciber licence.

You can try using the legacy helpers configuration, but I'm not sure it works 
on MX10003:

set forwarding-options helpers bootp server x.x.x.x
set forwarding-options helpers bootp server y.y.y.y
set forwarding-options helpers bootp server z.z.z.z
set forwarding-options helpers bootp maximum-hop-count 16
set forwarding-options helpers bootp client-response-ttl 20
set forwarding-options helpers bootp interface xe-x/x/x. broadcast
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [EXT] Wishing for clarification on how dhcp-relay works with multiple server addresses

[Chuck Anderson]

On Thu, Jun 11, 2020 at 08:40:23AM +0300, Matti Saarinen wrote:
> We have a setup where one set of DHCP servers deliver IP configuration
> to clients and another set of DHCP servers deliver the PXE options. This

Don't do that.  Clients do not aggregate DHCP options from different
responses--they pick ONE DHCP server to bind to and use the info from
that one only.  That's how the DHCP spec is written.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] any way to do group inheritence only if parent exists?

[Chuck Anderson]

On Thu, May 21, 2020 at 07:56:10AM +0300, Saku Ytti wrote:
> Hey Chuck
> 
> > set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600
> > set interfaces apply-groups ND6
> >
> > then all irb interfaces get a "family inet6" with link-local
> > addressing created and the nd6-state-time setting applied.  How do I
> > inherit the nd6-stale-time setting only if there is already a
> > configured "family inet6" so I don't get IPv6 link-locals on IRBs
> > where I only want IPv4?
> 
> As far as I know, you can't. I'm sure if you push this at JNPR they
> are able to support it via 'family '. However as it is today,
>  only works for user input, not for parameters or keywords,
> which I suspect is not actually that huge change in parser.
> So if this would in in parser:
> 
> set family ?
>Interface protocol family
> 
> Then you could do 'family ' and it would only apply when that
> family exists. However, now as it's not user-input, it doesn't work
> and I don't think there is a way.

Is Phil Shafer reading?

> Having said that, configuration groups in junos are really great tool,
> while usually people use them to avoid repating themselves, I think
> perhaps even better use-case is to use them as namespaces, for
> example, put all your standard static config in 'template' namespace.
> So you you can programmatically do this:
> 
> edit groups template
> delete
> load merge relative https://nms/junos.template
> commit and-quit
> 
> Leaving all device-specific config intact, while normalising all generic 
> config.

Another great use (thanks to Phil Shafer for the suggestion) is to use
configuration groups combined with user classes as a finer-grained
access control mechanism for automation.

set system login class AUTO-PREFIX-LIST permissions configure
set system login class AUTO-PREFIX-LIST permissions view
set system login class AUTO-PREFIX-LIST permissions view-configuration
set system login class AUTO-PREFIX-LIST allow-commands junoscript
set system login class AUTO-PREFIX-LIST allow-configuration "(groups 
AUTO-PREFIX-LIST policy-options .*)"
set system login user autoprefix class AUTO-PREFIX-LIST

set policy-options prefix-list LIST1 apply-groups AUTO-PREFIX-LIST
set policy-options prefix-list LIST2 apply-groups AUTO-PREFIX-LIST
set policy-options prefix-list LIST3 apply-groups AUTO-PREFIX-LIST

The lists are populated by NETCONF script that cannot access any other
"policy-options" config, but can still create/delete new lists whose
names are not known beforehand:

set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 10.10.10.10/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 20.10.10.10/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 30.10.10.10/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST2 10.20.20.20/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST2 20.20.20.20/32
set groups AUTO-PREFIX-LIST policy-options prefix-list LIST3 30.20.20.20/32

> And further, don't use configuration groups, at all :) Do it all on
> NMS side, so that you are less reliant on vendor tools and
> limitations. Then you have as much flexibility on them as you wish and
> it works for all your vendors.

Any NMS(es) you recommend?  This one looks interesting:

https://napalm-automation.net/enms-hackathon-project-presentation/

and it is still under development.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] any way to do group inheritence only if parent exists?

[Chuck Anderson]

Is there any way to inherit a configuration group setting, but only if
the parent object already exists?  For example, if I apply this:

set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600
set interfaces apply-groups ND6

then all irb interfaces get a "family inet6" with link-local
addressing created and the nd6-state-time setting applied.  How do I
inherit the nd6-stale-time setting only if there is already a
configured "family inet6" so I don't get IPv6 link-locals on IRBs
where I only want IPv4?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [EXT] EX4300: Framing error with macsec enabled

[Chuck Anderson]

As I said, I'm not excluding any protocols from MACsec.  With that 
configuration, LLDP apparently doesn't work "outside the tunnel"--I never see 
any directly attached neighbors.  LLDP does work between the MACsec 
endpoints--they show as if they are directly connected neighbors.  I'm fine 
with that result in my case.

The solution to eliminate the spurious framing errors appears to be: Ask your 
carrier to shut off LLDP/CDP/any other L2 protocols running on their interfaces 
directly attached to your MACsec endpoint devices.

On Tue, Apr 21, 2020 at 02:59:53PM +, Richard McGovern wrote:
> Based upon Chuck’s reply:
> 
> Well, that was an easy fix on my MX480s:
> 
> set protocols lldp interface xe-0/0/1 disable
> 
> Now I'm not seeing CRC errors incrementing 2-3 times per minute on the 
> EX3400s connected directly to the MX480s.
> 
> I'm not excluding any protocols from MACsec--LLDP runs end-to-end between 
> the EX3400s just fine.
> 
> Don’t exclude LLDP from MACSEC and either stop or block LLDP from the 
> Carrier/ISP.  In Chuck’s case the Carrier (to the EX3400s) was his MX.  Then 
> EX3400s should see each other via LLDP, but not see the carrier.  I am not 
> sure if today, you have an LLDP neighbor with your Carrier/ISP or not?
> 
> This is the way I now read his response.
> 
> Yes?
> 
> 
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
> 
> I’d rather be lucky than good, as I know I am not good
> I don’t make the news, I just report it
> 
> [signature_1140633420]
> 
> From: james list 
> Date: Tuesday, April 21, 2020 at 10:53 AM
> To: Richard McGovern 
> Cc: Chuck Anderson , Juniper List 
> Subject: Re: [j-nsp] [EXT] EX4300: Framing error with macsec enabled
> 
> [External Email. Be cautious of content]
> 
> Hi Richard
> lldp and lacp are excluded:
> 
>   > > @EX4300-A> show configuration security macsec | display set
> > > set security macsec connectivity-association MAC security-mode 
> static-cak
> > > set security macsec connectivity-association MAC pre-shared-key ckn 
> 
> > > set security macsec connectivity-association MAC pre-shared-key cak
> > > "t"
> > > set security macsec connectivity-association MAC exclude-protocol lldp
> > > set security macsec connectivity-association MAC exclude-protocol lacp
> > > set security macsec interfaces ge-0/0/0 connectivity-association MAC
> 
> I did not catch the connection with Framing errors counter...
> 
> Please detail if you can.
> 
> Cheers
> 
> 
> Il giorno mar 21 apr 2020 alle ore 15:27 Richard McGovern 
> mailto:rmcgov...@juniper.net>> ha scritto:
> Chuck, I thought you were running both LLDP and LACP outside the MACSEC 
> tunnel, no?
> 
> (Optional) Exclude a protocol from MACsec:
> [edit security macsec connectivity-association connectivity-association-name]
> user@switch# set exclude-protocol protocol-name
> For instance, if you did not want Link Level Discovery Protocol (LLDP) to be 
> secured using MACsec:
> 
> [edit security macsec connectivity-association ca-dynamic1]
> user@switch# set exclude-protocol lldp
> When this option is enabled, MACsec is disabled for all packets of the 
> specified protocol—in this case, LLDP—that are sent or received on the link.
> 
> BEST PRACTICEWe recommend that any protocol other than MACsec being used on 
> the MACsec connection, such as LLDP, LACP, STP, or layer 3 routing protocols, 
> should be excluded and moved outside of the MACsec tunnel.
> 
> Is this not working properly for LLDP?
> 
> Rich
> 
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
> 
> I’d rather be lucky than good, as I know I am not good
> I don’t make the news, I just report it
> 
> 
> On 4/19/20, 7:31 PM, "Chuck Anderson" mailto:c...@wpi.edu>> 
> wrote:
> 
> Well, that was an easy fix on my MX480s:
> 
> set protocols lldp interface xe-0/0/1 disable
> 
> Now I'm not seeing CRC errors incrementing 2-3 times per minute on the 
> EX3400s connected directly to the MX480s.
> 
> I'm not excluding any protocols from MACsec--LLDP runs end-to-end between 
> the EX3400s just fine.
> 
> Check if the carrier is running LLDP or CDP or similar.
> 
> 
> On Sun, Apr 19, 2020 at 07:16:46PM -0400, Chuck Anderson wrote:
> > Yes, I see CRC errors on EX3400s with MACsec termination, but only on 
> one side.
> >
> > Here is my topology:
> >
> > From A to B:
> >
> > [EX3400-A]-->--[push-vlan-tag-on-MX480]-->-L2 
> vlan-->-[Carrier-ASR9

Re: [j-nsp] [EXT] EX4300: Framing error with macsec enabled

[Chuck Anderson]

Well, that was an easy fix on my MX480s:

set protocols lldp interface xe-0/0/1 disable

Now I'm not seeing CRC errors incrementing 2-3 times per minute on the EX3400s 
connected directly to the MX480s.

I'm not excluding any protocols from MACsec--LLDP runs end-to-end between the 
EX3400s just fine.

Check if the carrier is running LLDP or CDP or similar.


On Sun, Apr 19, 2020 at 07:16:46PM -0400, Chuck Anderson wrote:
> Yes, I see CRC errors on EX3400s with MACsec termination, but only on one 
> side.
> 
> Here is my topology:
> 
> From A to B:
> 
> [EX3400-A]-->--[push-vlan-tag-on-MX480]-->-L2 
> vlan-->-[Carrier-ASR9k-pop-vlan-tag]-->--[EX3400-B]
>   MACsec L2 connection  L2 xconnect   
>  MACsec
> 
> From B to A:
> 
> [EX3400-A]--<--[pop-vlan-tag-on-MX480]--<-L2 
> vlan--<-[Carrier-ASR9k-push-vlan-tag]--<--[EX3400-B]
>   MACsec L2 connection  L2 xconnect   
>  MACsec
> 
> I also have a redundant path with EX3400-C (different local switch) and 
> EX3400-B (same remote switch).
> 
> I see the CRC errors increasing at a rate of about 2-3 per minute, but only 
> on EX3400-A and EXX3400-C.
> 
> All EX3400s were initially running 15.1X53-D57.  Now A and C are running 
> 18.2R3-S2 and B is running 15.1X53-D592.  But the problem has been consistent 
> throughout all releases, no improvement with upgrades.
> 
> I wonder if something the carrier's ASR9k is sending down the VLAN towards 
> EX3400-A and -C is causing this?  If not, maybe it is the MX480s sending 
> something locally to EX3400-A and -C?
> 
> The following PRs don't seem relevant--I'm not doing anywhere close to 60% 
> utilization:
> 
> https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1261567
> 
> And I'm not seeing "runts":
> 
> https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1469663
> 
> I'm only seeing Framing errors (CRC/Align errors):
> 
> admin@ex3400-a> show interfaces extensive xe-0/2/0 |match 22791 
> Errors: 227911, Drops: 0, Framing errors: 227911, Runts: 0, Policed 
> discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 
> 0, FIFO errors: 0, Resource errors: 0
> CRC/Align errors2279110
> 
> A few seconds later, it increased to 227913:
> 
>   MAC statistics:  Receive Transmit
> Total octets179536471171563221741316352
> Total packets  13200126465   7010832956
> Unicast packets13194022205   7004785539
> Broadcast packets 52720
> Multicast packets  6098988  6047417
> CRC/Align errors2279130
> FIFO errors  00
> MAC control frames   00
> MAC pause frames 00
> Oversized frames 0
> Jabber frames0
> Fragment frames  0
> VLAN tagged frames 13196813130
> Code violations  0
> 
> Rate is only 24 Mbps, 2200 pps:
> 
> admin@ex3400-a> show interfaces extensive xe-0/2/0 |match "bps|pps" 
>   Link-level type: Ethernet, MTU: 9192, LAN-PHY mode, Speed: 10Gbps, BPDU 
> Error: None, Loop Detect PDU Error: None, Ethernet-Switching Error: None, 
> MAC-REWRITE Error: None,
>Input  bytes  :   17954037433802 24242136 bps
>Output bytes  :3221749625049   498504 bps
>Input  packets:  13200416854 2190 pps
>Output packets:   7010941872  830 pps
> 
> 
> 
> On Sun, Apr 19, 2020 at 09:37:23AM +0200, james list wrote:
> > Dear experts,
> > I've an EX4300 (Junos 17.3R3-S3.3) which have a constant Framing error
> > counter increase also if the traffic is very low.
> > Interface is connected to a WAN link from a carrier and bw is 1 Gbs but
> > traffic max is actually 100 Mbs and on average 10 Mbs.
> > On this interface I've enabled macsec, if I disable macsec the issue is not
> > in place but unfortunately macsec is mandatory to be kept enabled.
> > 
> > I cannot sniff since the packet is encrypted but to me it seems that
> > traffic is not lost, if I have 100 Mbs inside from WAN I see 100 Mbs
> > outside to DataCenter.
> > 
> > Due to the fact that monitoring system contantly raise an alert, I'd like
> > to know how to fix it or at leas

Re: [j-nsp] [EXT] EX4300: Framing error with macsec enabled

[Chuck Anderson]

Yes, I see CRC errors on EX3400s with MACsec termination, but only on one side.

Here is my topology:

>From A to B:

[EX3400-A]-->--[push-vlan-tag-on-MX480]-->-L2 
vlan-->-[Carrier-ASR9k-pop-vlan-tag]-->--[EX3400-B]
  MACsec L2 connectionL2 xconnect   
 MACsec

>From B to A:

[EX3400-A]--<--[pop-vlan-tag-on-MX480]--<-L2 
vlan--<-[Carrier-ASR9k-push-vlan-tag]--<--[EX3400-B]
  MACsec L2 connectionL2 xconnect   
 MACsec

I also have a redundant path with EX3400-C (different local switch) and 
EX3400-B (same remote switch).

I see the CRC errors increasing at a rate of about 2-3 per minute, but only on 
EX3400-A and EXX3400-C.

All EX3400s were initially running 15.1X53-D57.  Now A and C are running 
18.2R3-S2 and B is running 15.1X53-D592.  But the problem has been consistent 
throughout all releases, no improvement with upgrades.

I wonder if something the carrier's ASR9k is sending down the VLAN towards 
EX3400-A and -C is causing this?  If not, maybe it is the MX480s sending 
something locally to EX3400-A and -C?

The following PRs don't seem relevant--I'm not doing anywhere close to 60% 
utilization:

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1261567

And I'm not seeing "runts":

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1469663

I'm only seeing Framing errors (CRC/Align errors):

admin@ex3400-a> show interfaces extensive xe-0/2/0 |match 22791 
Errors: 227911, Drops: 0, Framing errors: 227911, Runts: 0, Policed 
discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, 
FIFO errors: 0, Resource errors: 0
CRC/Align errors2279110

A few seconds later, it increased to 227913:

  MAC statistics:  Receive Transmit
Total octets179536471171563221741316352
Total packets  13200126465   7010832956
Unicast packets13194022205   7004785539
Broadcast packets 52720
Multicast packets  6098988  6047417
CRC/Align errors2279130
FIFO errors  00
MAC control frames   00
MAC pause frames 00
Oversized frames 0
Jabber frames0
Fragment frames  0
VLAN tagged frames 13196813130
Code violations  0

Rate is only 24 Mbps, 2200 pps:

Manager@sw-gp1-macsec-1> show interfaces extensive xe-0/2/0 |match "bps|pps" 
  Link-level type: Ethernet, MTU: 9192, LAN-PHY mode, Speed: 10Gbps, BPDU 
Error: None, Loop Detect PDU Error: None, Ethernet-Switching Error: None, 
MAC-REWRITE Error: None,
   Input  bytes  :   17954037433802 24242136 bps
   Output bytes  :3221749625049   498504 bps
   Input  packets:  13200416854 2190 pps
   Output packets:   7010941872  830 pps



On Sun, Apr 19, 2020 at 09:37:23AM +0200, james list wrote:
> Dear experts,
> I've an EX4300 (Junos 17.3R3-S3.3) which have a constant Framing error
> counter increase also if the traffic is very low.
> Interface is connected to a WAN link from a carrier and bw is 1 Gbs but
> traffic max is actually 100 Mbs and on average 10 Mbs.
> On this interface I've enabled macsec, if I disable macsec the issue is not
> in place but unfortunately macsec is mandatory to be kept enabled.
> 
> I cannot sniff since the packet is encrypted but to me it seems that
> traffic is not lost, if I have 100 Mbs inside from WAN I see 100 Mbs
> outside to DataCenter.
> 
> Due to the fact that monitoring system contantly raise an alert, I'd like
> to know how to fix it or at least let the EX4300 do not raise the counter
> increase.
> 
> I've opened a JTAC case but they found a PR which is currently related to a
> Broadcom chipset raising framing errors during spikes (ie 70% of the
> interface bandwidth).
> 
> https://kb.juniper.net/InfoCenter/index?page=content=KB32264=METADATA
> 
> Also enabling flow-control as described in the KB do not change the
> behaviour.
> 
> I'm wondering if there could the option we're receiving some sort on
> "unknown protocol" from the carrier (I remeber Cisco has something like
> that) or could be an harware issue..
> 
> On the other side of the link, the other EX4300 (side B) do not experience
> the same issue but the traffic is mostly from side B to side A.
> 
> Here an example of the output, statistics cleared and after 1 minute I get
> 12 framing errors with 2 Mbs running on the WAN link:
> 
> @EX4300-A> show interfaces ae0 extensive
> Physical interface: ae0, Enabled, Physical link is Up
>   Interface index: 220, SNMP 

Re: [j-nsp] [EXT] Re: Decoding DDOS messages

[Chuck Anderson]

On Wed, Mar 18, 2020 at 06:36:58PM +0200, Saku Ytti wrote:
> On Wed, 18 Mar 2020 at 18:30, John Kristoff  wrote:
> 
> > Yep, I get all that.  I can tighten that up.  Care to show us how you
> > do loopback filters?
> 
> It is situational, it's hard to come up with one-size-fits-all. One
> approach would be basic skeleton, on top of which people then expand
> what they need, which would likely be also then broken. Another option
> would be to write exhaustive one, but exhaustive one necessarily has
> compromises, so then people who don't need everything still take those
> compromises.
> Really Juniper would be in the best position to automatically generate
> lo0 filter when none is provided, which would be really really good,
> not optimal, but really good. Bit of like generated-LPTS.

I disagree that they would be any good at it--it would likely be filled with 
the same holes as we've seen here given network vendors' poor history in this 
area (see bad filters taking out IS-IS, IPv6 ND, and NFS traffic on EX4500 
switches for example).  As this thread points out, getting the filters right is 
hard.  If they were hardcoded by Juniper, that would just make them opaque and 
unchangeable.  We'd all benefit from much more transparency and sharing of 
experiences.

> I'm not sure if there is a utility in public template. But it's
> something that I do occasionally think about, not just Junos or just
> firewall, but also BGP, to show how to normalise BGP behaviour (no one
> knows what their BGP policy is very accurately, as in almost every
> case BGP policy is 'what ever is vendor default', and when you have
> multivendor network, you have different policy in different  devices).

The utility is in documenting best practices and concepts in how the public 
template works so that it can be adjusted as necessary.  Having something 
documented, then claiming "that is wrong" without providing concrete 
corrections/suggestions is not helpful, especially if everyone out there is 
using the CYMRU templates or the MX book because that is the best information 
available.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [EXT] Re: Decoding DDOS messages

[Chuck Anderson]

On Wed, Mar 18, 2020 at 06:33:11PM +0200, Saku Ytti wrote:
> On Wed, 18 Mar 2020 at 18:28, Chuck Anderson  wrote:
> 
> > term bgp-inbound {
> > from {
> > source-prefix-list {
> > bgp-neighbors-v4;
> > }
> > protocol tcp;
> > source-port 1024-65535;
> This is immaterial, you don't care what this SPORT is. Be liberal.

True--the peer controls it so it doesn't matter what it is.

> > term bgp-replies {
> > from {
> > source-prefix-list {
> > bgp-neighbors-v4;
> > }
> > protocol tcp;
> > source-port bgp;
> > destination-port 1024-65535;
> This you care very much, and ephemeral range in your device is
> 49125-65535, 1024-49124 could have something listening in them.

Thanks, this is useful.  From the BSD shell it appears to be 49160-65535:

% sysctl -a | grep -E 'portrange.*(first|last)'
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 647
net.inet.ip.portrange.first: 49160
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.hifirst: 49160
net.inet.ip.portrange.hilast: 65535

> If you are in position where you only have customers and RR, no peers
> or anything else where there is no 'owner'. You should set your
> customer BGP to passive, so customer _always_ starts the BGP, you will
> never try to start it. Equally you should set your RR to passive, so
> clients always connect to RR,  RR never.
> This will allow greatly simplified filters for BGP, much safer, as
> well as trivial way to police iBGP and eBGP separately, in times when
> dddos-protection was not available.

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

Re: [j-nsp] [EXT] Re: Decoding DDOS messages

[Chuck Anderson]

On Wed, Mar 18, 2020 at 11:16:54AM -0500, John Kristoff wrote:
> On Wed, 18 Mar 2020 16:02:09 +
> Saku Ytti  wrote:
> 
> > It is completely broken, you use 'port' so you expose every port in your 
> > system.
> 
> Ha, OK thanks.  I think that would require some not so easy spoofing
> unless I'm missing something.  We can convert any statement that just
> uses port to directional, which I think will require additional rules
> to tighten it up.  Feel free to submit example configs.

To bypass your filter, just SSH using source port 179 (bgp), destination port 
22, and you are in (as long as you are a BGP neighbor for this specific term):

filter loopback-v4 {
 term bgp {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
port bgp;
}
then {
count bgp;
accept;
}
}

Fix:

/* allow inbound BGP connections */
term bgp-inbound {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count bgp;
accept;
}
}
/* allow reply packets to outbound BGP connections */
term bgp-replies {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
tcp-established;
}
then {
count bgp-replies;
accept;
}
}   
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] QSFP+ to SFP+ adapters

[Chuck Anderson]

Has anyone tried using QSFP+ to SFP+ adapters such as this one?  What software 
versions have you tried?

https://www.fs.com/products/72587.html

I'm testing these on QFX10002-36Q with 17.3R3-S7.2 and SFP+ 10G-LR modules.  
The links come up and pass LLDP and IP traffic, but DOM doesn't work:

{master:0}
root@spine-1> show interfaces diagnostics optics xe-0/0/30:0 
Physical interface: xe-0/0/30:0
Optical diagnostics   :  N/A

{master:0}
root@spine-1> show interfaces diagnostics optics xe-0/0/31:0 
Physical interface: xe-0/0/31:0
Optical diagnostics   :  N/A

{master:0}
root@spine-1> show chassis hardware 
Hardware inventory:
Item Version  Part number  Serial number Description
  PIC 0   BUILTIN  BUILTIN   36X40G
Xcvr 30   NON-JNPR   UNKNOWN
Xcvr 31   NON-JNPR   UNKNOWN


root@spine-1> show chassis pic fpc-slot 0 pic-slot 0 
FPC slot 0, PIC slot 0 information:
  Type 36X40G
  StateOnline
  PIC version 2.47
  Uptime 26 days, 40 minutes, 44 seconds

PIC port information:
 FiberXcvr vendor   Wave-
Xcvr
  Port Cable typetype  Xcvr vendorpart number   length   
Firmware
  30   unknown cable n/an/a  
0.0   
  31   unknown cable n/an/a  
0.0   


{master:0}
root@spine-1> show interfaces terse xe-*
Interface   Admin Link ProtoLocal Remote
xe-0/0/30:0 upup
xe-0/0/30:0.0   upup   inet 10.0.0.1/30 
xe-0/0/30:1 updown
xe-0/0/30:2 updown
xe-0/0/30:3 updown
xe-0/0/31:0 upup
xe-0/0/31:0.0   upup   inet 10.0.0.5/30 
xe-0/0/31:1 updown
xe-0/0/31:2 updown
xe-0/0/31:3 updown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [EXT] Any red flags on this MX240 configuration...

[Chuck Anderson]

I'd avoid the older RE-S-2000-4096-S with multiple full tables and newer code.  
I have some older lab boxes that can't really handle it, but I keep them around 
just for lab testing.  I had to trim down the full tables with AS Path Length 
filters to keep them from running out of RAM, swapping, and eventually 
crashing/core dumping.

You really want a 64-bit capable RE, such as RE-S-1800X4-32G-S or newer.  The 
rest of the hardware should be fine (as long as the newer REs support it, I 
didn't check.)

On Wed, Feb 26, 2020 at 08:46:42AM -0500, Alain Hebert wrote:
>      Beside the RE-S-2000-4096-S being EOL.  My experience with 16.2 was 
> pretty solid.
> 
>      We're planning to have 3 Full Routes BGP and the MPLS alphabet 
> soup, yadi yada.
> 
>      We don't want 2 RE since we'll use 2 MX240 and there is no point to 
> go for ISSU since the RE is EOL.
> 
>     1x CHAS-BP-MX240-S
>     1x FFANTRAY-MX240-HC
>     1x RE-S-2000-4096-S
>     1x SCBE-MX-S
>     2x PWR-MX480-1200-AC
>     1x MPC-3D-16XGE-SFPP
___
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

[Chuck Anderson]

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] Multicast duplicated on LAG with link-protection

[Chuck Anderson]

Instead of LAG you can try RTG, redundant-trunk-group.  That would block 
ingress and egress traffic on the backup link and not require STP.

On Fri, Aug 17, 2018 at 11:20:24AM +, Javier Valero wrote:
> Hello all,
> 
> We are facing a problem with one customer and multicast video streams on a 
> link aggregation.
> Maybe someone in the list know this behaviour and how to solve it.
> 
> We have EX4550 (VC) switches on different sites. We transport our customer 
> traffic over all our sites with a SVLAN assigned for them (QinQ) and give 
> them multiple access points in different places.
> In their service, they transmit some video streams with multicast, to all 
> their sites. (IPTV)
> 
> In one place, we connect with the customer with two 10G ports, each one from 
> a different equipment in our side (geographically), for redundancy.
> In their side it is only one equipment (also an EX4550).
> 
> We cannot configure a link aggregation in our side, as they are different 
> equipments. MC-LAG is not supported by EX4550.
> But our customer can configure a link aggregation in link-protection mode. By 
> this way, the avoid the use of STP for loop prevention.
> In link-protection mode, the backup interface stays in standby mode, without 
> egress traffic, but allowing ingress traffic.
> 
> The problem is the multicast traffic. As it is distributed over all the 
> links, we send the traffic on both 10G interfaces.
> The problem is that the backup interface of the link-proteccion is also 
> accepting the multicast traffic, so in the customer equipment, they have the 
> multicast duplicated.
> 
> This is causing problems on the customer side.
> 
> We don't know if the LAG is a good solution for this case, or we should tell 
> our customer that use STP.
> Maybe it is as simple as some configuration option that we don't know, or any 
> filter that can be applicated only on the interface not active.
> 
> Someone have any idea how to solve this?
> 
> Thank you very much in advance.
> 
> Best regards.
> Javier Valero.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Chuck Anderson]

I'm using just the front part, center mounted.  Works fine and is much stronger 
than the flimsy back part.

On Thu, Aug 02, 2018 at 11:07:20AM -0400, Colton Conor wrote:
> Chuck,
> 
> We put them in the center, and even cut them, but overall the 4 post rack
> brackets that come with the QFX5100 are flimsy as hell.
> 
> On Wed, Aug 1, 2018 at 6:09 PM, Chuck Anderson  wrote:
> 
> > Just put the rack brackets back towards the middle of the sides so the
> > switch is hangs further forward.  The weight is more balanced and it works
> > fine.
> >
> > On Wed, Aug 01, 2018 at 06:39:43PM -0400, Colton Conor wrote:
> > > We are constantly having to mount these larger switches to two post
> > racks.
> > > To my knowledge Juniper does not make 2 post mounting brackets for these
> > > switches. Does anyone have any recommendations on a shelf or something to
> > > hold these up? We are dealing with 19 and 23 inch racks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Chuck Anderson]

Just put the rack brackets back towards the middle of the sides so the switch 
is hangs further forward.  The weight is more balanced and it works fine.

On Wed, Aug 01, 2018 at 06:39:43PM -0400, Colton Conor wrote:
> We are constantly having to mount these larger switches to two post racks.
> To my knowledge Juniper does not make 2 post mounting brackets for these
> switches. Does anyone have any recommendations on a shelf or something to
> hold these up? We are dealing with 19 and 23 inch racks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Macsec not working with carrier ethernet link

[Chuck Anderson]

On Thu, Jul 26, 2018 at 05:24:53PM -0500, Doug McIntyre wrote:
> On Thu, Jul 26, 2018 at 05:35:42PM -0400, Chuck Anderson wrote:
> > Ask your Juniper rep for a feature that Cisco calls "WAN MACsec".
> 
> Juniper calls it MACsec.

"WAN MACsec" is a slightly modified version that Cisco made in order
to allow it to work over carrier ethernet systems that are underpinned
by protocols that block 802.1x EAPOL and 802.1ae among other L2 PDUs.
It is designed to work when you can't get cooperation from your
carrier.

If your carrier uses L2VPN, L2circuit, or some other type of
point-to-point circuit, plain MACsec should "just work" as long as
their physical port handoff to your MACsec switch is untagged.
However, if they use VPLS or some other p2mp protocol that does MAC
learning, it most likely won't bridge the 802.1x and/or 802.1ae frames
unless a special config is used on the carrier side.  Juniper needs to
be configured to tunnel the L2 protocols for example.

> The OP probably needs to make sure the firmware is correct for his platform.
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec.html
> MACsec is also a licensed product.
> Make sure the switches were ordered with the EX-QFX-MACSEC-ACC3 license.

Lack of a license won't prevent it from working, at least with 14.x
and 15.x--it will just warn you every time you commit.  That might
have changed with 17.x or 18.x.

> > On Thu, Jul 26, 2018 at 11:01:37PM +0200, james list wrote:
> > > Dear experts,
> > > I have a virtual chassis of ex4300 connected to another vc of ex4300 with 
> > > 2
> > > x 1 Gbs links provided by two carriers.
> > > 
> > > Lacp aggregation is up with just one carrier1 link encrypted with macsec,
> > > unfortunately carrier2 is not going to find the problem and macsec packet
> > > are not transported.
> > > 
> > > I sent them the 802.1ae standard and ethertype to transport but no way.
> > > 
> > > As far as I could understand they have Huawei devices.
> > > 
> > > Do you have any suggestion for me to let them verify?
> > > 
> > > Cheers
> > > James
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Macsec not working with carrier ethernet link

[Chuck Anderson]

Ask your Juniper rep for a feature that Cisco calls "WAN MACsec".

On Thu, Jul 26, 2018 at 11:01:37PM +0200, james list wrote:
> Dear experts,
> I have a virtual chassis of ex4300 connected to another vc of ex4300 with 2
> x 1 Gbs links provided by two carriers.
> 
> Lacp aggregation is up with just one carrier1 link encrypted with macsec,
> unfortunately carrier2 is not going to find the problem and macsec packet
> are not transported.
> 
> I sent them the 802.1ae standard and ethertype to transport but no way.
> 
> As far as I could understand they have Huawei devices.
> 
> Do you have any suggestion for me to let them verify?
> 
> Cheers
> James
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Chuck Anderson]

Yes.  Juniper added a configuration knob to cause PortList to work
according to the standard on Junos ELS for at least EX4300, EX3400
etc:

set switch-options mib dot1q-mib port-list bit-map

in Junos versions at least as old as 14.1X53-D45 and 15.1X53-D57.3.
It also appears to commit in Junos 17.3R2 for MX, but I haven't tested
the functionality.

On Sun, Jul 08, 2018 at 11:51:32AM -0500, Colton Conor wrote:
> Chuck,
> 
> Did this Junos issue ever get resolved?
> 
> On Wed, Dec 9, 2015 at 10:31 AM, Chuck Anderson  wrote:
> 
> > Has anyone tried to use or implement polling of the Q-BRIDGE-MIB on
> > any Juniper products, using either commercial or open source NMS
> > software or custom in-house software?  What has been your experience
> > of the Juniper support of those SNMP products to correctly report
> > Port/VLAN memberships and VLAN/MAC FDB information?
> >
> > Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a
> > working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB
> > (jnxExVlan).  Because Q-BRIDGE-MIB refers only to internal VLAN
> > indexes, you need to use both MIBs to get Port/VLAN mappings including
> > the 802.1Q VLAN tag ID (jnxExVlanTag).  This means custom software, or
> > an NMS vendor willing to implement the Juniper Enterprise MIBs.
> >
> > All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is
> > broken (doesn't follow RFC 4363 standard PortList definition, instead
> > storing port indexes as ASCII-encoded, comma separated values),
> > apparently for a very long time.  So again, you need custom software
> > or an NMS vendor willing to implement the broken Juniper version of
> > Q-BRIDGE-MIB (along with detecting which implementation is needed on
> > any particular device).  This hasn't been a problem for us and in fact
> > went unnoticed, because we never cared to poll VLAN information from
> > our MX routers, only EX switches.
> >
> > But now EX-series (and QFX-series) 13.x and newer with ELS have
> > dropped the Enterprise JUNIPER-VLAN-MIB (a good thing to not require
> > Enterprise MIBs to get the VLAN tag ID) and have adopted the broken
> > Q-BRIDGE-MIB that all the other Junos platforms have been using (a
> > very bad thing).  I'm pushing to have Juniper fix this, but their
> > concern is that it may break SNMP software that has been assuming the
> > broken Q-BRIDGE-MIB implementation for all these years.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VRF export/import of eBGP learned route

[Chuck Anderson]

I don't see this issue.  Does it only happen when you have a different ASN 
inside the VRF?

On Thu, Jun 28, 2018 at 10:44:07PM -0400, Philippe Girard wrote:
> Grettings
> 
> I'm setting up this VRF that hosts the full routing table. I have other
> peerings or remote PEs that import IX routes through eBGP as well.
> 
> The problem resides on something TAC tells me is Juniper specific, which is
> to add my own internal ASN to the as-path when using vrf-import to get a
> route that was learned through eBGP from another router to avoid potential
> loops.
> 
> So, let's say IX has AS 123 and I have AS 456 in the VRF, and my real
> inet.0 AS is 789, what is seen by another PE than the one learning the
> route directly from the IX is:
> 
> IX -- eBGP - PE1 - iBGP inet-vpn - PE2
> 
> Route as-path seen by PE1: 123 XXX YYY I
> Route as-path seen by PE2: 456 123 XXX YYY I
> 
> The behaviour is the same on all Junos routing devices in my core (MX +
> QFX5100) and I have to configure routing-options autonomous-system 456
> loops 2 for the other peers to accept routes imported by eBGP on another
> node.
> 
> Obviously, the "real" as-path is as follows, since the AS doing the
> underlay iBGP has ASN 789.
> 
> 456 [789] 456 123 XXX YYY I
> 
> I've tried independant domain but that makes me unable to filter any bgp
> attribute in vrf-imports and exports. I've also tried an "option A" peering
> between the routers and that revealed the underlay AS in the path. Using
> remove-private created a loop by re-sending the learned routes towards the
> edge.
> 
> Would anybody have an idea on how to achieve the equivalent of having and
> inet.0 iBGP mesh and importing routes without the own as prepending that
> takes place as described?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Random question: JUNOS upgrades on dual-RE routers

[Chuck Anderson]

I've been doing it for years with no ill effects.  The only thing I do
is change the backup/master designations in chassis redundancy to
clear the alarm about running on the backup RE:

mx960> show configuration chassis redundancy |display set 
set chassis redundancy routing-engine 0 backup
set chassis redundancy routing-engine 1 master
set chassis redundancy failover on-loss-of-keepalives
set chassis redundancy failover on-disk-failure
set chassis redundancy graceful-switchover

On Thu, Jun 28, 2018 at 09:28:25AM -0500, Aaron Gould wrote:
> In my testing I haven't seen an issue with leaving it like this, however,
> that is my lab testing I only turned up my dual re, (5) node 100 gig
> ring of mx960's about 2 months ago with live traffic, and haven't had to do
> any issu upgrades or anything ... so I can only speak from my lab test thus
> far... but, with re1 running as master and re0 running as backup, it's been
> fine in lab.
> 
> ...lab 240...
> root@lab-mx-240> show chassis routing-engine | grep "slot|state|elec"
>   Slot 0:
> Current state  Backup
> Election priority  Master (default)
>   Slot 1:
> Current state  Master
> Election priority  Backup (default)
> 
> ...lab 960...
> {master}
> agould@lab-960> show chassis routing-engine | grep "slot|state|elec"
>   Slot 0:
> Current state  Backup
> Election priority  Master (default)
>   Slot 1:
> Current state  Master
> Election priority  Backup (default)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Random question: JUNOS upgrades on dual-RE routers

[Chuck Anderson]

I almost always leave it running as master on the former backup.  It is good to 
exercise both REs periodically.  I haven't bothered with ISSU in a long time 
since I have node/path redundancy.

On Thu, Jun 28, 2018 at 09:12:14AM -0500, Chris Adams wrote:
> It's been a bit since I upgraded JUNOS on a dual-RE router, and I was
> refreshing my memory from the documentation.  I noticed at the end they
> list switching RE mastership back to the first RE (which of course would
> cause a second network outage)... is that really needed?  Do you do
> that, or do you leave it running on the previously-stand-by RE?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] More power questions

[Chuck Anderson]

You don't need to use the original power cords.  IEC 60320 is the
standard for power connectors.  You want an IEC 60320 C19 to C20 cord
and a PDU with C19 outlets on it to accept the C20 end of the cord:

https://www.stayonline.com/reference-iec320.aspx

On Fri, May 11, 2018 at 03:15:13PM -0700, mike+j...@willitsonline.com wrote:
> Hi,
> 
> 
>     So I want to connect an MX240 and some other gear in a single cabinet at
> 208V. The group has convinced me this can work in general. I am now trying
> to find a rack mounted or Zero-U type metered 208V PDU but I am having a
> hell of a time finding one for this application. The power cords on the
> juniper are the 6-20 type (one ground, one horizontal blade, and one
> vertical blade), and I can't seem to find any PDU that have that as outlet
> styles. I do find some that have the 'C20' type, which is what the juniper
> has for an input at the power supply side of things. Im just trying to
> understand... is the deal that I now have to order different power cords and
> try to find some commonality between them all? My other gear is likely to be
> like ASR920 or somesuch and I am  totally confused how this could or should
> all be working. Someone out there can help me I hope..
> 
> Mike-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 208v power and 110...

[Chuck Anderson]

https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/power-supply-mx240-ac.html

You can run the power supplies on either 120v or 208/240v .  If you use the 
lower voltage, you need 4 power supplies for redundancy.  If you use the higher 
voltage, you only need 2 for full redundancy.

You decide what kind of power to use by what you already have available, how 
many power supplies/circuits you have, etc.  If you are in a position to decide 
what kind of power to make available, then choose the higher voltage if 
possible--it is more efficient and requires fewer power supplies.

On Wed, May 09, 2018 at 10:38:50AM -0700, mike+j...@willitsonline.com wrote:
> Hi.
> 
> 
> I now have an MX240 router and my god what a beast this is!
> 
> My system has the 'high line' 208v power supplies and this is my first time
> dealing with non-110v ac power. I have the two power supplies installed and
> I am thinking I may want to add a switch to this configuration and to date,
> I have no experience with any switches using this high of juice. I'm looking
> for something with 10G sfp+ interfaces and I'm just at a loss as this is a
> different world. Is the strategy in this situation that I need to commit to
> everything being high voltage, or do I get a power strip of some kind to
> feed my 110v stuff?
> 
> 
> Mike-
> 
> -- 
> Mike Ireton
> Your Town Online, Inc
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Equipment Labelling

[Chuck Anderson]

We think a M3.5-.07 is the right screw, but a 6-32 fits well enough as well.

On Sat, May 05, 2018 at 10:31:23PM +, Sweetser, Frank E wrote:
> So after a few rounds of design, Chuck and I came up with this simple bracket 
> that mounts onto the threaded stud in the middle of the mounting brackets for 
> many (all?) of the 1U EX and QFX switches:
> 
> 
> https://www.thingiverse.com/thing:2893741
> 
> 
> If you've got a 3D printer handy, this should give you an 18mm by 40mm space 
> for labelling.  If you don't have a 3D printer handy, now's your chance to 
> convince your boss to buy one for work purposes 
> 
> 
> Frank Sweetser
> Director of Network Operations
> Worcester Polytechnic Institute
> "For every problem, there is a solution that is simple, elegant, and wrong." 
> - HL Mencken
> 
> 
> 
> From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> on behalf of 
> Sweetser, Frank E <f...@wpi.edu>
> Sent: Thursday, May 3, 2018 10:07 PM
> To: Anderson, Charles R; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Equipment Labelling
> 
> That should be pretty straightforward to slap together something simple.  
> Anyone know the actual size of the threaded hole?
> 
> 
> Frank Sweetser
> Director of Network Operations
> Worcester Polytechnic Institute
> "For every problem, there is a solution that is simple, elegant, and wrong." 
> - HL Mencken
> 
> 
> 
> From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> on behalf of Chuck 
> Anderson <c...@wpi.edu>
> Sent: Thursday, May 3, 2018 9:39 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Equipment Labelling
> 
> Nice.  That screw hole on the front of the rack ear is screaming for
> someone to make a 3D printed label tag.
> 
> On Thu, May 03, 2018 at 08:19:59AM -0500, Chris Wopat wrote:
> > Our current QFX5100 label method:
> >
> > https://i.imgur.com/kRVojXk.jpg
> >
> > We have a label on both the left and right side, sticking out as a tab on
> > left and folded over on right. in both cases the label was adhered prior to
> > putting the ears on.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Equipment Labelling

[Chuck Anderson]

Nice.  That screw hole on the front of the rack ear is screaming for
someone to make a 3D printed label tag.

On Thu, May 03, 2018 at 08:19:59AM -0500, Chris Wopat wrote:
> Our current QFX5100 label method:
> 
> https://i.imgur.com/kRVojXk.jpg
> 
> We have a label on both the left and right side, sticking out as a tab on
> left and folded over on right. in both cases the label was adhered prior to
> putting the ears on.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Chuck Anderson]

It depends if the DWDM gear is purely L1 or if it is doing OTN switching (it 
will be doing OTN if you are mapping 1 or more lower rate client side signals 
into 1 or more higher rate line side signals).  The latter deals with framing 
and would have MTU limits.  The former would have a 1:1 mapping from each 
client side wave to a each line side wave.

On Tue, Apr 17, 2018 at 07:24:41AM -0500, Aaron Gould wrote:
> This issue is my turning up new MX960's that are simply connected together 
> with Ciena 6500 DWDM for me to have an MTU issue via DWDM is actually a 
> surprise to me.  I pretty much always envisioned wave/lamda dwdm as darn near 
> like having an actual fiber cable... no, not the case apparently... I'm 
> surprised that the ciena dwdm service in this case is actually imposing an 
> Ethernet mtu limitation !  wow, the more I think on it, the more I'm 
> surprised about it... previously my older asr9k 15-node mpls ring was via 
> fujitsu flashwave dwdm and I don't recall this occurring 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 and copper SFP?

[Chuck Anderson]

Back-in-the-day we had fe-x/x/x for 10/100 Mbps ports.  Now we have ge-x/x/x 
that can take a 100 Mbps SFP, but the name doesn't change to fe-x/x/x AFAIK.  
So there is precedent for the names not changing when the speed changes.

But I do like having the ability to match ports based on speed, e.g. find all 
"uplink" ports by assuming ge-* are access ports and xe-* are uplinks.  
Patterns can be used within configuration groups and interface-ranges.

On Thu, Apr 05, 2018 at 01:38:46PM +, Nelson, Brian wrote:
> Port-foo is so archaic. 
> It's an interface, inf-x/x/x would be more germane.
> 
> Brian
> 
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Ola Thoresen
> Sent: Thursday, April 05, 2018 3:59 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] MX204 and copper SFP?
> 
> On 05. april 2018 10:44, Saku Ytti wrote:
> 
> > Since of the fathers.
> >
> > 'Cisco did it'.
> >
> > I also see no value in it.
> 
> Don't we all love that "linux" changed from eth0, eth1, eth2... to beautiful 
> stuff like wwp0s20u4 and enp0s25...
> 
> Just call them port-x/x/x and be done with it.
> 
> 
> /Ola (T)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Power ON?

[Chuck Anderson]

It makes sense on dual-RE platforms:

mx960> request vmhost power-on other-routing-engine

On Tue, Apr 03, 2018 at 07:41:57AM -0500, Aaron Gould wrote:
> Seeing it on my MX960 also...
> 
> agould@ 960> request vmhost ?
> Possible completions:
>   cleanup  RE vmhost cleanup /var/tmp, /var/crash and /var/log
>   file-copyCopy file from vmhost to vjunos
>   halt Halt the software on RE
>   hard-disk-test   Run smartd self tests on hard disks
>   power-offPower off the software on RE
>   power-on Power on the system
>   reboot   Reboot RE vmhost
>   snapshot Create a vmhost recovery snapshot
>   software Perform vmhost software extension or upgrade
>   zeroize  Erase all data, including configuration and log files
> 
> 
> -Aaron
> 
> 
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Ola Thoresen
> Sent: Tuesday, April 3, 2018 1:59 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Power ON?
> 
> On 02. april 2018 21:00, Chris Adams wrote:
> 
> > Working on a new MX204, I noticed this:
> >
> > user@router> request vmhost power-o?
> > Possible completions:
> >power-offPower off the software on RE
> >power-on Power on the system
> >
> > Really?  The RE VM can tell the VM host to power ON? :)
> 
> We noticed the same thing, and had a good laugh last week.
> 
> Another fun thing is that if you just do a "vmhost halt", you can restart it 
> by pushing a button in the serial console.  But if you do a power-off, you 
> need to pull the power cord (no "on/off" switch in the PSUs or chassis) .
> 
> 
> /Ola (T)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Power ON?

[Chuck Anderson]

Cool.  Is there another parameter specify which VM to power-on, maybe a service 
VM?

I wonder why the MX150 doesn't have any vmhost commands.  It would come in 
handy for some issues.

On Mon, Apr 02, 2018 at 02:00:33PM -0500, Chris Adams wrote:
> Working on a new MX204, I noticed this:
> 
> user@router> request vmhost power-o?
> Possible completions:
>   power-offPower off the software on RE
>   power-on Power on the system
> 
> Really?  The RE VM can tell the VM host to power ON? :)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [c-nsp] Meltdown and Spectre

[Chuck Anderson]

Umm, you type the password into the box, right?  The box stores that password 
in memory so that it can build a TACACS+ request packet to send to the server?  
Unless you are using SSH keys in lieu of passwords.

On Mon, Jan 08, 2018 at 05:16:01PM +0100, Sebastian Becker wrote:
> The password will not be seen on the box itself so no problem. The users are 
> tacacs+ authorized/authenticated.
> Most scenarios are much easier to accomplish by using the already granted 
> rights on the boxes per user then using these kinds of attack vectors opened 
> by Meltdown and Spectre.
> 
> Our boxes simply do not run other code than that what is delivered by the 
> vendors.
> 
> — 
> Sebastian Becker
> s...@lab.dtag.de
> 
> > Am 08.01.2018 um 09:32 schrieb Thilo Bangert :
> > 
> > Den 06-01-2018 kl. 19:49 skrev Sebastian Becker:
> >> Same here. User that have access are implicit trusted.
> > 
> > You do have individual user accounts on the equipment, right?
> > 
> > The idea of having secure individual logins goes down the drain with 
> > Meltdown and Spectre. You want to be sure that a person logged into a box 
> > cannot snoop the password of a co-worker.
> > 
> > Meltdown and Spectre are relevant on all affected computing equipment.
> > 
> > > So no need for panic.
> > 
> > The usefulness of panic has been degrading the past couple of thousand 
> > years ;-)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] What is your experience with the EX2200

[Chuck Anderson]

The most current supported software on EX2200 is 12.3R12--there were
some issues with insufficient flash space for 15.1, so they rolled
back the recommended release to 12.3R12.

They are fairly solid boxes, although I do notice occasional STP
issues on them (Root Bridge changes, Loop Protect activating),
probably when the CPU gets busy and misses some STP BPDUs.  I haven't
seen this issue with our EX4200s.  Luckily it isn't service impacting
in our deployment, since we don't have any redundant links (loops) and
it recovers quickly.

On Fri, Dec 08, 2017 at 02:06:26PM -0500, Matt Freitag wrote:
> For some reason I also thought the EX2200 EOL date was coming up in a year
> or two but cannot find any sources to prove that.
> 
> My only complaints about the box:
> 
>- Sometimes when they lose power abruptly it corrupts the file system on
>the primary partition. Best way I know of to solve this is a complete
>reinstall of the OS on the routing engine.
>   - This does not affect forwarding at all since the actual packet
>   forwarding happens on a different unit of the box. You'll only see this
>   when you try to SSH to it, for example, and it rejects your attempts by
>   closing your connection.
>- It takes these things a few seconds to commit their config, but I
>think the routing engine runs on an 800MHz CPU and 512MB of RAM. They're
>also quite slow to SSH to, again due to the lack of CPU and memory.
> 
> Otherwise the EX2200 is a really solid platform, but as Saku said Juniper
> moved to the EX2300 a long time ago.
> 
> Matt Freitag
> Network Engineer
> Information Technology
> Michigan Technological University
> (906) 487-3696 <%28906%29%20487-3696>
> https://www.mtu.edu/
> https://www.mtu.edu/it
> 
> On Fri, Dec 8, 2017 at 1:54 PM, Saku Ytti  wrote:
> 
> > Only buy EX2200 if you're buying gray and get them really cheap.
> > Juniper has long since moved to entirely different platform EX2300.
> >
> > On 8 December 2017 at 19:41, Dan White  wrote:
> > > We're considering purchasing these switches for our branch offices. Our
> > > needs include PoE, and basic routing functionality. What's been your
> > > experience with these switches?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX3400 or EX4600, and HPE FlexFabric-20/40, QSFP+ DAC's

[Chuck Anderson]

On Tue, Nov 21, 2017 at 06:28:07AM -0800, Emille Blanc wrote:
> Hello folks,
> 
> Trudging through the woes that are cross-vendor compatibility issues, and 
> failing completely at getting a link between an EX3400 or EX4600, and an HPE 
> FlexFabric-20/40 F8 card in our c7000 enclosure using an HPE branded QSFP+ 
> 3mtr DAC.  That is to say, Juniper on one side, HPE on the other.
> As an added bonus, the HPE module seems to be allergic to Juniper's QSFP 
> completely.
> 
> After the inevitable "It's not us, it's them" back-and-forth between JTAC and 
> HPE Support, I'm looking for any success (or failure) stories from the 
> community.
> 
> We've been testing with a pair of HPE DACs, and they each work fine when we 
> loop it to two QSFP+ slots in the same chassis/module.
> 
> Has anyone been successful in making such a connection in the wild?

Buy cheap QSFP+ optics and use fiber?
___
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

[Chuck Anderson]

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] VCCP

[Chuck Anderson]

Virtual Chassis shares the management, control, and data planes across the two 
routers.  I don't like that from a high-availability standpoint.  The two 
routers are tightly coupled with software versions, bootup, etc.

MC-LAG shares some of the control and data planes via ICCP but maintains 
separate routing & management planes so it is better in that respect.

But IMO the best architecture is a L3 routed one.  If you need L2 services to 
extend across the L3 then use MPLS services such as EVPN.

On Thu, Nov 16, 2017 at 08:57:42AM -0500, harbor235 wrote:
> Has anyone deployed VCCP on the MX platform as a solution for a pair of
> edge routers that traditionally would support a BGP multihomed architecture?
> 
> I am interested if VCCP is a viable solution to replace the traditional
> dual homed architecture and if there are any pros and cons. Are there
> limitations with VCCP? Operational issues? EGP and/or IGP limitations,
> etc
___
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

[Chuck Anderson]

My testing has revealed that it works, as long as the service provider (MX) is 
doing something like e-line/l2circuit/CCC rather than bridging.  I even got it 
to work with ethernet-ccc on the MX port facing the EX4300 and vlan-ccc on the 
MX port facing the core/WAN.

However I've now run into an issue where I can only get a single MACsec 
connection working on the EX4300's.  As soon as I add a 2nd one, it fails to 
come up.  If I then reboot, neither one comes up.  If I deactivate the 2nd one, 
the 1st one comes up.

On Tue, Oct 31, 2017 at 07:30:35PM +, Nick Cutting wrote:
> I am also interested in this - my carriers keep saying "try it"
> 
> I have the config now - still have not tested - but I'm moving many of my 
> customer P2P links (hosted by carriers) to nexus switches that don't support 
> macsec.
> 
> Is anyone in the enterprise doing this over e-line services? 
> 
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Chuck Anderson
> Sent: Friday, October 27, 2017 9:39 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] MACsec over a service provider
> 
> This Message originated outside your organization.
> 
> Destination MAC 01:80:c2:00:00:03, EtherType 0x888e (ieee8021x) is eaten by 
> the PE router (MX480).  I'm not sure about the ASR9k at the other end of the 
> production scenario--it may have the same trouble.
> 
> My lab is like this, with the EX2200 substituting for the ASR9k.  The idea is 
> to have MACsec between the EX4300s, with the middle being transparent to it.
> 
> I got this working:
> 
> EX4300---EX2200---EX4300
> 
> For the EX2200, I had to configure layer2-protocol-tunneling to allow the 
> EAPOL 802.1x through:
> 
> vlans {
> MACSEC-TRANSPORT {
> vlan-id 10;
> ##
> ## Warning: requires 'dot1q-tunneling' license
> ##
> dot1q-tunneling {
> layer2-protocol-tunneling {
> all;
> }
> }
> }
> }
> 
> MACsec comes up fine on both EX4300s and I can ping between them.
> 
> 
> But this fails:
> 
> EX4300---EX2200---MX480---EX4300
> 
> I'm doing simple bridging through the MX, but the MX doesn't support the 
> mac-rewrite needed (ieee8021x).  Anyone have any clever ideas to work around 
> that limitation?
> 
> On Fri, Oct 27, 2017 at 05:40:57PM +0300, Elijah Zhuravlev wrote:
> > Hello
> > 
> > Ethertypes 0x888e and 0x88e5 should be supported by the switching hw, 
> > no any other special requirements.
> > Btw keep in the mind macsec overhead, +32.
> > 
> > regards, Eli
> > 
> > On Fri, 27 Oct 2017 10:23:01 -0400
> > Chuck Anderson <c...@wpi.edu> wrote:
> > 
> > > 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] MACsec over a service provider

[Chuck Anderson]

Destination MAC 01:80:c2:00:00:03, EtherType 0x888e (ieee8021x) is
eaten by the PE router (MX480).  I'm not sure about the ASR9k at the
other end of the production scenario--it may have the same trouble.

My lab is like this, with the EX2200 substituting for the ASR9k.  The
idea is to have MACsec between the EX4300s, with the middle being
transparent to it.

I got this working:

EX4300---EX2200---EX4300

For the EX2200, I had to configure layer2-protocol-tunneling to allow
the EAPOL 802.1x through:

vlans {
MACSEC-TRANSPORT {
vlan-id 10;
##
## Warning: requires 'dot1q-tunneling' license
##
dot1q-tunneling {
layer2-protocol-tunneling {
all;
}
}
}
}

MACsec comes up fine on both EX4300s and I can ping between them.


But this fails:

EX4300---EX2200---MX480---EX4300

I'm doing simple bridging through the MX, but the MX doesn't support
the mac-rewrite needed (ieee8021x).  Anyone have any clever ideas to
work around that limitation?

On Fri, Oct 27, 2017 at 05:40:57PM +0300, Elijah Zhuravlev wrote:
> Hello
> 
> Ethertypes 0x888e and 0x88e5 should be supported by the switching hw,
> no any other special requirements. 
> Btw keep in the mind macsec overhead, +32.
> 
> regards, Eli
> 
> On Fri, 27 Oct 2017 10:23:01 -0400
> Chuck Anderson <c...@wpi.edu> wrote:
> 
> > 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

[j-nsp] MACsec over a service provider

[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

[j-nsp] BGP VPLS - Multi-homing

[Chuck Anderson]

On Wed, Oct 11, 2017 at 12:23:16PM -0500, Aaron Gould wrote:
> (I really should change this subject heading to "BGP VPLS - Multi-homing"
> since that's the more specific vpls version we are discussing at this
> point... FEC 128 / RFC 4761)
> 
> hey look what I just found ..
> https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/vp
> ns-configuring-vpls-multihoming.html
> "When two PE routers use the same site ID, VPLS assumes multihoming behavior
> by default."  .so I guess that's why I'm seeing good multi-homing behavior
> without configuring that command ".site multi-homing"
> 
> But interestingly, they mention a few things with that multi-homing command.
> they say it tracks bgp neighborship, but I don't know what they mean by
> this. "such as to prevent isolation of the PE router from the core or split
> brain."  Not sure how that *prevents* isolation.  If you lose bgp, aren't
> you isolated ?!
>
> Also, I'm wondering what the scenario is that they mention in this statement
> . "There are scenarios, however that require preventing of BGP peer
> tracking, such as in a two-PE-router topology. In such cases, multihoming
> should not be explicitly configured as it can break node redundancy."  How
> would config'ing "protocol vpls site test multi-homing" break node
> redundancy ?

Well gee, I think you found my problem I reported here:

https://lists.gt.net/nsp/juniper/60351

I'm going to try removing the multi-homing statement to see if it fixes my 
issue.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] *humor*. MX480 sound card options

[Chuck Anderson]

On Mon, Oct 09, 2017 at 11:34:52PM +, Matthew Crocker wrote:
> 
> 
> I’m performing an upgrade on my MX480 NG-REs and I see this scroll through 
> the console:
> 
> ALSA: Storing mixer settings...
> /usr/sbin/alsactl: save_state:1590: No soundcards found...
> 
> 
> So, the question is, what sound card options can I get on my MX480?  Is there 
> a 3D sound option for ‘SonicIP’?

Try a USB sound card and let us know how it goes :-)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5048 - 40 gbps ER 40 km optic

[Chuck Anderson]

Insert a 3dB or 7dB attenuator pad for lab testing.  In a pinch (no pun 
intended) you can take a fiber jumper and bend it tightly into a loop (like 
1/4" diameter) to attenuate the signal, but I would use a disposable jumper for 
that.  Use a twist tie or similar to hold it in the tight loop.  Monitor the 
receive power level while adjusting the tightness of the loop until it is lower 
than -5 dBm but higher than -20 dBm.

On Wed, Oct 04, 2017 at 07:04:05PM -0500, Aaron Gould wrote:
> Well, when the transport eng I work with found out that I had these two 40km 
> optics connected with a 3’ jumper he ran into the lab to disconnect it…. So 
> that’s probably why you see no light right now…. Lemme get back into the 
> office Monday and we will go from there… yeah, as I mentioned I’m working 
> with my Juniper account SE on this, so he may update support matrix if he 
> discovers they are good…. I dunno.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RSTP best practices on ELS switching (EX2300/3400/4300)

[Chuck Anderson]

Yes, I'm using bpdu-block-on-edge with disable-timeout 3600 (1 hour).
I'm also using mac-limits with port shutdown.

Until a location is ready for IPv6:

set interfaces interface-range EDGE member-range ge-0/0/0 to ge-0/0/47
set interfaces interface-range EDGE unit 0 family ethernet-switching filter 
input DROP-IPv6
set interfaces interface-range EDGE unit 0 family ethernet-switching filter 
output DROP-IPv6
set firewall family ethernet-switching filter DROP-IPv6 term DROP-IPv6 from 
ether-type 0x86dd
set firewall family ethernet-switching filter DROP-IPv6 term DROP-IPv6 then 
discard
set firewall family ethernet-switching filter DROP-IPv6 term DROP-IPv6 then 
count DROP-IPv6
set firewall family ethernet-switching filter DROP-IPv6 term ACCEPT then accept

Storm-Control set to 100 Mbps (this needs to be adjusted according to normal 
baseline):

set interfaces interface-range EDGE unit 0 family ethernet-switching 
storm-control SC-EDGE
set forwarding-options storm-control-profiles SC-EDGE all bandwidth-level 10

BPDU block:

set protocols layer2-control bpdu-block disable-timeout 3600
set protocols rstp interface EDGE edge
set protocols rstp bpdu-block-on-edge

MAC-limit (adjust for normal baseline of # of MACs per port):

set switch-options interface EDGE interface-mac-limit 16
set switch-options interface EDGE interface-mac-limit packet-action shutdown

On Thu, Sep 28, 2017 at 09:43:26PM +1000, Chris Lee via juniper-nsp wrote:
> Hi All,
> 
> Interested to know what others have as their RSTP best practice setups for
> access-layer switches in the ELS platform, specifically EX2300/3400/4300's
> 
> Until today I had thought that having defined my access interfaces (to end
> devices like PC's/printers etc) with "edge" and "no-root-port" was offering
> protection from people plugging in random stuff like other switches.
> 
> After some more research it looks like I should probably be defining
> bpdu-block-on-edge,so interested to know if others are defining this along
> with a disable-timeout setting like 5 minutes, or do you not generally
> bother with a disable-timeout and manually clear these if they occur ?
> 
> Options I'm looking at defining :-
> 
> [edit protocols]
> +   layer2-control {
> +   bpdu-block {
> +   disable-timeout 300;
> +   }
> +   }
> [edit protocols rstp]
> +   bpdu-block-on-edge;
> 
> Thanks,
> Chris
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Software Upgrade failures on EX4200

[Chuck Anderson]

Personally I would stick with 12.3.  They came out with another service 
release, 12.3R12-S6.

On Thu, Sep 28, 2017 at 03:26:36AM +1000, Kamal Dissanayaka wrote:
> Hi Jason,
> 
> Thanks for the response,
> This happened to us irrespective of version, some switches were from
> 12.3.r9 to 15.1.r2.9 and some were from 15.1.r2.9 to 15.1.R6s2.1  as far as
> I remember.
> 
> 
> Same thing here with the JTAC support, they say go to the site and upgrade
> using USB if the device fails during upgrade. They don't understand
> practical difficulties when you have frequent failures.
> 
> Best Regards
> 
> Kamal
> 
> 
> 
> 
> On Wed, Sep 27, 2017 at 11:58 PM, Jason Healy  wrote:
> 
> > On Sep 27, 2017, at 1:56 AM, Kamal Dissanayaka 
> > wrote:
> > >
> > > The issue with this is remote upgrades. Remote upgrades fails randomly
> > and
> > > some has to visit the sit to fix it. Is there any way fix it ?
> >
> > What version were you running previously?  We bumped all of our 4200s from
> > 12.x to 15.x and got badly burned with switches that didn't come up.
> >
> > JTAC told us (after the fact) that we needed to be on the VERY LATEST 12
> > series before making the upgrade or else there might be 'issues'.  Ended up
> > having to do a format reinstall from USB on about a third of the switches.
> >
> > Jason
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] logical system in production - MX960

[Chuck Anderson]

On Mon, Sep 25, 2017 at 07:10:47AM -0500, Aaron Gould wrote:
> A few questions about logical systems. related to a new 5-node MX960 100 gig
> ring.
> 
> Do you all use logical systems in your production environment ?

I do.

> Do you contain your core P functions inside of an lsys ?

My network is rather small and combines P/PE functions, so I guess the
answer is "yes".

> Is the master/hosting lsys completely absent of any and all provider routes,
> and does it only contain a simply management interface (fxp) and not much
> more than that ?

No, I use the main systems to run my LAN and a single WAN lsys on each
MX480.  They are interconnected by my firewalls.

> If you were deploying a 5-node MX960 mpls core for an ISP, would you deploy
> lsys's from the start and put the core routing inside an lsys ?

Maybe, but there are some limitations.  Some things don't work in
lsys, such as port-mirroring & inline-jflow sampling (although support
for the latter is supposed to be there in the latest Junos
releases--it was buggy/crashy and I had to turn it off).

https://www.juniper.net/documentation/en_US/junos/topics/concept/logical-systems-restrictions.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Moving onto EX2300

[Chuck Anderson]

I don't normally rely on VRs on my access layer devices, but it comes
in handy once in a while for troubleshooting to add a l3-interface to
a VLAN, but keep the routing separate from the in-band management
VLAN.  For this I use a routing-instance of instance-type
virtual-router.  I can then use "ping routing-instance FOO ...".

On Wed, Sep 20, 2017 at 09:30:32PM +0200, Pavel Lunin wrote:
> VRs on a basic enterprise access switch? You guys are really crazy.
> 
> "Gustav Ulander" :
> 
> Yea lets make the customers job harder partly by not supporting old
> features in the next incarnation of the platform (think VRF support) . Also
> lets not make them work the same so that the customer must relearn how to
> configure them.
> Excellent way of actually pushing the customer to also look at other
> platforms...
> 
> //Gustav
> 
> -Ursprungligt meddelande-
> Från: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] För William
> Skickat: den 20 september 2017 21:10
> Till: Chris Morrow 
> Kopia: juniper-nsp@puck.nether.net
> Ämne: Re: [j-nsp] Moving onto EX2300
> 
> Thanks to all the replies so far!
> 
> Regarding a VC Licence -
> https://www.juniper.net/documentation/en_US/junos/topics/
> concept/ex-series-software-licenses-overview.html#jd0e59
> 
> Here are the features which require a EFL:
> 
> Bidirectional Forwarding Detection (BFD) IGMP (Internet Group Management
> Protocol) version 1 (IGMPv1), IGMPv2, and
> IGMPv3
> IPv6 routing protocols: Multicast Listener Discovery version 1 and 2 (MLD
> v1/v2), OSPFv3, PIM multicast, VRRPv6 Multicast Source Discovery protocol
> (MSDP) OSPF v2/v3 Protocol Independent Multicast (PIM) dense mode, PIM
> source-specific mode, PIM sparse mode Real-time performance monitoring
> (RPM) RIPng (RIPng is for RIP IPv6) Virtual Router Redundancy Protocol
> (VRRP)
> 
> Which seems straight forward, but they have this bit at the end -
> Note: You require a paper license to create an EX2300 Virtual Chassis. If
> you do not have a paper license, contact Customer Support.
> 
> 
> And looking at the EX2300 packing list:
> 
> * Paper license for Virtual Chassis (only for the models EX2300-C-12T-VC,
> EX2300-C-12P-VC, EX2300-24T-VC, EX2300-24P-VC, EX2300-48T-VC, and
> EX2300-48P-VC)
> 
> So it appears I may need to ensure i'm ordering EX2300-48P-VC if I want to
> stack 'em, I need to check the finer details with Juniper.
> 
> Cheers,
> 
> William
> 
> 
> On 20 September 2017 at 19:18, Chris Morrow  wrote:
> 
> > At Wed, 20 Sep 2017 17:03:21 +,
> > Raphael Maunier  wrote:
> > >
> > > Not supported at all.
> > >
> > > According to a meeting last week, hardware limitation … EX2200 or
> > > 3400 but no support of BGP, if bgp is needed EX3300 / 4300
> > >
> >
> > I found the 3400's are painfully different from 3300/3200's.. with
> > respect to vlans, trunks and access port assignment into said vlans..
> > and actually getting traffic to traverse a trunk port to an access
> > port.
> >
> > this coupled with what seems a requirement to enable an IRB interface
> > to attach the management ip address to seems ... wonky.
> >
> > I don't find the docs online particularly enlightening either :) I
> > have a 3300 config, it should 'just work' on a 3400.. I would have
> > expected anyway.
> >
> > also, I don't think you can disable the VC functions in the
> > 3400:
> > @EX3400-0401> show chassis hardware
> > Hardware inventory:
> > Item Version  Part number  Serial number Description
> > ChassisNX0217020007  EX3400-48T
> > Pseudo CB 0
> > Routing Engine 0  BUILTIN  BUILTIN   RE-EX3400-48T
> > FPC 0REV 14   650-059881   NX0217020007  EX3400-48T
> >   CPU BUILTIN  BUILTIN   FPC CPU
> >   PIC 0  REV 14   BUILTIN  BUILTIN   48x10/100/1000
> > Base-T
> >   PIC 1  REV 14   650-059881   NX0217020007  2x40G QSFP
> >   PIC 2  REV 14   650-059881   NX0217020007  4x10G SFP/SFP+
> > Xcvr 0   REV 01   740-021309   FS40531D0014  SFP+-10G-LR
> > Xcvr 1   REV  740-021309   FS40531D0015  SFP+-10G-LR
> > Power Supply 0   REV 05   640-060603   1EDV6486028   JPSU-150W-AC-AFO
> > Power Supply 1   REV 05   640-060603   1EDV7021509   JPSU-150W-AC-AFO
> > Fan Tray 0   Fan Module,
> > Airflow Out (AFO)
> > Fan Tray 1   Fan Module,
> > Airflow Out (AFO)
> >
> > (port xe-0/2/0 and xe-0/2/1 are what I'd like to disable)
> >
> > @EX3400-0401> request virtual-chassis vc-port delete pic-slot 2 port 0
> > error: interface not a vc-port
> > @EX3400-0401> request virtual-chassis vc-port delete pic-slot 2 port 1
> > error: interface not a vc-port
> >
> > of course, possibly they are not vc-ports, and are only acting like
> > 3300 vc ports 

Re: [j-nsp] Moving onto EX2300

[Chuck Anderson]

Is virtual-router at least supported if not full VRF?

On Wed, Sep 20, 2017 at 05:26:27PM +0100, Olivier Benghozi wrote:
> New additional licence needed to stack (VirtualChassis), VRF not supported.
> 
> > On 20 sept. 2017 at 17:16, William  wrote :
> > 
> > Due to the ex2200 going eol/eos we are looking at the EX2300 - can anyone
> > share their experience with this model? Anything to watch out for?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Odd issue with logical-system

[Chuck Anderson]

On Mon, Sep 18, 2017 at 01:12:36PM +, Eric Van Tol wrote:
> > Have you tried enabling BGP traceoptions to see if that logs more useful
> > diagnostics?
> 
> Yes, per my first message:
> 
> >I also see absolutely nothing when I enable traceoptions on the 
> >peer in LS1 and with MX2 attempting to contact LS1
> 
> Nothing helpful in those, with all flags enabled, both sides show the same 
> thing:
> 
> bgp_connect_complete: error connecting to x.x.x.x (Internal AS x): Socket 
> is not connected
> 
> Again, I don't even see a TCP SYN being sent in the 'monitor traffic 
> interface' output on the only active interface in LS1, as though it's being 
> dropped before it even hits the wire.

Is the correct interface and unit number specified inside the logical-system on 
both sides?  Have you tried deleting the config, commit full, rollback?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Odd issue with logical-system

[Chuck Anderson]

On Sun, Sep 17, 2017 at 01:43:31PM +, Eric Van Tol wrote:
> Thanks, I did check all this and re-entered MD5 keys by pasting in on all 4 
> routers. The fact that only one session out of the bunch isn't coming up 
> indicates that it's not an MD5 or ASN issue, though, as they are all defined 
> within groups and not individual definitions within the neigbhor statements. 
> Traceoptions simply show that the attempts timed out. LS1 is not responding 
> at all to the incoming request from MX2, nor is it even *sending* a TCP SYN 
> to MX2 in its own supposed session request (LS1 is not in passive mode). 
> 
> IPv6 peering between all four nodes is working, too.
> 
> I feel like this is going to end up a JTAC ticket, but wanted to know if 
> anyone else had ever seen this behavior. I may end up rebooting MX1 to see if 
> that fixes it, but I'd prefer not to do the Roy and Moss Method if I can help 
> it.

Have you tried enabling BGP traceoptions to see if that logs more useful 
diagnostics?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX 3300 vs EX 3400 for access layer

[Chuck Anderson]

On Thu, Sep 14, 2017 at 10:54:54AM -0500, John Kristoff wrote:
> Typically these devices can last out in the field for five or more
> years.  There are at least two potential concerns about this series of
> switches.  One, when stacking them into a larger virtual chassis (i.e.
> six or more), the management plan performance appears to be horribly
> slow and burdened by this extra maintenance work.  Two, will these
> devices sustain the future PoE requirements that we may see from edge
> devices?

For your large VC concern, break up the VCs so none is larger than 4
or 5 units and interconnect multiple VCs at each site with LAGs.
We've done this with some EX4200 VCs that were 8-10 units for the same
reasons.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4200: Ricoh printers, DHCP Snooping, dot1x Dynamic VLAN assignments

[Chuck Anderson]

Is anyone using EX4200 with DHCP Snooping + dot1x Dynamic VLAN
assignments?  I appear to be hitting bugs where some devices can't
DHCP (such as Ricoh printer/copier/fax/scanners), or once they do DHCP
they can't communicate through the EX4200 switch port.  It seems I can
make things work better by statically configuring the VLAN on the port
rather than relying on dot1x RADIUS to dynamically assign the VLAN.

I've also discovered that all VLANs that might end up being assigned
to a port either statically or dynamically or via the VOIP VLAN
feature must have matching examine-dhcp/ip-source-guard/arp-inspection
settings under ethernet-switching-options secure-access-port.  The
easiest way to accomplish this is to use "ethernet-switching-options
secure-access-port vlan all" rather than specifiy individual VLANs.

But even then I'm still having problems when combined with RADIUS
Dynamic VLANs.  I'm using 12.3R12-S3.1.

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

Re: [j-nsp] RES: RES: QFX 5100 and Q-in-Q

[Chuck Anderson]

I'm using Q-in-Q as a tap aggregation function.  Port mirrors and/or
optical taps from other devices are connected to QFX5100 ports which
encapsulate the foreign traffic with Q-in-Q, then flood the traffic to
all ports in the same outer VLAN.  Analyzers are connected to the
output ports.  It may be that L2 protocols like PVST+ are not passing
through, but that doesn't matter much for my use case:

set interfaces xe-0/0/0 description "MIRROR1 INPUT from device foo"
set interfaces xe-0/0/0 flexible-vlan-tagging
set interfaces xe-0/0/0 native-vlan-id 2
set interfaces xe-0/0/0 mtu 9216
set interfaces xe-0/0/0 encapsulation extended-vlan-bridge
set interfaces xe-0/0/0 unit 2 vlan-id-list 1-4094
set interfaces xe-0/0/0 unit 2 input-vlan-map push
set interfaces xe-0/0/0 unit 2 input-vlan-map vlan-id 2
set interfaces xe-0/0/0 unit 2 output-vlan-map pop
set interfaces xe-0/0/0 unit 2 family ethernet-switching filter output DISCARD

set interfaces xe-0/0/24 description "MIRROR1 OUTPUT to analyzer bar"
set interfaces xe-0/0/24 flexible-vlan-tagging
set interfaces xe-0/0/24 mtu 9216
set interfaces xe-0/0/24 encapsulation extended-vlan-bridge
set interfaces xe-0/0/24 unit 2 vlan-id-list 1-4094
set interfaces xe-0/0/24 unit 2 input-vlan-map push
set interfaces xe-0/0/24 unit 2 input-vlan-map vlan-id 2
set interfaces xe-0/0/24 unit 2 output-vlan-map pop
set interfaces xe-0/0/24 unit 2 family ethernet-switching filter input DISCARD

set vlans MIRROR1 interface xe-0/0/0.2
set vlans MIRROR1 interface xe-0/0/24.2
set vlans MIRROR1 switch-options no-mac-learning

On Sat, Mar 25, 2017 at 12:22:40AM +, Alexandre Guimaraes wrote:
> Chuck, 
> 
> 
>Could you please share portion of your QinQ configuration?  In my tests, 
> facing customer side, used:
> 
> set vlans S-VLAN-200 vlan-id 200
> set vlans S-VLAN-200 interface ge-0/0/14.200
>  
> set interfaces ge-0/0/14 flexible-vlan-tagging
> set interfaces ge-0/0/14 native-vlan-id 200
> set interfaces ge-0/0/14 mtu 6000
> set interfaces ge-0/0/14 encapsulation extended-vlan-bridge
> set interfaces ge-0/0/14 unit 200 vlan-id-list 10-30
> set interfaces ge-0/0/14 unit 200 input-vlan-map push
> set interfaces ge-0/0/14 unit 200 output-vlan-map pop
> 
> 
> Even you can encapsulates customer vlan inside a service vlan, all layer 2 
> protocols will not pass. 
> 
> 
> 
> ____
> De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Chuck 
> Anderson [c...@wpi.edu]
> Enviado: sexta-feira, 24 de março de 2017 18:33
> Para: juniper-nsp@puck.nether.net
> Assunto: Re: [j-nsp] RES:  QFX 5100 and Q-in-Q
> 
> I had to load 14.1X53-D40 to have a basic working Q-in-Q config.  D35
> was broken in some fundamental way.
> 
> On Fri, Mar 24, 2017 at 04:31:56PM +, Alexandre Guimaraes wrote:
> > Alain,
> >
> >   As far i know, QinQ - L2TP does not work at QFX5100.
> >
> > Att.,
> > Alexandre
> >
> > 
> > De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Alain 
> > Hebert [aheb...@pubnix.net]
> > Enviado: sexta-feira, 24 de março de 2017 13:07
> > Para: juniper-nsp@puck.nether.net
> > Assunto: [j-nsp] QFX 5100 and Q-in-Q
> >
> >  Well,
> >
> >  We're having all sort of massive failure making Q-in-Q works in our
> > QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x
> >
> >  Such a simple thing should not take 1 week of back & forth with JTAC.
> >
> >  Anyone have some experience to share on that subject?
> >
> >  Thank.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RES: QFX 5100 and Q-in-Q

[Chuck Anderson]

I had to load 14.1X53-D40 to have a basic working Q-in-Q config.  D35
was broken in some fundamental way.

On Fri, Mar 24, 2017 at 04:31:56PM +, Alexandre Guimaraes wrote:
> Alain,
> 
>   As far i know, QinQ - L2TP does not work at QFX5100.
> 
> Att.,
> Alexandre 
> 
> 
> De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Alain Hebert 
> [aheb...@pubnix.net]
> Enviado: sexta-feira, 24 de março de 2017 13:07
> Para: juniper-nsp@puck.nether.net
> Assunto: [j-nsp] QFX 5100 and Q-in-Q
> 
>  Well,
> 
>  We're having all sort of massive failure making Q-in-Q works in our
> QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x
> 
>  Such a simple thing should not take 1 week of back & forth with JTAC.
> 
>  Anyone have some experience to share on that subject?
> 
>  Thank.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RES: QFX 5100 and Q-in-Q

[Chuck Anderson]

On Fri, Mar 24, 2017 at 04:31:56PM +, Alexandre Guimaraes wrote:
> Alain,
> 
>   As far i know, QinQ - L2TP does not work at QFX5100.
> 
> Att.,
> Alexandre 
> 
> 
> De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Alain Hebert 
> [aheb...@pubnix.net]
> Enviado: sexta-feira, 24 de março de 2017 13:07
> Para: juniper-nsp@puck.nether.net
> Assunto: [j-nsp] QFX 5100 and Q-in-Q
> 
>  Well,
> 
>  We're having all sort of massive failure making Q-in-Q works in our
> QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x
> 
>  Such a simple thing should not take 1 week of back & forth with JTAC.
> 
>  Anyone have some experience to share on that subject?
> 
>  Thank.
> 
> --
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
> 
> ___
> 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

-- 
Charles R. Anderson, JNCIE-SP   c...@wpi.edu
Network Architect   (508) 831-6110
Network Operations - Morgan Hall(508) 831-
Worcester Polytechnic Institute Fax (508) 831-6669
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] flowspec in logical-systems

[Chuck Anderson]

Try:

show firewall | match flowspec

Sometimes the filter names aren't what you expect when dealing with
logical-systems.  The ones I see are prepended with __LSYSNAME/ to you
might find them names __LSYSNAME/__flowspec_

On Wed, Mar 22, 2017 at 09:07:22PM +0200, Michail Litvak wrote:
> Hi all,
> 
> Did anybody tried to use flowspec in the logical-system ?
> The BGP session with flowspec family is up and receiving appropriate NLRI,
> the inetflow.0 table exists in the LS with appropriate values:
> 
> But no firewall filter __flowspec_default_inet__ exists in the LS.
> 
> 
>1.
> 
>admin@lab-2> show firewall filter logical-system LS4
> __flowspec_default_inet__
> 
>2.
> 
>error: filter name inconsistent with logical router
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX control plane filter

[Chuck Anderson]

On Mon, Mar 20, 2017 at 10:19:35AM +0100, Johan Borch wrote:
> Do anyone have a control plane filter for ACX they can share? :) they don't
> seem to support using standard loopback filters.

See this thread:

https://puck.nether.net/pipermail/juniper-nsp/2016-April/032422.html

and specifically this message which provides a good solution:

https://puck.nether.net/pipermail/juniper-nsp/2016-April/032436.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Generating routes from inactive/hidden contributors

[Chuck Anderson]

Last time I checked the contributing routes have to be in the
destination RIB for the aggregate/generate to go active.

On Sun, Mar 05, 2017 at 11:26:18AM +, Alexander Arseniev wrote:
> Hello,
> 
> Have You tried putting all routes from that peer in a routing-instance?
> 
> Then configure aggregate|generate in that instance and leak it into
> inet.0|whereever the other peers sit.
> 
> You can leak the whole table from that peer as well, but that
> amounts to 2x route memory consumption by that peer.
> 
> HTH
> 
> Thx
> 
> Alex
> 
> 
> On 03/03/2017 15:07, Tore Anderson wrote:
> >Hi,
> >
> >* adamv0...@netconsultings.com
> >
> >>Interesting,
> >>There appears to be no cmd to override the default, "contributing route has
> >>to be active", requirement. (the "from state inactive" attachment point is
> >>only the export policy).
> >>I'm just thinking whether it's not working simply because the inactive
> >>routes wouldn't be advertised anyways -so why to bother aggregating them
> >>right?
> >True, but this is a generated route, not an aggregated route. They're
> >quite similar, but the generated routes can have next-hops (copied from
> >a contributing route), which means you don't really need the
> >contributing routes themselves to be active or even non-hidden to
> >actually forward packets somewhere useful.
> >
> >Aggregated routes are on the other hand discard only, so then you need
> >the more-specific contributing routes with their next-hops to avoid
> >blackholing traffic.
> >
> >(AIUI, anyway.)
> >
> >>But maybe if you enable "advertise-inactive" towards your iBGP -maybe
> >>then the aggregation starts to work?
> >Perhaps, but if both the generated route and its contributors are
> >indeed inactive in the RIB and thus not found in the FIB, then I don't
> >think the router would be able to forward the packets it attracts to
> >where it should.
> >
> >>Alternatively, I'm thinking of something along the lines of making the
> >>prefixes active (to allow the aggregate to be advertised), but use
> >>them only for routing not for forwarding -so that FIB on a local
> >>router is not skewed.
> >Yep, something like that would probably do the trick. I was hoping to
> >keep them out of the RIB in the first place though, to avoid having to
> >explicitly filter them on export to the FIB and iBGP peers, but maybe
> >there's no way around it.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] controlling link-local and global next hops in MP_REACH_NLRI

[Chuck Anderson]

Is there any way with JUNOS to not send the link-local next hop in the
MP_REACH_NLRI path attribute of an IPv6 BGP session?  Another vendor
may be choking on it, and I'd like to test if removing it "fixes" the
issue, after which I can tell the vendor to fix their code.

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

[j-nsp] MX 15.1R4 port-mirror reliability

[Chuck Anderson]

Has anyone found MX port-mirror to be unreliable?  Either missing some
traffic or showing more traffic than should be there (e.g. from other
interfaces than the one(s) you have configured for port-mirroring)?
I'm using "family inet" port mirror on 15.1R4 and I can't explain why
some flows are showing up on the two ports I have mirrored, but I know
some of those sources are communicating over a different interface
that isn't mirrored.

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

Re: [j-nsp] JUNOS bug for QinQ VLANs

[Chuck Anderson]

I recommend 12.3R12-S3.1 for EX2200/3200/4200/4500.  I has many bug
fixes over 12.3R12.4:

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

However I see that JTAC is now recommending 15.1R5:

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

I haven't tried it yet--hopefully it has all the fixes that went into
the 12.3 service releases...

On Fri, Dec 16, 2016 at 10:21:06AM -0500, Dovid Bender wrote:
> The Juniper site was a bit confusing and I thought the latest was 12.3R as
> well till I was told otherwise on IRC (that US Domestic is being done away
> with).
> 
> 
> 
> On Fri, Dec 16, 2016 at 10:14 AM, Laurent CARON 
> wrote:
> 
> > On 15/12/2016 16:15, Valentini, Lucio wrote:
> >
> >> it seems there is a bug in the latest version of JUNOS for the EX4200:
> >> JUNOS Base OS boot [12.3R12.4]
> >>
> >
> > Hi,
> >
> > Latest release is:
> >
> > JUNOS EX  Software Suite [15.1R5.5]
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Chuck Anderson]

On Mon, Dec 14, 2015 at 12:40:05PM +, Phil Mayers wrote:
> On 11/12/15 17:16, Chuck Anderson wrote:
> 
> >For those of us who wish to/need to use commercial NMS software, are
> >there any that support NETCONF?  And NETCONF isn't the answer yet
> >anyway to cross-vendor standardization, at least not until standard
> >YANG models are developed.  At least Q-BRIDGE-MIB exists as a
> >standard.
> 
> On the commercial NMSes, no idea. I would hope that commercial
> products would provide a way to integrate external datasources, but
> maybe not.
> 
> I take your point about Netconf versus SNMP, and I don't disagree
> with you that Juniper should really fix this - "it's been broken for
> ages" is a pretty poor excuse, they could always provide a config
> knob to toggle on the new behaviour.
> 
> But I just don't see them fixing it.

They fixed it in 14.1X53-D40 and made it configurable.  Add this
configuration to make Q-BRIDGE-MIB follow the standard defintion of
PortList:

set switch-options mib dot1q-mib port-list bit-map

[edit switch-options]
+   mib {
+   dot1q-mib {
+   port-list bit-map;
+   }
+   }
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Keep local VPLS instance up when there are no remote PEs up

[Chuck Anderson]

In a VPLS multihoming scenario, if the remote primary multihomed PE
goes down, the local PE should start forwarding traffic to the CE:

https://www.juniper.net/documentation/en_US/junos15.1/topics/concept/vpn-vpls-multihoming-network-failures.html

But if all remote PEs go down (or if there are only 2 PEs in the VPLS
routing-instance to begin with, and one goes gown), the local VPLS
instance goes down, showing "No connections found".  The local IRB &
CE interfaces are taken down as well.

How do I keep the local VPLS instance UP including keeping the local
IRB and CE interfaces UP in this scenario?  "connectivity-type irb" or
"permanent" is about keeping the instance UP when all local CE
interfaces go down--I need the opposite, the CEs are up but remote PEs
are down.

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

Re: [j-nsp] interpreting 10Gb interface "PCS statistics" values

[Chuck Anderson]

When I was getting these and the Cisco far end was getting tons of
errors, the light levels were good all around.  It ended up being a
fiber problem near the transmitter.  Try shooting the fiber link with
an OTDR to see if you are getting lots of reflections.

On Fri, Oct 21, 2016 at 12:23:18PM -0700, Michael Loftis wrote:
> Was hoping someone who knew more could chime in...but it's measured in
> seconds basically because the PCS (physical coding sublayer) does NOT
> keep detailed statistics...so the "Seconds" value means there were X
> distinct seconds in which an error was flagged in that category...the
> previous response detailing bit vs errored blocks I think is wrong.
> The PCS layer can repair single bit errors, thus a second with one or
> more single bit (but correctable!) errors is a "bit errored second" -
> if it is unabled to correct and recover a valid PCS block then you get
> the "errored block" seconds...
> 
> It's not a raw count of the number of those errors, just that it
> occurred in a ~1s window X times.  You can totally get PCS errors
> unplugging an optic or otherwise shutting down the remote end.  You
> can totally get spurious PCS errors from a marginal ish link that
> shows PLENTY of light (SNR is low or a marginal cable).  in MX
> specifically it *can* in very rare circumstances indicate a problem
> even between the optic and the MICmost of the time my suggestion
> for PCS errors is clear counters and check in 1h and 24h.  If you get
> a significant number of errored seconds in a 24h period then
> check/clean ends and patches, maybe replace optics.
> 
> Also beware, lots of DOM bugs in various JunOS releases cause the DOM
> values to get stuck, and it can be hard or impossible to check in a
> non outage causing way (sometimes you can safely bend the patch cable
> and observe the increase in loss to verify your DOM values aren't
> stuck) - I've had this most commonly in the past on DPC cards but have
> also observed it in MPC cards.  The DOM data is also highly dependent
> upon the optic itself and there's a LOT of buggy stuff out there so
> it's not all juniper's fault there.
> 
> 
> On Fri, Oct 21, 2016 at 11:07 AM, David B Funk
>  wrote:
> > Thanks guys but this isn't what I was asking.
> >
> > The optical power is similar (within a few tenths of a dBm) at my end, down
> > by 3 dBm at the far end of the link that is having issues (-6.23 dBm as
> > opposed to -3.73 dBm) but not enough to explain what I'm seeing.
> >
> > The big question I have is: What does "30 Seconds" mean for an attribute
> > that by description of the docs is supposed to be number of PCS blocks with
> > invalid Sync headers?
> > Particularly when the guy on the Cisco at the other end says his error
> > counters are going up like crazy (and packets are being dropped) while the
> > stats my end stays constant at "30 Seconds".
> > What does that mean?
> >
> > The particularly frustrating thing is that data streams are dropping packets
> > (EG iperf3 showing retries and seriously degraded performance) but none of
> > the interface stats are showing any values that indicate an issue other than
> > that "30 Seconds".
> >
> > Can anybody tell me what "30 Seconds" means (in the context of an error
> > counter)?
> >
> >
> >
> >
> > On Fri, 21 Oct 2016, Christopher Costa wrote:
> >
> >> Here's my notes from a jtac review about these a couple years ago:
> >>
> >>
> >>
> >> [pcs] encoding is continually transmitting to keep the line in sync. The
> >> PCS layer is directly below the MAC layer so for MX,
> >> it’s on the MIC. PCS errors can be caused by anything MIC or lower, i.e.
> >> transceiver, fiber, line equipment, etc.
> >>
> >>
> >>
> >>  PCS functionality:
> >>  ===
> >>  IEEE 802.3ae 10GbE interfaces use a 64B/66B encoder/decoder in the
> >> PHY-PCS (Physical Coding Sub layer) to allow reasonable
> >> clock recovery and facilitate alignment of the data stream at the
> >> receiver.
> >>  As the scheme name suggests, 64 bits of data on the MAC layer are
> >> transmitted as a 66-bit code block on the PHY layer, which
> >> realizes easier clock/timing synchronization. A 66-bit code block contains
> >> a 2-bit Sync. Header + 8 octets data/control field.
> >>   If the Sync. header is '01', the 8 octets are entirely data.
> >>  If the Sync. header is '10', an 8-bit Type field follows, plus 56 bits of
> >> data/control field.
> >>   The 8 octets data/control field is scrambled by using a self-synchronous
> >> scrambler to achieve complete DC-balance on the
> >> serial line.
> >>  PCS statistics displays PCS fault conditions by checking valid Sync.
> >> headers received with every 66 bits interval, so that we
> >> can monitor 10Gbps high speed transmission line quality.
> >>   If the 64B/66B receiver does not detect the 2-bit Sync.
> >>  Header with regular 66-bit interval and it estimates the high BER (Bit
> >> Error Rate of >10^-4), PCS statistics will report a
> >> 

Re: [j-nsp] NETCONF vs.

[Chuck Anderson]

On Wed, Sep 21, 2016 at 03:26:40PM -0400, Chuck Anderson wrote:
> This doesn't work:
> 
> $res = $jnx->get_configuration(changed => 'changed', compare => 'rollback', 
> database => 'candidate');
> 
> because that generates this:
> 
> 
>   
> candidate
> rollback
> changed
>   
> 
> 
> when I need it to be this:
> 
> 
>changed="changed">
>   
> 

After a close reading of the Perl Net::Netconf::Device code, I've come
to the conclusion that what I want to do is impossible with that API
as written, unless I modify it to add a get_configuration method that
accepts attributes.  I will either need to switch back to the
JUNOScript Perl API or change my approach.

It seems like this would be a common operation--commit my changes if
anything was actually changed during a merge/replace operation,
rollback otherwise.  Perhaps something could be built-in that does
this.  Even from the CLI I often do "show | compare" followed by
"rollback" and "exit" if there are no actual changes after e.g. a
"replace pattern" or "load merge" operation.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF vs.

[Chuck Anderson]

No, I'm trying to have the router do the compare server-side.

On Wed, Sep 21, 2016 at 02:52:42PM -0500, Tim Jackson wrote:
> Have you just tried to just compare source=>running to source=>candidate
> from get_config?
> 
> --
> Tim
> 
> On Wed, Sep 21, 2016 at 2:26 PM, Chuck Anderson <c...@wpi.edu> wrote:
> 
> > Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the
> > candidate configuration to see what changed before issuing a commit
> > request so I can avoid "empty" commits after doing a "replace"
> > operation on a subtree.  I see that NETCONF defines a standard
> >  call, and I believe  is a
> > legacy/proprietary Junos call.  There is a  example in the
> > documentation, but there doesn't appear to be a way to see what was
> > changed in the candidate config vs. the committed config:
> >
> > https://www.juniper.net/techpubs/en_US/junos16.1/
> > topics/task/program/netconf-perl-client-application-
> > submitting-requests.html
> >
> > The API call I want to make is documented here:
> >
> > https://www.juniper.net/documentation/en_US/junos14.1/
> > topics/reference/tag-summary/netconf-junos-xml-protocol-
> > get-configuration.html
> >
> > But I can't for the life of me figure out how to pass the various
> > attributes inside the  tag with Perl.  How does one
> > map the attributes INSIDE a tag to the Perl API call as below?
> >
> >  > database="candidate">
> >
> > This doesn't work:
> >
> > $res = $jnx->get_configuration(changed => 'changed', compare =>
> > 'rollback', database => 'candidate');
> >
> > because that generates this:
> >
> > 
> >   
> > candidate
> > rollback
> > changed
> >   
> > 
> >
> > when I need it to be this:
> >
> > 
> >> changed="changed">
> >   
> > 
> >
> > Thanks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] NETCONF vs.

[Chuck Anderson]

Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the
candidate configuration to see what changed before issuing a commit
request so I can avoid "empty" commits after doing a "replace"
operation on a subtree.  I see that NETCONF defines a standard
 call, and I believe  is a
legacy/proprietary Junos call.  There is a  example in the
documentation, but there doesn't appear to be a way to see what was
changed in the candidate config vs. the committed config:

https://www.juniper.net/techpubs/en_US/junos16.1/topics/task/program/netconf-perl-client-application-submitting-requests.html

The API call I want to make is documented here:

https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/tag-summary/netconf-junos-xml-protocol-get-configuration.html

But I can't for the life of me figure out how to pass the various
attributes inside the  tag with Perl.  How does one
map the attributes INSIDE a tag to the Perl API call as below?



This doesn't work:

$res = $jnx->get_configuration(changed => 'changed', compare => 'rollback', 
database => 'candidate');

because that generates this:


  
candidate
rollback
changed
  


when I need it to be this:


  
  


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

[j-nsp] MX upgrade to 15.1R4.6: loopback filters drop all traffic

[Chuck Anderson]

Has anyone upgraded from 14.2 to 15.1 and seen this issue?  Right
after the upgrade, all loopback filters started dropping all traffic
causing OSPF & BGP failures, inability to ping or SSH into fxp0, etc.,
despite being configured to allow the appropriate management & control
plane traffic which was working perfectly fine in 14.2.
Deactivating/reactivating the filters "fixed" the issue, as did a full
box reboot.  Of course JTAC can't reproduce it.  64-bit Junos,
RE-1800X4's.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] need HELP black holing a /32 via BGP community.

[Chuck Anderson]

You can also directly set the communities on the static route, making
the BGP policy unnecessary:

set routing-options static route A.B.C.D/32 discard community [ 7922:666 
1239:66 ]

On Thu, Sep 15, 2016 at 05:12:34PM +, Matthew Crocker wrote:
> 
> 
> 
> Static /32 is in and  Sprint (AS1239) uses 1239:66 as the blackhole 
> community.   Some use 666, some have 911
> 
> I think it is working, just need to dig into some looking glasses to see what 
> the world sees.
> 
> Thanks again.
> 
> From: Dave Bell 
> Date: Thursday, September 15, 2016 at 1:02 PM
> To: Matthew Crocker 
> Cc: "juniper-nsp@puck.nether.net" 
> Subject: Re: [j-nsp] need HELP black holing a /32 via BGP community.
> 
> Looks good. You may just want to add a /32 route so you have one to send.
> 
> set routing-options static route A.B.C.D/32 discard
> 
> Looks like you may be missing a 6 from a community too?
> 
> Regards,
> Dave
> 
> On 15 September 2016 at 17:53, Matthew Crocker 
> > wrote:
> 
> 
> Hello,
> 
> I have a /32 that I need to add a community to so get my upstreams to 
> blackhole the traffic.
> 
> Can anyone send me any points on how to do that?
> 
> I have:
> 
> policy-statement pl-blackhole {
> term match-route {
> from {
> prefix-list blackhole-prefixes;
> }
> }
> then {
> community add blackhole;
> accept;
> }
> }
> 
> 
> prefix-list blackhole-prefixes {
> A.B.C.D/32;
> }
> 
> community blackhole members [ 7922:666 1239:66 ];
> 
> 
> 
> I’ve added pl-blockhole to my upstream BGP group export statement.
> 
> Am I on the right track?  What am I missing?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Fate sharing between BGP and RSVP

[Chuck Anderson]

See also:

http://www.juniper.net/documentation/en_US/junos15.1/topics/usage-guidelines/mpls-configuring-traffic-engineering-for-lsps.html

On Wed, Sep 14, 2016 at 09:20:17AM +0200, Dragan Jovicic wrote:
> So you want BGP to resolve routes using only inet.3 table which contains
> RSVP routes, and not inet.0.
> 
> https://www.juniper.net/documentation/en_US/junos15.1/topics/example/vpns-layer-3-route-resolution-route-reflector.html
> 
> 
> Dragan
> 
> On Wed, Sep 14, 2016 at 1:26 AM, Rob Foehl <r...@loonybin.net> wrote:
> 
> > On Tue, 13 Sep 2016, Chuck Anderson wrote:
> >
> > I guess I don't understand what you are trying to accomplish then.
> >> Ttaffic engineering specific routes is exactly what RSVP is used for.
> >> The MPLS path should be torn down if there is no available
> >> RSVP-capable route.  Did you try just not configuring RSVP on the
> >> interfaces that can't support MPLS?
> >>
> >
> > The LSP is torn down; the BGP session carrying a bunch of routes for which
> > that LSP is the only viable forwarding path survives.  (RSVP is only
> > configured where it ought to be, no "interfaces all" or anything like that.)
> >
> > The goal is for the BGP-learned routes to disappear along with the LSP --
> > preferably by just tearing the session down with it, but otherwise
> > invalidating the next-hops would suffice.
> >
> > I have another idea in my back pocket if this isn't workable, but that
> > involves turning a bunch of P routers into full BGP RRs...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Fate sharing between BGP and RSVP

[Chuck Anderson]

On Tue, Sep 13, 2016 at 06:38:10PM -0400, Rob Foehl wrote:
> On Tue, 13 Sep 2016, Chuck Anderson wrote:
> 
> >Could you just use a strict MPLS path with an ERO?
> 
> Hmm, doesn't look like it...  I just tried configuring an explicit
> path LSP to nowhere on a lab box, and it didn't install anything
> into the routing table without the LSP up.  Either way, a strict
> path would probably cause more trouble than it'd be worth.

I guess I don't understand what you are trying to accomplish then.
Ttaffic engineering specific routes is exactly what RSVP is used for.
The MPLS path should be torn down if there is no available
RSVP-capable route.  Did you try just not configuring RSVP on the
interfaces that can't support MPLS?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Fate sharing between BGP and RSVP

[Chuck Anderson]

On Tue, Sep 13, 2016 at 05:42:37PM -0400, Rob Foehl wrote:
> Assuming a typical IBGP session built between loopbacks, is there
> any relatively clean way to tie that session state to RSVP-signaled
> LSPs between the same pair of routers?
> 
> I'm trying to work around a case where the IGP knows about another
> path between the two that doesn't carry any MPLS traffic, thus
> keeping the BGP session alive without a valid forwarding path for
> any of the received routes in the event of a failure along the
> MPLS-enabled path.

Could you just use a strict MPLS path with an ERO?

http://www.juniper.net/documentation/en_US/junos14.2/topics/example/mpls-lsp-explicit-path-configuring.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] open source packages to monitor ex2200/vc

[Chuck Anderson]

Okay, attachments don't come through the list, so I've done what I
should have done long ago and put this on github:

https://github.com/cranderson/nagios-plugins

On Wed, Aug 17, 2016 at 11:12:12AM -0400, Chuck Anderson wrote:
> (trying again with gzipped code to make message small enough)
> 
> For Juniper hardware/software fault monitoring, we use Nagios with the
> check_snmp_environment plugin, extended with more Juniper checks.
> I've attached the one we use here.  I'd like to improve this further
> by removing duplicate alerts (often the Component State and FRU states
> are identical, so we get alert messages with the same alerts printed
> twice, but I didn't know that when I wrote it originally and wanted to
> not miss anything).
> 
> For interface statistics and historical graphing/trending, we use
> AKiPS.  AKiPS can also do threshold and fault alerting if you'd rather
> have a single solution that does everything.  The nice thing about
> AKiPS is that it has pretty comprehensive support for many vendors of
> not just networking gear, but also servers, power systems, wireless,
> etc.  It also has a syslog and NetFlow collector.  They also add new
> functionality pretty rapidly.
> 
> On Wed, Aug 17, 2016 at 12:15:12PM +0100, William wrote:
> > Hi list,
> > 
> > What is everyone using to monitor their EX2200/VC stacks?
> > 
> > We are using check_mk to monitor our network which is great, however due to
> > the way it polls or due to the low power of the ex2200 I'm unable to
> > monitor all the individual interfaces.
> > 
> > Cheers,
> > 
> > Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] open source packages to monitor ex2200/vc

[Chuck Anderson]

(trying again with gzipped code to make message small enough)

For Juniper hardware/software fault monitoring, we use Nagios with the
check_snmp_environment plugin, extended with more Juniper checks.
I've attached the one we use here.  I'd like to improve this further
by removing duplicate alerts (often the Component State and FRU states
are identical, so we get alert messages with the same alerts printed
twice, but I didn't know that when I wrote it originally and wanted to
not miss anything).

For interface statistics and historical graphing/trending, we use
AKiPS.  AKiPS can also do threshold and fault alerting if you'd rather
have a single solution that does everything.  The nice thing about
AKiPS is that it has pretty comprehensive support for many vendors of
not just networking gear, but also servers, power systems, wireless,
etc.  It also has a syslog and NetFlow collector.  They also add new
functionality pretty rapidly.

On Wed, Aug 17, 2016 at 12:15:12PM +0100, William wrote:
> Hi list,
> 
> What is everyone using to monitor their EX2200/VC stacks?
> 
> We are using check_mk to monitor our network which is great, however due to
> the way it polls or due to the low power of the ex2200 I'm unable to
> monitor all the individual interfaces.
> 
> Cheers,
> 
> Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Chuck Anderson]

On Tue, Jun 21, 2016 at 01:37:37PM +0300, Saku Ytti wrote:
> On 21 June 2016 at 13:31, Nathan Ward  wrote:
> 
> > I haven’t looked in ages, but didn’t Richard Steenbergen run a wiki for 
> > this sort of info?
> 
> Yeah but he's wearing suits now and has no time for such shenanigans.
> Job has copy of the data. But community (I don't exclude myself here)
> contribution to the site were less than stellar. Unsure if it's the
> wiki format or what.

I wanted (still want) to contribute but could never get an account.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VPLS and IRB

[Chuck Anderson]

On Wed, Apr 20, 2016 at 01:14:17AM +0200, j...@czmok.de wrote:
> Hi,
> 
> i am looking for the following solution:
> 
> - SITE A - VPLS SITE 1
> - SITE B - VPLS SITE 2
> 
> On Site A i receive on ae0. Traffic which is tagged with VLAN 
> On Site B i want to provide a Layer3 Interface which provides 
> Layer3-Termination of VLAN
> Between Site A and Site B i want to use vpls

> on SITE b:
> 
> TEST {
> instance-type virtual-switch;
> route-distinguisher 1.2.3.5:;
> vrf-target target::;
> protocols {
> vpls {
> site-range 3;
> no-tunnel-services;
> site B {
> site-identifier 1;
> }
> }
> }
> bridge-domains {
> vlan {
> vlan-id ;
> routing-interface irb.;
> }
> }
> }

Don't use a virtual-switch, just use a regular vpls instance, and add
a routing-interface irb..  Addionally use connectivity-type irb so
the VPLS instance stays up even with no physical ports in it:

TEST {
instance-type vpls;
route-distinguisher 1.2.3.5:;
vrf-target target::;
routing-interface irb.;
protocols {
vpls {
site-range 3;
no-tunnel-services;
site B {
site-identifier 1;
}
connectivity-type irb;
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Leaking from a vrf to inet0

[Chuck Anderson]

On Mon, Mar 21, 2016 at 05:04:35PM +0100, Raphael Mazelier wrote:
> I am currently evaluating how to migrate the internet dmz, and the
> public pfx of my customers into VRF.
> During the migration phase I have to leak pfx from vrf to the global table.
> Don't ask why, but I cannot do the leaking on the PE-CE side as it
> should normaly occur.
> So I want to do leaking on the remote PE from pfx learned via mp-bgp
> on the vrf to the global, and afaik it is not possible directly.
> 
> I know that this topic have been discussed before, but if someone
> have some hints on how to do this the cleanest way possible.

You can use rib-groups to do this.

> - advertise twice the route in family inet in addition to inet-vpn,
> in order to leak it with rib-group (since rib-group only work when
> pfx is in a primary table)

I don't think this is true.  I'm doing this and it works.

set routing-instances INTERNET protocols bgp family inet unicast rib-group 
INTERNET-to-MAIN-UCAST
set routing-instances INTERNET protocols bgp family inet6 unicast rib-group 
INTERNET-to-MAIN-UCAST6
set routing-options rib-groups INTERNET-to-MAIN-UCAST import-rib INTERNET.inet.0
set routing-options rib-groups INTERNET-to-MAIN-UCAST import-rib inet.0
set routing-options rib-groups INTERNET-to-MAIN-UCAST6 import-rib 
INTERNET.inet6.0
set routing-options rib-groups INTERNET-to-MAIN-UCAST6 import-rib inet6.0
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] firewall filter prefix-list ordering

[Chuck Anderson]

On the MX/Trio platform, from a performance standpoint with large
prefix-lists (~10,000) and firewall filters, does it matter what order
the prefix-list is in?  Will the firewall filter perform better if
shorter prefixes are listed first or if some other criteria is used
for sorting?

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

Re: [j-nsp] MX960 2x MS-MPC-128

[Chuck Anderson]

Not enough power to power up the card?

show chassis power

On Fri, Feb 26, 2016 at 01:50:44PM -0600, Josh Reynolds wrote:
> Hi all.
> 
> Pair of MS-MPC-128's. 1st card boots, second card doesn't. Swapped FPC
> locations, now the 2nd card boots in the first card's spot, but the
> 1st card won't boot in the previous spot of the 2nd card. Have tried
> several other slots for the 2nd card the with same results.
> 
> show chassis hardware recognizes the MS-MPC-128 is installed, but no
> power. request chassis fpc online slot X shows: "Online initiated, use
> "show chassis fpc" to verify", but "show chassis fpc" still shows it's
> powered off.
> 
> What gives?
> 
> Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] "load replace" junoscript login class permissions

[Chuck Anderson]

Can you please provide an example of what you are saying should work
(in text format even)?

This is what I was trying in XML (from perl) and it doesn't work with
the permissions restricted to "policy-options prefix-list AUTO-.*",
but it does work with the permissions widened to "policy-options .*":

$jnx->load_configuration(
format => "xml",
action => "replace",
configuration => $replace);

Where the contents of the $replace variable is:


  

  AUTO-FOO
  
1.1.1.1/32
  

  


I believe I also tried applying the "replace" attribute on the 
tag like this: AUTO-FOO, but that isn't
accepted as valid syntax.

I ended up using a configuration group at Phil's suggestion.  That way
I can restrict the permissions to "groups AUTO-PREFIX-LIST
policy-options .*" to allow the replace operation to work but prevent
the script from mucking with objects it isn't supposed to touch.

Thanks.

On Thu, Feb 25, 2016 at 12:05:36PM -0500, Chris Spears wrote:
> Can you add a replace attribute in the container for the prefix-lists
> matching /AUTO-*/, and see if the permissions work?   The equivalent
> replace: tag in the text format works with a restricted login class when
> using netconf.
> 
> http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/tag-summary/junos-xml-protocol-replace-attribute.html
> 
> 
> 
> 
> On Mon, Feb 22, 2016 at 9:46 PM, Chuck Anderson <c...@wpi.edu> wrote:
> 
> > On Mon, Feb 22, 2016 at 09:08:04PM -0500, Jared Mauch wrote:
> > > > 1. "load replace" config with the new prefix list contents
> > > > 2. commit
> > >
> > >
> > > Try ‘load update’ first.
> > >
> > > That should be much faster than load replace.
> >
> > Yes, I see it is fast, but I can't figure out the right XML to do the
> > equivalent of "load update relative" in the CLI.  If I leave off the
> > "relative", then the entire configuration is replaced (deleted), not
> > just the prefix-list.
> >
> > "show | compare | display xml" exists in 15.1, but not in 14.2 :-(
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] family inet/inet6 fw filters sharing the same prefix-list

[Chuck Anderson]

Has anyone seen strange behavior when using a single prefix-list
shared containing both IPv4 and IPv6 prefixes shared between two fw
filters, one family inet and one family inet6?  I just tried this, and
the family inet6 filter is executing the "then syslog" term even when
there is no match in the "from" clause.

Something like this:

family inet { AND family inet6 {
term PORT-MIRROR {
then {
port-mirror;
next term;
}
}
term TS-ALLOW {
from {
prefix-list {
TS-ALLOW;
}
}
then {
count TS-ALLOW;
syslog;
next term;
}
}
term Accept-All {
then accept;
}
}

For the family inet version, everything works correctly.  For the
family inet6 version (configured at the same time), any/all IPv6
traffic, regardless if it matches the prefix-list TS-ALLOW, is being
subject to the syslog action.  I was seeing link-local ND and
site-local IPsec OSPF traffic matching.

The prefix-list TS-ALLOW contains only IPv4 address prefixes.  I tried
adding an IPv6 one (:::::::/128) just
so there was at least one, but the result is the same.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] syslog is flooded with curious messages (MX5 / 14.2R2.8)

[Chuck Anderson]

At least for the "ifa for this rt" message, it is a bug that was
fixed:

https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1067484

   "When setting the syslog to debug level (any any), you may note
reoccurring messages of the form "ifa for this rt ia is not
present, consider ifa as ready". These messages are logged for
IPv6 enabled interfaces when receiving forwarded packets and cause
no harm. Set a higher debug level to avoid seeing them.

Resolved In  14.1R6 14.2R4 15.1R2"

On Fri, Jan 22, 2016 at 12:31:05PM +0100, Job Snijders wrote:
> On Fri, Jan 22, 2016 at 09:12:01AM -0200, Eduardo Schoedler wrote:
> > Same problem here...
> > 
> > Jan 22 09:05:04  router chassisd[1546]: Cannot read 
> > hw.chassis.startup_time: No such file or directory
> > Jan 22 09:05:14  router last message repeated 2 times
> > Jan 22 09:07:14  router last message repeated 24 times
> > Jan 22 09:08:59  router last message repeated 21 times
> 
> I upgraded to 15.1R2.9, and subsequently the above messages went away
> (hooray!) but in return I got the below:
> 
>   Jan 22 11:29:32  eunetworks-1.router.nl.coloclue.net tfeb0 
> cmtfpc_vtreg_npc_create: Invalid I2C ID 0x556
>   Jan 22 11:29:32  eunetworks-1.router.nl.coloclue.net tfeb0 
> cmtfpc_vtreg_npc_volt_get - Failed to create vtreg handle
>   Jan 22 11:29:32  eunetworks-1.router.nl.coloclue.net tfeb0 
> cmtfpc_collect_voltage_status: failed reading Volterra volt data
>   (endlessly)
> 
> Kind regards,
> 
> Job
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] "load replace" junoscript login class permissions

[Chuck Anderson]

On Mon, Feb 22, 2016 at 09:08:04PM -0500, Jared Mauch wrote:
> > 1. "load replace" config with the new prefix list contents
> > 2. commit
> 
> 
> Try ‘load update’ first.
> 
> That should be much faster than load replace.

Yes, I see it is fast, but I can't figure out the right XML to do the
equivalent of "load update relative" in the CLI.  If I leave off the
"relative", then the entire configuration is replaced (deleted), not
just the prefix-list.

"show | compare | display xml" exists in 15.1, but not in 14.2 :-(
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] "load replace" junoscript login class permissions

[Chuck Anderson]

Historically, we've implemented scripts to sync prefix-lists with
Junoscript perl using this method:

1. get_configuration of the prefix-list
2. compare prefix list in router to our local copy
3. "load merge" config to delete prefixes that exist in the router but not 
locally
4. "load merge" config to add prefixes that exist locally but not in the router
5. commit

The reason for this was because we wanted to lock down the junoscript
account like this:

> show configuration system login class prefix-list
permissions [ configure view view-configuration ];
allow-commands junoscript;
allow-configuration "policy-options prefix-list AUTO-.*";

So any rogue junoscript could only ever change the contents of
prefix-lists whose names begin with "AUTO-".

However, this method is very slow.  So I tried going back to the
"replace" method:

1. "load replace" config with the new prefix list contents
2. commit

This is nice and fast (3-10 times faster).  But it doesn't work with
the login class restrictions above.  Instead we have to open it up:

> show configuration system login class prefix-list
permissions [ configure view view-configuration ];
allow-commands junoscript;
allow-configuration "policy-options .*";

Otherwise we get a failure trying to replace the prefix-list.  I don't
like this because now a rogue script could mess with the entire
policy-options hierarchy.

Is there a solution that allows fast on-box merging (load update?)
without requiring wide-open permissions?

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