Re: [j-nsp] proxy-arp on EVPN irb
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
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?
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
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
tats 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 entries needed : 1 > > > > Total hardware instances: 1 > > == > > > > > > > On Wed, 12 Oct 2022 at 05:33, Chuck Anderson via juniper-nsp > > > wrote: > > > > > > > > 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 p
Re: [j-nsp] Cannot program filter pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
ntries needed : 1 Total hardware instances: 1 == > On Wed, 12 Oct 2022 at 05:33, Chuck Anderson via juniper-nsp > wrote: > > > > 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
[j-nsp] Cannot program filter pfe-cos-cl-631-5-1 (type VFP_IL2L3_COS) -TCAM has 0 free entries
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
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
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?
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
"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
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?
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
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
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
