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

2016-09-18 Thread Saku Ytti 
On 18 September 2016 at 10:18, Chuck Anderson  wrote:

Hey,

> 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.

I've seen similar in ISSU years ago. Once after ISSU lo0 filter
dropped LDP, another time after ISSU one particular customer filter
was dropping things it should not have, forcing reprogramming helped
in both case.

And yeah, probably is going to be challenging to reproduce. I wonder
if implementations even try to verify correctness, do they ask HW
about state they just changed/added/removed, to confirm what code
asked actually did occur.

Not picking on Juniper here, I've seen various HW programming issues
in other vendors too.
-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

2016-09-18 Thread Diogo Montagner 
This sounds like activating enhanced-ip and forgetting to reboot the box
immediately after it.

I never saw this type of issue caused by upgrades.

On Sunday, 18 September 2016, Chuck Anderson  wrote:

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


-- 
./diogo -montagner
JNCIE-SP 0x41A
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

2016-09-18 Thread Olivier Benghozi 
Updated from 14.2 to 15.1R here (on several MX, same RE hardware).
Didn't see this issue.
Any particular stuff in your filters ?

> Le 18 sept. 2016 à 09:18, Chuck Anderson  a écrit :
> 
> 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

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

2016-09-18 Thread 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.

2016-09-18 Thread 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