Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 21:48, Nehul Patel wrote:


ok mark got it currently we are using the following DPCE Cards

DPCE-R-4XGE-XFP
DPCE-R-Q-4XGE-XFP

When we tried using the command set chassis memory-enhanced route on 
the current Junos version 10.4 it says the command is not supported


so we will need to upgrade the Junos to the newer version in order to 
try above command of it.


Odd, as this said it came alive in Junos 10.4:

https://www.juniper.net/documentation/us/en/software/junos/junos-overview/topics/ref/statement/memory-enhanced-edit-chassis.html

Mark.

Re: Strange behavior on the Juniper MX240

[Nehul Patel]

ok got it thank you Nick

On Thu, May 5, 2022 at 3:43 PM Nick Olsen  wrote:

> Nehul,
>
> He was running the 15 code train. I think 15.1R6.7. But don't take that as
> fact. I just know it was 15 for sure.
> --
> *From:* Nehul Patel 
> *Sent:* Thursday, May 5, 2022 6:40 PM
> *To:* Nick Olsen 
> *Cc:* nanog@nanog.org 
> *Subject:* Re: Strange behavior on the Juniper MX240
>
> Hi Nick,
>
> Thank you for the feedback on it. Would you please let me know which Juno
> OS version he had installed on the MX Chassis that works with the extended
> memory command of it?
>
> On Thu, May 5, 2022 at 12:50 PM Nick Olsen  wrote:
>
> Friend of mine had this issue recently on an MX chassis running DPC's and
> RE-2000's.
>
> The extend memory command others have mentioned worked for him.
>
> His instance drove us crazy for a bit. The device would learn a route,
> show that it was installed (show routes) but traffic to said prefix would
> bounce net unreachable. We even pushed a static just for S's and that
> still didn't resolve it. It was a single prefix that a customer had
> reported.
>
> Some things to consider, as others have mentioned.
>
>
>1. IPv6 routes share the same space. And use more per-route. You can
>extend the life of this box (probably considerably) by dropping full tables
>for IPv6. Perhaps taking just a default (Same goes for v4).
>2. It seems from your previous output that you're taking ~1 full v4
>table. And 2x v6 tables. Do you really need a full table if you're only
>taking 1 v4 table? Consider switching to a default only? In my Colleagues
>case, he was taking 2 full tables of v4 and v6 until he hit the same issue.
>3. While you're RE's could use a nice upgrade too. Your linecards are
>actually the problem here. If you move to anything > DPC you get the trio
>chipset with much more FIB space (2 Million routes I believe?). I'd
>consider new RE's and new line cards for this box. Which might also mean
>new switch fabric controllers Basically, we'd be talking a full
>overhaul sans the power supplies and chassis.
>4. Consider taking a default + full routes. Then filtering > /24 (if
>you even have anything < /24 learned now) (/48 on IPv6).
>
> Start with the memory command first and see where that gets you. But keep
> a watchful eye out for this to happen again (as the DFZ grows). Eventually
> your only option will be to filter routes and rely on a default or upgrade.
> --
> *From:* NANOG  on behalf of
> Nehul Patel 
> *Sent:* Wednesday, May 4, 2022 3:56 PM
> *To:* nanog@nanog.org 
> *Subject:* Strange behavior on the Juniper MX240
>
>
> Hi NANOG,
>
> We are seeing some strange behavior on our Juniper MX240 Chassis it is
> randomly dropping the routes to the certain destination IP address getting
> the following errors on the MX240 Chassis
>
> If Someone has seen these errors before please suggest how to resolve it
>
>
> May  4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to
> size>1024K
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5
> (Invalid)
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err
> 5 (Invalid)
> May  4 12:42:01   last message repeated 4 times
> May  4 12:42:01   fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry into
> jtree failed)
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028:
> rt_halp_vectors->rt_create failed
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len
> 48 prefix 2600:40fc:1011::/48 nh 1048576
> May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
> May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 (No
> memory) on FE 0
> May  4 12:42:01   fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry into
> jtree failed)
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028:
> rt_halp_vectors->rt_create failed
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len
> 48 prefix 2001:67c:20fc::/48 nh 1048576
> May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
> May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2606:2800:e004::/48
> (No memory) on FE 0
> May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2a05:3181:::/48
> (No memory) on FE 0
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err
> 5 (Invalid)
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5
> (Invalid)
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, err
> 5 (Invalid)
> May  4 12:42:02   fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No
> memory) on FE 0
> May  4 12:42:02   fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into jtree
> failed)
> May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2028:
> rt_halp_vectors->rt_create failed
> May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv4,len
> 24 prefix 79.120.22/24 nh 1048583
> 

Re: Strange behavior on the Juniper MX240

[Nick Olsen]

Nehul,

He was running the 15 code train. I think 15.1R6.7. But don't take that as 
fact. I just know it was 15 for sure.

From: Nehul Patel 
Sent: Thursday, May 5, 2022 6:40 PM
To: Nick Olsen 
Cc: nanog@nanog.org 
Subject: Re: Strange behavior on the Juniper MX240

Hi Nick,

Thank you for the feedback on it. Would you please let me know which Juno OS 
version he had installed on the MX Chassis that works with the extended memory 
command of it?

On Thu, May 5, 2022 at 12:50 PM Nick Olsen 
mailto:n...@141networks.com>> wrote:
Friend of mine had this issue recently on an MX chassis running DPC's and 
RE-2000's.

The extend memory command others have mentioned worked for him.

His instance drove us crazy for a bit. The device would learn a route, show 
that it was installed (show routes) but traffic to said prefix would bounce net 
unreachable. We even pushed a static just for S's and that still didn't 
resolve it. It was a single prefix that a customer had reported.

Some things to consider, as others have mentioned.


  1.  IPv6 routes share the same space. And use more per-route. You can extend 
the life of this box (probably considerably) by dropping full tables for IPv6. 
Perhaps taking just a default (Same goes for v4).
  2.  It seems from your previous output that you're taking ~1 full v4 table. 
And 2x v6 tables. Do you really need a full table if you're only taking 1 v4 
table? Consider switching to a default only? In my Colleagues case, he was 
taking 2 full tables of v4 and v6 until he hit the same issue.
  3.  While you're RE's could use a nice upgrade too. Your linecards are 
actually the problem here. If you move to anything > DPC you get the trio 
chipset with much more FIB space (2 Million routes I believe?). I'd consider 
new RE's and new line cards for this box. Which might also mean new switch 
fabric controllers Basically, we'd be talking a full overhaul sans the 
power supplies and chassis.
  4.  Consider taking a default + full routes. Then filtering > /24 (if you 
even have anything < /24 learned now) (/48 on IPv6).

Start with the memory command first and see where that gets you. But keep a 
watchful eye out for this to happen again (as the DFZ grows). Eventually your 
only option will be to filter routes and rely on a default or upgrade.

From: NANOG 
mailto:141networks@nanog.org>>
 on behalf of Nehul Patel mailto:nehul.pa...@gmail.com>>
Sent: Wednesday, May 4, 2022 3:56 PM
To: nanog@nanog.org 
mailto:nanog@nanog.org>>
Subject: Strange behavior on the Juniper MX240


Hi NANOG,

We are seeing some strange behavior on our Juniper MX240 Chassis it is randomly 
dropping the routes to the certain destination IP address getting the following 
errors on the MX240 Chassis

If Someone has seen these errors before please suggest how to resolve it


May  4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to size>1024K
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 
(Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 
(Invalid)
May  4 12:42:01   last message repeated 4 times
May  4 12:42:01   fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry into 
jtree failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 
prefix 2600:40fc:1011::/48 nh 1048576
May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 (No 
memory) on FE 0
May  4 12:42:01   fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry into jtree 
failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 
prefix 2001:67c:20fc::/48 nh 1048576
May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2606:2800:e004::/48 (No 
memory) on FE 0
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2a05:3181:::/48 (No 
memory) on FE 0
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 
(Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 
(Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, err 5 
(Invalid)
May  4 12:42:02   fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No memory) on 
FE 0
May  4 12:42:02   fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into jtree 
failed)
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv4,len 24 
prefix 79.120.22/24 nh 1048583
May  4 12:42:02   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 
(Invalid)
May  4 12:42:02   fpc0 RT-HAL,rt_msg_handler,540: route 

Re: Strange behavior on the Juniper MX240

[Nehul Patel]

Hi Nick,

Thank you for the feedback on it. Would you please let me know which Juno
OS version he had installed on the MX Chassis that works with the extended
memory command of it?

On Thu, May 5, 2022 at 12:50 PM Nick Olsen  wrote:

> Friend of mine had this issue recently on an MX chassis running DPC's and
> RE-2000's.
>
> The extend memory command others have mentioned worked for him.
>
> His instance drove us crazy for a bit. The device would learn a route,
> show that it was installed (show routes) but traffic to said prefix would
> bounce net unreachable. We even pushed a static just for S's and that
> still didn't resolve it. It was a single prefix that a customer had
> reported.
>
> Some things to consider, as others have mentioned.
>
>
>1. IPv6 routes share the same space. And use more per-route. You can
>extend the life of this box (probably considerably) by dropping full tables
>for IPv6. Perhaps taking just a default (Same goes for v4).
>2. It seems from your previous output that you're taking ~1 full v4
>table. And 2x v6 tables. Do you really need a full table if you're only
>taking 1 v4 table? Consider switching to a default only? In my Colleagues
>case, he was taking 2 full tables of v4 and v6 until he hit the same issue.
>3. While you're RE's could use a nice upgrade too. Your linecards are
>actually the problem here. If you move to anything > DPC you get the trio
>chipset with much more FIB space (2 Million routes I believe?). I'd
>consider new RE's and new line cards for this box. Which might also mean
>new switch fabric controllers Basically, we'd be talking a full
>overhaul sans the power supplies and chassis.
>4. Consider taking a default + full routes. Then filtering > /24 (if
>you even have anything < /24 learned now) (/48 on IPv6).
>
> Start with the memory command first and see where that gets you. But keep
> a watchful eye out for this to happen again (as the DFZ grows). Eventually
> your only option will be to filter routes and rely on a default or upgrade.
> --
> *From:* NANOG  on behalf of
> Nehul Patel 
> *Sent:* Wednesday, May 4, 2022 3:56 PM
> *To:* nanog@nanog.org 
> *Subject:* Strange behavior on the Juniper MX240
>
>
> Hi NANOG,
>
> We are seeing some strange behavior on our Juniper MX240 Chassis it is
> randomly dropping the routes to the certain destination IP address getting
> the following errors on the MX240 Chassis
>
> If Someone has seen these errors before please suggest how to resolve it
>
>
> May  4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to
> size>1024K
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5
> (Invalid)
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err
> 5 (Invalid)
> May  4 12:42:01   last message repeated 4 times
> May  4 12:42:01   fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry into
> jtree failed)
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028:
> rt_halp_vectors->rt_create failed
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len
> 48 prefix 2600:40fc:1011::/48 nh 1048576
> May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
> May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 (No
> memory) on FE 0
> May  4 12:42:01   fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry into
> jtree failed)
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028:
> rt_halp_vectors->rt_create failed
> May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len
> 48 prefix 2001:67c:20fc::/48 nh 1048576
> May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
> May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2606:2800:e004::/48
> (No memory) on FE 0
> May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2a05:3181:::/48
> (No memory) on FE 0
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err
> 5 (Invalid)
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5
> (Invalid)
> May  4 12:42:01   /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, err
> 5 (Invalid)
> May  4 12:42:02   fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No
> memory) on FE 0
> May  4 12:42:02   fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into jtree
> failed)
> May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2028:
> rt_halp_vectors->rt_create failed
> May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv4,len
> 24 prefix 79.120.22/24 nh 1048583
> May  4 12:42:02   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5
> (Invalid)
> May  4 12:42:02   fpc0 RT-HAL,rt_msg_handler,540: route process failed
>
> May  4 09:33:17   fpc0 RSMON: Resource Category:jtree
>  Instance:jtree2-seg0 Type:free-pages Available:20 is less than LWM
> limit:1638, rsmon_syslog_limit()
> May  4 09:33:17   fpc0 RSMON: Resource Category:jtree
>  Instance:jtree2-seg0 Type:free-dwords 

Re: Court orders for blocking of streaming services

[John Levine]

It appears that Joe Greco  said:
>While the issue of domains being confiscated and being handed over to a
>prevailing plaintiff for an international domain with no obvious nexus
>to the United States ...

Most of the domains do have US nexus. Two are in .TV, one in .COM,
both run by Verisign, one in .XYZ which is assigned to an LLC in Las
Vegas, registered via registrar Namecheap which is in Phoenix. .DEV is
Google, again registered via Namecheap. The ones in .AC .LY .TO and
the non-existent .ISR, not so much.

I agree that the rest of the language demanding that every ISP,
hosting provider, credit union, bank, and presumably nail salon and
coin laundry in the US stop serving the defendants is nuts.

The defendants didn't show up in court so the plantiffs would have
provided a proposed order which it looks like the court just rubber
stamped. That was pretty sloppy of her.

R's,
John

Re: Strange behavior on the Juniper MX240

[Nick Olsen]

Friend of mine had this issue recently on an MX chassis running DPC's and 
RE-2000's.

The extend memory command others have mentioned worked for him.

His instance drove us crazy for a bit. The device would learn a route, show 
that it was installed (show routes) but traffic to said prefix would bounce net 
unreachable. We even pushed a static just for S's and that still didn't 
resolve it. It was a single prefix that a customer had reported.

Some things to consider, as others have mentioned.


  1.  IPv6 routes share the same space. And use more per-route. You can extend 
the life of this box (probably considerably) by dropping full tables for IPv6. 
Perhaps taking just a default (Same goes for v4).
  2.  It seems from your previous output that you're taking ~1 full v4 table. 
And 2x v6 tables. Do you really need a full table if you're only taking 1 v4 
table? Consider switching to a default only? In my Colleagues case, he was 
taking 2 full tables of v4 and v6 until he hit the same issue.
  3.  While you're RE's could use a nice upgrade too. Your linecards are 
actually the problem here. If you move to anything > DPC you get the trio 
chipset with much more FIB space (2 Million routes I believe?). I'd consider 
new RE's and new line cards for this box. Which might also mean new switch 
fabric controllers Basically, we'd be talking a full overhaul sans the 
power supplies and chassis.
  4.  Consider taking a default + full routes. Then filtering > /24 (if you 
even have anything < /24 learned now) (/48 on IPv6).

Start with the memory command first and see where that gets you. But keep a 
watchful eye out for this to happen again (as the DFZ grows). Eventually your 
only option will be to filter routes and rely on a default or upgrade.

From: NANOG  on behalf of Nehul 
Patel 
Sent: Wednesday, May 4, 2022 3:56 PM
To: nanog@nanog.org 
Subject: Strange behavior on the Juniper MX240


Hi NANOG,

We are seeing some strange behavior on our Juniper MX240 Chassis it is randomly 
dropping the routes to the certain destination IP address getting the following 
errors on the MX240 Chassis

If Someone has seen these errors before please suggest how to resolve it


May  4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to size>1024K
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 
(Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 
(Invalid)
May  4 12:42:01   last message repeated 4 times
May  4 12:42:01   fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry into 
jtree failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 
prefix 2600:40fc:1011::/48 nh 1048576
May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 (No 
memory) on FE 0
May  4 12:42:01   fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry into jtree 
failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 
prefix 2001:67c:20fc::/48 nh 1048576
May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2606:2800:e004::/48 (No 
memory) on FE 0
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2a05:3181:::/48 (No 
memory) on FE 0
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 
(Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 
(Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, err 5 
(Invalid)
May  4 12:42:02   fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No memory) on 
FE 0
May  4 12:42:02   fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into jtree 
failed)
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv4,len 24 
prefix 79.120.22/24 nh 1048583
May  4 12:42:02   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 
(Invalid)
May  4 12:42:02   fpc0 RT-HAL,rt_msg_handler,540: route process failed

May  4 09:33:17   fpc0 RSMON: Resource Category:jtree  Instance:jtree2-seg0 
Type:free-pages Available:20 is less than LWM limit:1638, rsmon_syslog_limit()
May  4 09:33:17   fpc0 RSMON: Resource Category:jtree  Instance:jtree2-seg0 
Type:free-dwords Available:1280 is less than LWM limit:104857, 
rsmon_syslog_limit()
May  4 09:33:18   fpc0 RSMON: Resource Category:jtree  Instance:jtree3-seg0 
Type:free-pages Available:19 is less than LWM limit:1638, rsmon_syslog_limit()
May  4 09:33:18   fpc0 RSMON: Resource Category:jtree  Instance:jtree3-seg0 
Type:free-dwords Available:1216 is less than LWM limit:104857, 
rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: 

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

[Nehul Patel]

ok mark got it currently we are using the following DPCE Cards

DPCE-R-4XGE-XFP
DPCE-R-Q-4XGE-XFP

When we tried using the command set chassis memory-enhanced route on the
current Junos version 10.4 it says the command is not supported

so we will need to upgrade the Junos to the newer version in order to try
above command of it.



On Thu, May 5, 2022 at 11:55 AM Mark Tinka via NANOG <
ad...@community.nanog.org> wrote:

> Mark_Tinka4 
> May 5
>
> If memory serves, I believe the DPC used I-chip for Layer 3, and EZ-chip
> for Layer 2 (Ethernet framing + MAC look-up). Someone with a longer memory
> may need to chime in. Mark.
> --
>
> Visit Topic
> 
> to respond.
>
> To unsubscribe from these emails, click here
> 
> .
>
>

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 17:24, Nehul Patel wrote:


Ok Mark thank you for the suggestion we are currently running on the 
RE-S-1300 i am trying to check if juniper docs as the list of the DPCE 
with the I-Chip but not able to find it yet if you know DPCE model 
number let me know for it


If memory serves, I believe the DPC used I-chip for Layer 3, and EZ-chip 
for Layer 2 (Ethernet framing + MAC look-up).


Someone with a longer memory may need to chime in.

Mark.

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

[Nehul Patel]

Ok Mark thank you for the suggestion we are currently running on the
RE-S-1300 i am trying to check if juniper docs as the list of the DPCE with
the I-Chip but not able to find it yet if you know DPCE model number let me
know for it

On Thu, May 5, 2022, 08:20 Nehul Patel  wrote:

> Ok Mark thank you for the suggestion we are currently running on the
> RE-S-1300 i am trying to check if juniper docs as the list of the DPCE with
> the I-Chip but not able to find it yet if you know DPCE model number let me
> know for it
>
>
>
> On Thu, May 5, 2022, 01:46 Mark Tinka via NANOG 
> wrote:
>
>> Mark_Tinka4 
>> May 5
>>
>> Certainly an option, but this requires quite a bit of babysitting,
>> because as the DFZ oscillates, you can run into issues that send you into
>> circles, largely unaware about FIB issues, especially when just a subset of
>> routes are affected.
>>
>> So yes, definitely an option, but the OP will need to watch the line
>> cards like a hawk, and be ultra sensitive to debugging regular issues vs.
>> FIB-related issues.
>>
>> Mark.
>> --
>>
>> Visit Topic
>> 
>> to respond.
>>
>> To unsubscribe from these emails, click here
>> 
>> .
>>
>>
>

Re: Court orders for blocking of streaming services

[Grant Taylor via NANOG]

On 5/5/22 6:07 AM, Joe Greco wrote:

Greetings -


Hello,

Aside:  Any greeting more cheerful / up beat seems ... misplaced.


Recently, a court issued a troubling set of rulings in a default decision
against "Israel.TV" and some other sites.

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572373/gov.uscourts.nysd.572373.49.0.pdf


How can someone go to court with "unknown" information like in exhibit 
A?  This seems insultingly incomplete like someone simply didn't want to 
do their homework.



https://storage.courtlistener.com/recap/gov.uscourts.nysd.572374/gov.uscourts.nysd.572374.49.0.pdf

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572375/gov.uscourts.nysd.572375.53.0.pdf


I take umbrage at the fact that many of the domain names aren't actually 
domain names and instead are host names or URLs which are decidedly 
different than a domain name.


If you want someone else to do work on your behalf then you should have 
the decency and respect to give them /directly/ actionable and 
/accurate/ data.



This expansive clause basically demands that ISP's implement a
DNS override in recursers, which may be dubiously effective given
things such as DNSSEC and DNS-over-HTTPS complications.  This is
not an insignificant amount of work to implement, and since they
have not limited the list to big players, that means us small guys
would need to do this too.


As others have suggested, I would run this past in-house / retained 
lawyers before doing anything more than sending an email about it.



Perhaps more worryingly is the clause "by any technological means
available," which seems like it could be opening the door to
mandatory DPI filtering of port 53 traffic, an expensive and dicey
proposition, or filtering at the CPE for those who run dnsmasq on
busybox based CPE, etc., etc.


"diverted by the ISPs DNS servers" seems to be a very small subset of 
"by any technological means".


I'm waiting for the day that the plaintiff looses control of the landing 
page to the original defendants and uses the court order -- such as it 
is(n't) -- against the plaintiff.  --  "Hey, you failed to renew the 
domain for your landing page, so we did.  Now we are using your own 
ruling against you.  Either we get the traffic or your own landing page 
is filtered as a (Newly-Detected Website)."



This seems to be transferring the expense of complying to third
parties who had nothing to do with the pirate sites.


I feel like "undue burden" is going to come into play here.


And how is this practical when this scales to hundreds or thousands
of such rulings?


As it is, it won't.


Is anybody here considering recovering compliance costs from the
plaintiffs?


:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

EzIP vs. YADA & YATT Re: Ready to compromise? was RE: V6 still not supported

[Abraham Y. Chen]

Dear Pascal:

Have not heard your follow-up thoughts and comments.

It would be much appreciated if we can carry this dialog forward.

Regards,


Abe (2022-05-05 11:23 EDT)



On 2022-04-21 17:38, Abraham Y. Chen wrote:

Dear Pascal:

0) Thanks for your clarification. It enabled me to study your draft a 
little closer and came up with the following observations to share.


1) "Yes, this is plain IP in IP. For a router does not know about 
YADA, this looks like the most basic form of tunnel you can get.":


Not really. I believe that any networking stack conforming to the 
Options mechanism in RC791 can achieve the same, thus more concise and 
less involved. Please see Figure 4 of EzIP Draft.


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space

2) " 1. 
Introduction 
and Motivation 
 
The proposed benefit is a thousandfold increase of the 
IPv4-addressable domain by building parallel realms each potentially 
the size of the current Internet.


"2.2. 
New 
Terms 
 


            This document often uses the following new terms:

  # IPv4 realm:

  # A full IPv4 network like the current Internet. YADA does not
affect the traditional IPv4 operations within a realm.":

These are the critical statements that led to one of my two initial 
questions. That is, are you proposing to have N (>250 as an example 
cited in your draft) realms that each has the full IPv4 address pool 
capacity (after deducted for certain special functions)? This will be 
fine if each realm was occupying one floor of a stand-alone  
skyscraper. I can not visualize this architecture when it is expanded 
to cover the whole earth, since each of them can operate with all the 
IPv4 addresses. Not only physically impossible to build such a 
skyscraper, but also how can we form 250 independent overlays on top 
of the entire IPv4 based Internet? Is there any mechanism that can 
isolate the respective transmission media of the 250 realms from one 
another?


3) " 1. 
Introduction 
and Motivation 
 
 Connectivity between an IPv4-only node and an IPv6-only node, or 
between an IPv4-only node and a YADA node in different realm, still 
requires a CG-NATs as of today,  ":


Since eliminating the CG-NAT practice is one of the general 
motivations for address expansion efforts, I am puzzled by why are you 
still keeping it, and for how long? In contrast, upon the initial RAN 
(Regional Area Network) deployment, the CG-NAT will be retired from 
EzIP environment.


4)   "Figure 2 
: 
YADA format in the source realm 
 
YADA also requires a change for the routers that serve the shaft.":


    Are you saying that an IoT in a realm wishing to communicate with 
another in a separate realm does not need to know about this format 
nor something equivalent to convey such inter-realm address information?


5) "Figure 4 
: 
YADA format inside the shaft 
 
":


This particular format closely resembles that of EzIP (see EzIP Draft 
Figure 4 mentioned above), where "outer IPv4 header" part of five 
words carrying the two realms' address information are conveyed by 
words 4 & 5 of a standard IPv4 header, while the IoT (inner) addresses 
are transported by three Options words. The EzIP format enables the 
EzIP implementation to stay within the RFC791 specifications, no need 
to go beyond.


6) Below is my quick digest and comparison of our two projects by 
partially paraphrasing YADA terminology:


A.    Since there is no way to build a 250 floor skyscraper covering 
the entire globe for physical isolation between floors (realms), it is 
difficult to visualize how could the same IP address be used by 250 
separate parties as proposed by YADA without the fundamental address 
conflict issue. How to provide a medium that has 250 fully isolated 
layers, each capable of transporting the full set of IPv4 addresses, 
seems to be the challenge.


B.    The function of YADA format probably can be achieved by making 
use of the Options mechanism under RFC791, so that IP header can stay 
basic.


C.    The EzIP scheme is less capable than YADA, but 

Re: Strange behavior on the Juniper MX240

[Nehul Patel]

Ok got it saku we will got with the direct upgrade of it

On Wed, May 4, 2022, 22:34 Saku Ytti  wrote:

> Almost always direct upgrade works. If you ask TAC, they will likely
> suggest a formal process and you'll be doing many upgrades, which
> itself isn't actually something that is guaranteed to work (like in
> WRL9 case, but that is vmhost RE, not yours).
>
> And like Jordan said, you are out of resources but can extend them
> with the command given, which should give you more run rate. You may
> want to look in more detail how long you can keep running DPCE until
> you're really out.
>
>
> On Thu, 5 May 2022 at 06:08, Nehul Patel  wrote:
> >
> > Ok, thank you all for the feedback we are going to start with the Junos
> OS upgrade first on it but have to open the ticket with JTAC since
> currently on the juniper support website they have the Junos 15.1 is
> available so not sure we can directly jump from 10.4 to 15.1 maybe we have
> to do step by step upgrade on it. Any other suggestions will be helpful as
> well
> >
> > By the way, the uptime on the Juniper MX chassis was 1589 Days on it.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, May 4, 2022 at 7:11 PM Jordan  wrote:
> >>
> >> Your line cards (not RE's) are running out of route-storage memory.
> >> As a short-term mitigation, you could try borrowing from segment 1,
> >> normally dedicated to filters,
> >>
> >> set chassis memory-enhanced route
> >>
> >> but this option may not exist in the version of JunOS you're
> >> running, which as already mentioned is very old.
> >>
> >> If the command is accepted, and it lets you commit, you'll then
> >> need to restart each of the FPC's, one at a time, by slot number,
> >> which will take each out of service for a few minutes, so you
> >> probably want to wait until a scheduled maintenance period, and
> >> start with less-important FPC slots first:
> >>
> >> request chassis fpc restart slot X
> >>
> >>
> >>
> >> On Wed, May 04, 2022 at 02:34:45PM -0700, Nehul Patel wrote:
> >> > Thank you Saku and the warren  Here is the requested output
> >> >
> >> >
> >> > show route summary
> >> >
> >> > inet.0: 879635 destinations, 879649 routes (879634 active, 0
> holddown, 1
> >> > hidden)
> >> >   Direct:  9 routes,  8 active
> >> >Local:  8 routes,  8 active
> >> > OSPF:928 routes,925 active
> >> >  BGP: 878686 routes, 878678 active
> >> >   Static:  2 routes,  2 active
> >> >Aggregate: 15 routes, 12 active
> >> >
> >> > inet.3: 718 destinations, 718 routes (718 active, 0 holddown, 0
> hidden)
> >> >  LDP:718 routes,718 active
> >> >
> >> > Test_VRF.inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0
> hidden)
> >> >Local:  1 routes,  1 active
> >> >
> >> > mpls.0: 390 destinations, 390 routes (390 active, 0 holddown, 0
> hidden)
> >> > MPLS:  3 routes,  3 active
> >> >  LDP:387 routes,387 active
> >> >
> >> > inet6.0: 143065 destinations, 286099 routes (143065 active, 0
> holddown, 0
> >> > hidden)
> >> >   Direct: 13 routes,  9 active
> >> >Local: 10 routes, 10 active
> >> >OSPF3: 16 routes, 15 active
> >> >  BGP: 286060 routes, 143030 active
> >> >   Static:  1 routes,  1 active
> >> >
> >> > show chassis fpc
> >> >  Temp  CPU Utilization (%)   Memory
> Utilization (%)
> >> > Slot State(C)  Total  Interrupt  DRAM (MB) Heap
>  Buffer
> >> >   0  Online31 11  0   1024   37
>29
> >> >   1  Online31 11  0   1024   45
>29
> >> >   2  Online30  4  0   1024   36
>29
> >> >
> >> > request pfe execute target fpc0 command "show jtree 0 memory
> extensive"
> >> > SENT: Ukern command: show jtree 0 memory extensive
> >> > GOT:
> >> > GOT: Jtree memory segment 0 (Context: 0x44817bb0)
> >> > GOT: ---
> >> > GOT: Memory Statistics:
> >> > GOT:16777216 bytes total
> >> > GOT:16715144 bytes used
> >> > GOT:   56880 bytes available (7168 bytes from free pages)
> >> > GOT:3024 bytes wasted
> >> > GOT:2168 bytes unusable
> >> > GOT:   32768 pages total
> >> > GOT:   32519 pages used (2568 pages used in page alloc)
> >> > GOT: 235 pages partially used
> >> > GOT:  14 pages free (max contiguous = 6)
> >> > GOT:
> >> > GOT:  Partially Filled Pages (In bytes):-
> >> > GOT:   UnitAvail Overhead
> >> > GOT:  8262560
> >> > GOT: 16143200
> >> > GOT: 24 8352 2040
> >> > GOT: 32  3520
> >> > GOT: 48  432  128
> >> > GOT:
> >> > GOT:  Free Page Lists(Pg Size = 512 bytes):-
> >> > GOT:  

10 Do's + Don'ts for Visiting Québec + Register Now for N85!

[Nanog News]

*10 Do's + Don'ts for Visiting Québec*
*NANOG 85 Meeting Will Take Place Jun. 6 - 8 in Montréal*

We are delighted to cross international borders in our mission to grow,
inspire + profoundly build the Internet of tomorrow!

Montréal is Canada's second-largest city and is known for its melting pot
of diverse culture, established universities, enthralling art, food,
history + festivals. It has been called one of the world's "happiest
locations" as an estimated 45,000 immigrants relocate to the city every
year.

For those who don't call Québec home, we have prepared a list of cultural
"Do's and Don'ts" to help you quickly acclimate + thrive in this foreign
destination.

*READ MORE  *

*Register for NANOG 85 Today!*

Join us in person or virtually for NANOG 85. Don't miss your chance to
experience hours of ground-breaking industry talks, a legendary keynote
speaker, opportunities for networking + more.

*REGISTER NOW *

[NANOG-announce] 10 Do's + Don'ts for Visiting Québec + Register Now for N85!

[Nanog News]

*10 Do's + Don'ts for Visiting Québec*
*NANOG 85 Meeting Will Take Place Jun. 6 - 8 in Montréal*

We are delighted to cross international borders in our mission to grow,
inspire + profoundly build the Internet of tomorrow!

Montréal is Canada's second-largest city and is known for its melting pot
of diverse culture, established universities, enthralling art, food,
history + festivals. It has been called one of the world's "happiest
locations" as an estimated 45,000 immigrants relocate to the city every
year.

For those who don't call Québec home, we have prepared a list of cultural
"Do's and Don'ts" to help you quickly acclimate + thrive in this foreign
destination.

*READ MORE  *

*Register for NANOG 85 Today!*

Join us in person or virtually for NANOG 85. Don't miss your chance to
experience hours of ground-breaking industry talks, a legendary keynote
speaker, opportunities for networking + more.

*REGISTER NOW *
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Court orders for blocking of streaming services

[John Curran]

On 5 May 2022, at 7:12 AM, William Herrin 
mailto:b...@herrin.us>> wrote:

On Thu, May 5, 2022 at 3:09 AM Joe Greco 
mailto:jgr...@ns.sol.net>> wrote:
It seems to me like the court overstepped here and issued a ruling
that contained a lot of wishful thinking that doesn't reflect the
ability of miscreants on the Internet to just rapidly register a new
domain name with a new fake credit card.  Certainly it is trivial
to host the actual websites well out of legal reach of US courts,
and with domain registrars without US presence.  This leaves those
of us in the network operations community in the position of
shouldering costs to comply with a court order, but without a clear
mechanism to continue to be in compliance.  This could become a full
time job, if the defendants want to play the game right.  
"israel.tv"?
"1srael.tv" (with a "1" or "L" for the first letter, etc).

Is anybody here considering recovering compliance costs from the
plaintiffs?

Check with your lawyer to be sure and then ignore the ruling. A judge
in a civil case definitely does not have the authority to bind folks
who are not parties to the suit. It's a fairly basic due process
issue.

Bill -

That approach may be viable with one judgement from a court that you don’t 
share jurisdiction with, but probably doesn’t scale any more than the proposed 
technical measures...

I.e.  it’s probably wise for there to be some degree of constructive engagement 
and education over these orders, as absence of such will inevitably lead to an 
abundance of similar rulings as other plaintiffs in the online content industry 
seek the same “all ISP” remedies - e.g., from 
 -

"In the approaching months and years, it’ll be interesting to see whether the 
move becomes a common component of judgements in similar stateside cases.”

Best wishes,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: Court orders for blocking of streaming services

[William Herrin]

On Thu, May 5, 2022 at 3:09 AM Joe Greco  wrote:
> It seems to me like the court overstepped here and issued a ruling
> that contained a lot of wishful thinking that doesn't reflect the
> ability of miscreants on the Internet to just rapidly register a new
> domain name with a new fake credit card.  Certainly it is trivial
> to host the actual websites well out of legal reach of US courts,
> and with domain registrars without US presence.  This leaves those
> of us in the network operations community in the position of
> shouldering costs to comply with a court order, but without a clear
> mechanism to continue to be in compliance.  This could become a full
> time job, if the defendants want to play the game right.  "israel.tv"?
> "1srael.tv" (with a "1" or "L" for the first letter, etc).
>
> Is anybody here considering recovering compliance costs from the
> plaintiffs?

Check with your lawyer to be sure and then ignore the ruling. A judge
in a civil case definitely does not have the authority to bind folks
who are not parties to the suit. It's a fairly basic due process
issue.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Court orders for blocking of streaming services

[John Curran]

Joe - 

All excellent questions.  The Internet is a relatively new phenomenon when it 
comes to the US court system and thus there has always been an ongoing risk of 
“interesting” court orders that are shaped by primarily by the plaintiffs 
understanding of the Internet (rather than being shaped and/or anchored in the 
reality of those who operate the various services that actually make the 
Internet function.) 

I would suspect that several of the larger ISPs involved and the some of the 
providers of DNS services will respond to such an order, but it is not assured. 
 (ARIN regularly reviews federal orders issued that might preclude operation of 
the Internet number registry service accordingly to the wishes of the 
community, and the issuance of these orders were noted but do not appear not 
applicable to our services.)   

It’s also possible that some of the US telecommunications/Internet trade 
associations might respond, as they have regulatory and legal folks dedicated 
to such activities (i.e. WISPA, FISPA, NCTA, CA, CTIA, etc.)  – If you are a 
member of one of those associations, then it’s worth inquiring with them. 

Best wishes,
/John

John Curran
President and CEO
American Registry for Internet Numbers


> On 5 May 2022, at 8:07 AM, Joe Greco  wrote:
> 
> Greetings -
> 
> Recently, a court issued a troubling set of rulings in a default decision
> against "Israel.TV" and some other sites.
> 
> https://storage.courtlistener.com/recap/gov.uscourts.nysd.572373/gov.uscourts.nysd.572373.49.0.pdf
> 
> https://storage.courtlistener.com/recap/gov.uscourts.nysd.572374/gov.uscourts.nysd.572374.49.0.pdf
> 
> https://storage.courtlistener.com/recap/gov.uscourts.nysd.572375/gov.uscourts.nysd.572375.53.0.pdf
> 
> While the issue of domains being confiscated and being handed over to a
> prevailing plaintiff for an international domain with no obvious nexus
> to the United States by a United States court via orders to companies
> that happen to be in the United States is a bit of a concerning issue,
> that's not operationally relevant.
> 
> What's more concerning is that the ruling includes an expansive clause
> B, "Against Internet Service Providers (ISPs):"
> 
>   IT IS FURTHER ORDERED that all ISPs (including without
>   limitation those set forth in Exhibit B hereto) and any
>   other ISPs providing services in the United States shall
>   block access to the Website at any domain address known
>   today (including but not limited to those set forth in
>   Exhibit A hereto) or to be used in the future by the
>   Defendants (.Newly-Detected Websites.) by any technological
>   means available on the ISPs. systems. The domain addresses
>   and any NewlyDetected Websites shall be channeled in such
>   a way that users will be unable to connect and/or use the
>   Website, and will be diverted by the ISPs. DNS servers
>   to a landing page operated and controlled by Plaintiffs
>   (the .Landing Page.) which can be reached as follows:
> 
> This expansive clause basically demands that ISP's implement a
> DNS override in recursers, which may be dubiously effective given
> things such as DNSSEC and DNS-over-HTTPS complications.  This is
> not an insignificant amount of work to implement, and since they
> have not limited the list to big players, that means us small guys
> would need to do this too.
> 
> Perhaps more worryingly is the clause "by any technological means
> available," which seems like it could be opening the door to 
> mandatory DPI filtering of port 53 traffic, an expensive and dicey
> proposition, or filtering at the CPE for those who run dnsmasq on
> busybox based CPE, etc., etc.
> 
> This seems to be transferring the expense of complying to third
> parties who had nothing to do with the pirate sites.
> 
> Complying with random court orders where there isn't even a formal
> notice that there's been a court order is problematic.  I would
> guess that the 96 ISP's listed in the order are going to receive a
> formal notice, but by what mechanism does the court think that a
> small service provider would even be aware of such an order?
> 
> What happens with respect to the "Newly Detected Websites"?  What
> mechanism exists here?
> 
> Who is going to pay for the costs?
> 
> And how is this practical when this scales to hundreds or thousands
> of such rulings?
> 
> It seems to me like the court overstepped here and issued a ruling
> that contained a lot of wishful thinking that doesn't reflect the
> ability of miscreants on the Internet to just rapidly register a new
> domain name with a new fake credit card.  Certainly it is trivial
> to host the actual websites well out of legal reach of US courts, 
> and with domain registrars without US presence.  This leaves those
> of us in the network operations community in the position of
> shouldering costs to comply with a court order, but without a clear
> mechanism to continue to be in compliance.  This 

Court orders for blocking of streaming services

[Joe Greco]

Greetings -

Recently, a court issued a troubling set of rulings in a default decision
against "Israel.TV" and some other sites.

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572373/gov.uscourts.nysd.572373.49.0.pdf

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572374/gov.uscourts.nysd.572374.49.0.pdf

https://storage.courtlistener.com/recap/gov.uscourts.nysd.572375/gov.uscourts.nysd.572375.53.0.pdf

While the issue of domains being confiscated and being handed over to a
prevailing plaintiff for an international domain with no obvious nexus
to the United States by a United States court via orders to companies
that happen to be in the United States is a bit of a concerning issue,
that's not operationally relevant.

What's more concerning is that the ruling includes an expansive clause
B, "Against Internet Service Providers (ISPs):"

IT IS FURTHER ORDERED that all ISPs (including without
limitation those set forth in Exhibit B hereto) and any
other ISPs providing services in the United States shall
block access to the Website at any domain address known
today (including but not limited to those set forth in
Exhibit A hereto) or to be used in the future by the
Defendants (.Newly-Detected Websites.) by any technological
means available on the ISPs. systems. The domain addresses
and any NewlyDetected Websites shall be channeled in such
a way that users will be unable to connect and/or use the
Website, and will be diverted by the ISPs. DNS servers
to a landing page operated and controlled by Plaintiffs
(the .Landing Page.) which can be reached as follows:

This expansive clause basically demands that ISP's implement a
DNS override in recursers, which may be dubiously effective given
things such as DNSSEC and DNS-over-HTTPS complications.  This is
not an insignificant amount of work to implement, and since they
have not limited the list to big players, that means us small guys
would need to do this too.

Perhaps more worryingly is the clause "by any technological means
available," which seems like it could be opening the door to 
mandatory DPI filtering of port 53 traffic, an expensive and dicey
proposition, or filtering at the CPE for those who run dnsmasq on
busybox based CPE, etc., etc.

This seems to be transferring the expense of complying to third
parties who had nothing to do with the pirate sites.

Complying with random court orders where there isn't even a formal
notice that there's been a court order is problematic.  I would
guess that the 96 ISP's listed in the order are going to receive a
formal notice, but by what mechanism does the court think that a
small service provider would even be aware of such an order?

What happens with respect to the "Newly Detected Websites"?  What
mechanism exists here?

Who is going to pay for the costs?

And how is this practical when this scales to hundreds or thousands
of such rulings?

It seems to me like the court overstepped here and issued a ruling
that contained a lot of wishful thinking that doesn't reflect the
ability of miscreants on the Internet to just rapidly register a new
domain name with a new fake credit card.  Certainly it is trivial
to host the actual websites well out of legal reach of US courts, 
and with domain registrars without US presence.  This leaves those
of us in the network operations community in the position of
shouldering costs to comply with a court order, but without a clear
mechanism to continue to be in compliance.  This could become a full
time job, if the defendants want to play the game right.  "israel.tv"?
"1srael.tv" (with a "1" or "L" for the first letter, etc).

Is anybody here considering recovering compliance costs from the
plaintiffs?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 07:34, Saku Ytti wrote:


And like Jordan said, you are out of resources but can extend them
with the command given, which should give you more run rate. You may
want to look in more detail how long you can keep running DPCE until
you're really out.


Certainly an option, but this requires quite a bit of babysitting, 
because as the DFZ oscillates, you can run into issues that send you 
into circles, largely unaware about FIB issues, especially when just a 
subset of routes are affected.


So yes, definitely an option, but the OP will need to watch the line 
cards like a hawk, and be ultra sensitive to debugging regular issues 
vs. FIB-related issues.


Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 05:08, Nehul Patel wrote:

Ok, thank you all for the feedback we are going to start with the 
Junos OS upgrade first on it but have to open the ticket with JTAC 
since currently on the juniper support website they have the Junos 
15.1 is available so not sure we can directly jump from 10.4 to 15.1 
maybe we have to do step by step upgrade on it. Any other suggestions 
will be helpful as well


By the way, the uptime on the Juniper MX chassis was 1589 Days on it.


Curious, what RE are you running?

If you have DPC's still, I'd assume something like the RE-S-1300 or 
RE-S-2000, but not sure.


I ask because I'm not how late the older RE's can go.

Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/5/22 04:11, Jordan wrote:


Your line cards (not RE's) are running out of route-storage memory.
As a short-term mitigation, you could try borrowing from segment 1,
normally dedicated to filters,

set chassis memory-enhanced route

but this option may not exist in the version of JunOS you're
running, which as already mentioned is very old.


This feature was introduced in 10.4, so he should have it.

And yes, it's only supported for DPC's (I-chip).

Mark.

Re: Strange behavior on the Juniper MX240

[Mark Tinka]

On 5/4/22 21:56, Nehul Patel wrote:


Hi NANOG,

We are seeing some strange behavior on our Juniper MX240 Chassis it is 
randomly dropping the routes to the certain destination IP address 
getting the following errors on the MX240 Chassis


If Someone has seen these errors before please suggest how to resolve it


May  4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to 
size>1024K
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, 
err 5 (Invalid)

May  4 12:42:01   last message repeated 4 times
May  4 12:42:01   fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry 
into jtree failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto 
ipv6,len 48 prefix 2600:40fc:1011::/48 nh 1048576

May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 
(No memory) on FE 0
May  4 12:42:01   fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry 
into jtree failed)
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:01   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto 
ipv6,len 48 prefix 2001:67c:20fc::/48 nh 1048576

May  4 12:42:01   fpc0 RT-HAL,rt_msg_handler,540: route process failed
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 
2606:2800:e004::/48 (No memory) on FE 0
May  4 12:42:01   fpc0 RT: Failed prefix add IPv6 - 
2a05:3181:::/48 (No memory) on FE 0
May  4 12:42:01   /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, 
err 5 (Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)
May  4 12:42:01   /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, 
err 5 (Invalid)
May  4 12:42:02   fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No 
memory) on FE 0
May  4 12:42:02   fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into 
jtree failed)
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2028: 
rt_halp_vectors->rt_create failed
May  4 12:42:02   fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto 
ipv4,len 24 prefix 79.120.22/24 nh 1048583
May  4 12:42:02   /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, 
err 5 (Invalid)

May  4 12:42:02   fpc0 RT-HAL,rt_msg_handler,540: route process failed

May  4 09:33:17   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-pages Available:20 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:17   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-dwords Available:1280 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-pages Available:19 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:18   fpc0 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-dwords Available:1216 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-pages Available:16 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-dwords Available:1024 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-pages Available:15 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-dwords Available:960 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:18   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-pages Available:19 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree2-seg0 Type:free-dwords Available:1216 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:19   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-pages Available:17 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc1 RSMON: Resource Category:jtree 
 Instance:jtree3-seg0 Type:free-dwords Available:1088 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-pages Available:15 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree0-seg0 Type:free-dwords Available:960 is less than LWM 
limit:104857, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-pages Available:15 is less than LWM 
limit:1638, rsmon_syslog_limit()
May  4 09:33:19   fpc2 RSMON: Resource Category:jtree 
 Instance:jtree1-seg0 Type:free-dwords Available:960 is less than LWM 
limit:104857, rsmon_syslog_limit()


Any suggestions will 

Re: DMARC ViolationDKIM ViolationRe: Strange behavior on the Juniper MX240

[Nehul Patel]

Ok thank you Harold we currently have the multihomed setup so we are still
planning to address it in the bestway

For the Junos OS we can go 10.4 to 15.1 directly from the USB installer
will be helpful also is their any tools available we can validate the
config before upgrading it

On Wed, May 4, 2022, 20:50 Paschal Masha 
wrote:

> Try setting "keep-none" on your BGP  neighbor (s) not sure if it'll still
> need the cards rebooted equally you can also just accept a default route or
> wait for TAC to take over :)
>
>
>
> Regards
> Paschal Masha | Engineering
> Skype ID: paschal.masha
>
>
> --
> *From: *"Nehul Patel" 
> *To: *"Jordan" 
> *Cc: *"nanog" 
> *Sent: *Thursday, May 5, 2022 06:08:05 AM
> *Subject: *DMARC ViolationDKIM ViolationRe: Strange behavior on the
> Juniper MX240
>
> Ok, thank you all for the feedback we are going to start with the Junos OS
> upgrade first on it but have to open the ticket with JTAC since currently
> on the juniper support website they have the Junos 15.1 is available so not
> sure we can directly jump from 10.4 to 15.1 maybe we have to do step by
> step upgrade on it. Any other suggestions will be helpful as well
>
> By the way, the uptime on the Juniper MX chassis was 1589 Days on it.
>
>
>
>
>
>
>
>
>
>
> On Wed, May 4, 2022 at 7:11 PM Jordan  wrote:
>
>> Your line cards (not RE's) are running out of route-storage memory.
>> As a short-term mitigation, you could try borrowing from segment 1,
>> normally dedicated to filters,
>>
>> set chassis memory-enhanced route
>>
>> but this option may not exist in the version of JunOS you're
>> running, which as already mentioned is very old.
>>
>> If the command is accepted, and it lets you commit, you'll then
>> need to restart each of the FPC's, one at a time, by slot number,
>> which will take each out of service for a few minutes, so you
>> probably want to wait until a scheduled maintenance period, and
>> start with less-important FPC slots first:
>>
>> request chassis fpc restart slot X
>>
>>
>>
>> On Wed, May 04, 2022 at 02:34:45PM -0700, Nehul Patel wrote:
>> > Thank you Saku and the warren  Here is the requested output
>> >
>> >
>> > show route summary
>> >
>> > inet.0: 879635 destinations, 879649 routes (879634 active, 0 holddown, 1
>> > hidden)
>> >   Direct:  9 routes,  8 active
>> >Local:  8 routes,  8 active
>> > OSPF:928 routes,925 active
>> >  BGP: 878686 routes, 878678 active
>> >   Static:  2 routes,  2 active
>> >Aggregate: 15 routes, 12 active
>> >
>> > inet.3: 718 destinations, 718 routes (718 active, 0 holddown, 0 hidden)
>> >  LDP:718 routes,718 active
>> >
>> > Test_VRF.inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0
>> hidden)
>> >Local:  1 routes,  1 active
>> >
>> > mpls.0: 390 destinations, 390 routes (390 active, 0 holddown, 0 hidden)
>> > MPLS:  3 routes,  3 active
>> >  LDP:387 routes,387 active
>> >
>> > inet6.0: 143065 destinations, 286099 routes (143065 active, 0 holddown,
>> 0
>> > hidden)
>> >   Direct: 13 routes,  9 active
>> >Local: 10 routes, 10 active
>> >OSPF3: 16 routes, 15 active
>> >  BGP: 286060 routes, 143030 active
>> >   Static:  1 routes,  1 active
>> >
>> > show chassis fpc
>> >  Temp  CPU Utilization (%)   MemoryUtilization
>> (%)
>> > Slot State(C)  Total  Interrupt  DRAM (MB) Heap
>>  Buffer
>> >   0  Online31 11  0   1024   37
>>  29
>> >   1  Online31 11  0   1024   45
>>  29
>> >   2  Online30  4  0   1024   36
>>  29
>> >
>> > request pfe execute target fpc0 command "show jtree 0 memory extensive"
>> > SENT: Ukern command: show jtree 0 memory extensive
>> > GOT:
>> > GOT: Jtree memory segment 0 (Context: 0x44817bb0)
>> > GOT: ---
>> > GOT: Memory Statistics:
>> > GOT:16777216 bytes total
>> > GOT:16715144 bytes used
>> > GOT:   56880 bytes available (7168 bytes from free pages)
>> > GOT:3024 bytes wasted
>> > GOT:2168 bytes unusable
>> > GOT:   32768 pages total
>> > GOT:   32519 pages used (2568 pages used in page alloc)
>> > GOT: 235 pages partially used
>> > GOT:  14 pages free (max contiguous = 6)
>> > GOT:
>> > GOT:  Partially Filled Pages (In bytes):-
>> > GOT:   UnitAvail Overhead
>> > GOT:  8262560
>> > GOT: 16143200
>> > GOT: 24 8352 2040
>> > GOT: 32  3520
>> > GOT: 48  432  128
>> > GOT:
>> > GOT:  Free Page Lists(Pg Size = 512 bytes):-
>> > GOT:Page Bucket Avail(Bytes)
>> >