[j-nsp] RES: LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[Alexandre Guimaraes]

Had experienced the same thing.

After adding this to the loopback filter, the problem gone


set firewall family inet filter PROTECT-RE term aceita-ldp from protocol tcp
set firewall family inet filter PROTECT-RE term aceita-ldp from protocol udp
set firewall family inet filter PROTECT-RE term aceita-ldp from source-port 646
set firewall family inet filter PROTECT-RE term aceita-ldp from 
destination-port 646
set firewall family inet filter PROTECT-RE term aceita-ldp then accept

Alexandre

-Mensagem original-
De: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Em nome de joel 
ahumuza
Enviada em: quinta-feira, 28 de abril de 2016 12:38
Para: juniper-nsp@puck.nether.net
Cc: t...@roketelkom.co.ug
Assunto: [j-nsp] LDP flaps specifically present on ACX Juniper routers (ACX4000 
and ACX1100)

Hi All,

We are experiencing an issue with ACX routers running on 12.3X54-D20.7 where 
the LDP sessions are continuously flapping, the logs indicate the following;

Apr 21 03:36:31  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x 
is down, reason: hold time expired Apr 21 03:36:34  hostname rpd[2299]: 
RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x 
is down, reason: all adjacencies down Apr 21 03:55:34  hostname rpd[2299]: 
RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification 
from peer Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session 
x.x.x.x is down, reason: received notification from peer Apr 21 03:55:35  
hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: 
received notification from peer Apr 21 03:55:35  hostname rpd[2299]: 
RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received notification 
from peer

The physical connections are okay, no flaps or errors on the p2p connections We 
are running ISIS as the IGP, whose adjacency is stable.

Actions taken from our team was;
- Increase the hold time setting on the ldp enabled interfaces.
- Increase the time interval on the same ldp enabled interfaces.
- setting the ldp session protection setting on the ldp enabled loopback 
interface.

Unfortunately the actions did not yield much since the flaps have been ongoing.

Anyone have any Idea on what the problem / solution might be?

--
Blessings,

AJ.
SkypeID - jl.hmz
ahumuza-joel.blogspot.ug
___
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

Re: [j-nsp] LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[raf]

Yep the software poller I was using, make a lot of bulk walk on the 
entire part of the Mib (I was using observium and it had a so poorly 
coded poller).
Other software made more intelligent polling using cache and atomic get 
(like cacti).
Anyway even a bad snmp poller should not kill the control plane of a 
router/switch.
Junos should have implemented software qos, leaving some cpu time for 
critical daemon (rpd, lacpd, etc..) or even better use a real time os 
(like some other vendor do)...
The fun thing is that manually nicing the snmpd process help. I wonder 
why juniper does do that by default ?


--
Raphael Mazelier

Le 28/04/2016 à 22:02, Aaron a écrit :

About snmp...

Is your Management station walking the entire mib tree of your devices ?!

I've experienced over the years that when I management station is NOT tuned
appropriately, it WILL spike the processors of your routers/switches during
the polling cycle, like every 15 minutes or so, whatever it is set to.

I'm not sure this is your problem, but it could be.

Aaron

p.s. it's probably dumb/unnecessary to have a snmp mgmt. station hit all the
OIDs on the network devices since you probably don't want/need that much
info queried anyway.



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
raf
Sent: Thursday, April 28, 2016 11:03 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] LDP flaps specifically present on ACX Juniper routers
(ACX4000 and ACX1100)

Hi,

Is your RE cpu utilisation is OK or not ?

I have similars issues on EX during snmp polling, which are eating all the
cpu time.



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

Re: [j-nsp] LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[Aaron]

Are the ldp id's /32's ?

They might need to be, I don't recall, but I will say that I always use
/32's on a loopback and then add that loopback and the phy int to the ldp
process...

agould@eng-lab-5048-1# show protocols ldp
interface ae0.0;
interface ae10.0;
interface lo0.0;

{master:0}[edit]
agould@eng-lab-5048-1# show protocols mpls
interface ae0.0;
interface ae10.0;

{master:0}[edit]
agould@eng-lab-5048-1# show routing-options
router-id 10.101.12.245;


Aaron

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
joel ahumuza
Sent: Thursday, April 28, 2016 10:38 AM
To: juniper-nsp@puck.nether.net
Cc: t...@roketelkom.co.ug
Subject: [j-nsp] LDP flaps specifically present on ACX Juniper routers
(ACX4000 and ACX1100)

Hi All,

We are experiencing an issue with ACX routers running on 12.3X54-D20.7 where
the LDP sessions are continuously flapping, the logs indicate the following;

Apr 21 03:36:31  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: hold time expired Apr 21 03:36:34  hostname
rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: all adjacencies down Apr 21 03:55:34  hostname
rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason:
received notification from peer Apr 21 03:55:34  hostname rpd[2299]:
RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received
notification from peer Apr 21 03:55:35  hostname rpd[2299]:
RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received
notification from peer Apr 21 03:55:35  hostname rpd[2299]:
RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received
notification from peer

The physical connections are okay, no flaps or errors on the p2p connections
We are running ISIS as the IGP, whose adjacency is stable.

Actions taken from our team was;
- Increase the hold time setting on the ldp enabled interfaces.
- Increase the time interval on the same ldp enabled interfaces.
- setting the ldp session protection setting on the ldp enabled loopback
interface.

Unfortunately the actions did not yield much since the flaps have been
ongoing.

Anyone have any Idea on what the problem / solution might be?

--
Blessings,

AJ.
SkypeID - jl.hmz
ahumuza-joel.blogspot.ug
___
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

Re: [j-nsp] LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[Aaron]

About snmp...

Is your Management station walking the entire mib tree of your devices ?!

I've experienced over the years that when I management station is NOT tuned
appropriately, it WILL spike the processors of your routers/switches during
the polling cycle, like every 15 minutes or so, whatever it is set to.

I'm not sure this is your problem, but it could be.

Aaron

p.s. it's probably dumb/unnecessary to have a snmp mgmt. station hit all the
OIDs on the network devices since you probably don't want/need that much
info queried anyway.



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
raf
Sent: Thursday, April 28, 2016 11:03 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] LDP flaps specifically present on ACX Juniper routers
(ACX4000 and ACX1100)

Hi,

Is your RE cpu utilisation is OK or not ?

I have similars issues on EX during snmp polling, which are eating all the
cpu time.

-- 

Raphael Mazelier


Le 28/04/2016 à 17:38, joel ahumuza a écrit :
> Hi All,
>
> We are experiencing an issue with ACX routers running on 12.3X54-D20.7 
> where the LDP sessions are continuously flapping, the logs indicate 
> the following;
>
> Apr 21 03:36:31  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session 
> x.x.x.x is down, reason: hold time expired Apr 21 03:36:34  hostname 
> rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
> (lo0.0) is down
> Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor 
> x.x.x.x
> (lo0.0) is down
> Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session 
> x.x.x.x is down, reason: all adjacencies down Apr 21 03:55:34  
> hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, 
> reason: received notification from peer Apr 21 03:55:34  hostname 
> rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: 
> received notification from peer Apr 21 03:55:35  hostname rpd[2299]: 
> RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received 
> notification from peer Apr 21 03:55:35  hostname rpd[2299]: 
> RPD_LDP_SESSIONDOWN: LDP session x.x.x.x is down, reason: received 
> notification from peer
>
> The physical connections are okay, no flaps or errors on the p2p 
> connections We are running ISIS as the IGP, whose adjacency is stable.
>
> Actions taken from our team was;
> - Increase the hold time setting on the ldp enabled interfaces.
> - Increase the time interval on the same ldp enabled interfaces.
> - setting the ldp session protection setting on the ldp enabled 
> loopback interface.
>
> Unfortunately the actions did not yield much since the flaps have been 
> ongoing.
>
> Anyone have any Idea on what the problem / solution might be?
>

___
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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[James Bensley]

On 28 April 2016 at 17:16, Hugo Slabbert  wrote:
> Use a community of simply "@SecretCommunity", *WITHOUT* the actual RI
> specified.  That will pull everything.  It's a little weird, but it works.

Yeah I had someone point that out to me offlist. I can confirm it's
now working as desired. Weird indeed, but hey, it works! :)

Thanks for the help all.

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

Re: [j-nsp] ACX5048 - protect remote access (telnet, ssh, http, snmp)

[Aaron]

How about for ACX5048 ?

I see two Junos versions...

15.1X54-D25
15.1X54-D20


Aaron

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Daniel Rohan
Sent: Wednesday, April 27, 2016 12:54 PM
To: Mark Tinka 
Cc: Saku Ytti ; juniper-nsp List 
Subject: Re: [j-nsp] ACX5048 - protect remote access (telnet, ssh, http,
snmp)

BTW, this appears to now be fixed in 12.3X54-D25.7.

ne@ACX1000-lab# load set terminal

[Type ^D at a new line to end input]

set firewall family inet filter local_acl term terminal_access from address
172.17.143.0/24

set firewall family inet filter local_acl term terminal_access from protocol
tcp

set firewall family inet filter local_acl term terminal_access from port ssh

set firewall family inet filter local_acl term terminal_access from port
telnet

set firewall family inet filter local_acl term terminal_access then accept

set firewall family inet filter local_acl term terminal_access_denied from
protocol tcp

set firewall family inet filter local_acl term terminal_access_denied from
port ssh

set firewall family inet filter local_acl term terminal_access_denied from
port telnet

set firewall family inet filter local_acl term terminal_access_denied then
log

set firewall family inet filter local_acl term terminal_access_denied then
reject

set firewall family inet filter local_acl term default-term then accept

set interfaces lo0 unit 0 family inet filter input local_acl


load complete


[edit]

ne@ACX1000-lab# commit check

configuration check succeeds


[edit]

ne@ACX1000-lab# run show version

Hostname: ACX1000-lab

Model: acx1100

JUNOS Crypto Software Suite [12.3X54-D25.7]

JUNOS Base OS Software Suite [12.3X54-D25.7]

JUNOS Kernel Software Suite [12.3X54-D25.7]

JUNOS Base OS boot [12.3X54-D25.7]

JUNOS Packet Forwarding Engine Support (ACX) [12.3X54-D25.7]

JUNOS Online Documentation [12.3X54-D25.7]

JUNOS Routing Software Suite [12.3X54-D25.7]


[edit]

ne@ACX1000-lab#

On Sat, Apr 2, 2016 at 2:59 AM, Mark Tinka  wrote:

>
>
> On 2/Apr/16 11:04, Saku Ytti wrote:
>
> >
> > I've always wondered why is this a hard problem, especially in low 
> > end? Naively I'd think that from your ASIC waste one revenue port as 
> > host-bound facing and implement normal port ACLs there.
>
> It is exactly for that reason. Vendors will assume all low-end 
> requirements place more emphasis on cost than security (however basic) 
> or generally well-practiced network operational requirements.
>
> They'll further justify it by saying, "If you want all the bells & 
> whistles, we have box for that".
>
> Mark.
> ___
> 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

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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[Hugo Slabbert]

On Thu 2016-Apr-28 13:13:35 +0100, James Bensley  wrote:


On 28 April 2016 at 12:50, Dale Shaw  wrote:

Hi James,
My memory's a bit hazy on this, but do you see everything you want to see if
you prefix the community string with a "@" in your cacti config?




Hi Dale,

As per my original email, I am prefixing the routing-instance name on
the SNMP get's;

snmpwalk -v 2c -c TEST-SNMP@SecretCommunity 10.254.242.1 .iso | grep ifDesc

Without the routing-instance name the SNMP gets timeout. I can prefix
it as default@SecretCommunity which will for example bring back all
the interfaces on the MX not in any VRf/routing-instance.

So it seems I have to specify a routing instance when using the config
from my original post, and I can specify "default@" to see interfaces
in the default table, I can also specify
A.Nother.Routing-Instance.Name@SecretCommunity and see interfaces in
that RI too, but nothing I can do seems to pull all interfaces when
making the SNMP get from within the RI when compared to making the get
from a host default.inet0.


Use a community of simply "@SecretCommunity", *WITHOUT* the actual RI 
specified.  That will pull everything.  It's a little weird, but it works.




Cheers,
James.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[raf]

Hi,

Is your RE cpu utilisation is OK or not ?

I have similars issues on EX during snmp polling, which are eating all 
the cpu time.


--

Raphael Mazelier


Le 28/04/2016 à 17:38, joel ahumuza a écrit :

Hi All,

We are experiencing an issue with ACX routers running on 12.3X54-D20.7
where the LDP sessions are continuously flapping, the logs indicate the
following;

Apr 21 03:36:31  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: hold time expired
Apr 21 03:36:34  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: all adjacencies down
Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:35  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:35  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer

The physical connections are okay, no flaps or errors on the p2p connections
We are running ISIS as the IGP, whose adjacency is stable.

Actions taken from our team was;
- Increase the hold time setting on the ldp enabled interfaces.
- Increase the time interval on the same ldp enabled interfaces.
- setting the ldp session protection setting on the ldp enabled loopback
interface.

Unfortunately the actions did not yield much since the flaps have been
ongoing.

Anyone have any Idea on what the problem / solution might be?



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

[j-nsp] LDP flaps specifically present on ACX Juniper routers (ACX4000 and ACX1100)

[joel ahumuza]

Hi All,

We are experiencing an issue with ACX routers running on 12.3X54-D20.7
where the LDP sessions are continuously flapping, the logs indicate the
following;

Apr 21 03:36:31  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: hold time expired
Apr 21 03:36:34  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_NBRDOWN: LDP neighbor x.x.x.x
(lo0.0) is down
Apr 21 03:36:38  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: all adjacencies down
Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:34  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:35  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer
Apr 21 03:55:35  hostname rpd[2299]: RPD_LDP_SESSIONDOWN: LDP session
x.x.x.x is down, reason: received notification from peer

The physical connections are okay, no flaps or errors on the p2p connections
We are running ISIS as the IGP, whose adjacency is stable.

Actions taken from our team was;
- Increase the hold time setting on the ldp enabled interfaces.
- Increase the time interval on the same ldp enabled interfaces.
- setting the ldp session protection setting on the ldp enabled loopback
interface.

Unfortunately the actions did not yield much since the flaps have been
ongoing.

Anyone have any Idea on what the problem / solution might be?

-- 
Blessings,

AJ.
SkypeID - jl.hmz
ahumuza-joel.blogspot.ug
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Problem with BGP

[Alan Gravett]

Hi Johan,

What you seem to be describing sounds like the application for route
"origin" filtering between the 2 PE  devices that are multi homed to a VPN
site?

What's not clear is the relationship between as65534 and as64560?

Can you send a diagram and configurations?
On 27 Apr 2016 7:59 PM, "Johan Borch"  wrote:

Hi

I have a problem that perhaps the experts on this list can help me shed
some light on :)

The problem involves two PE routers one Cisco IOS and one Juniper MX. MPLS
& co between them. Each PE have a VRF, same route-target. Each of these
PE-routers have a BGP session inside the VRF that connects to a customer
site via supplier and a leased line. These leased lines should be redundant
for each other.

Both BGP sessions use local as AS65534 and supplier on other side is
AS65535. Sessions are up and I'm receiving routes from supplier in each PE.

Now to my problem.

If I cut the leased line on the Cisco PE it will populate the vrf routing
table on the Cisco PE with routes from the Juniper PE learned over MPLS, no
problem.
If I cut the leased line on the Juniper PE then Juniper PE should learn the
routes from the Cisco PE, but all routes are hidden and Juniper thinks that
AS65534 is looped.

If I check a route on Juniper PE it says:

AS path: $MY_MPLS_NET_AS 65534 65535 $SUPPLIER_AS $SUPPLIER_AS I (Looped:
65534) (sorry for the obfuscation)

State: 

Hidden reason: reason not available

VRF on Juniper side is configured with:
autonomous-system 64560 independent-domain

What am I missing? Can I tell JunOS do not think it is a loop somehow?
Would it be easier to peer with different ASN from each PE?

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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[James Bensley]

On 28 April 2016 at 12:50, Dale Shaw  wrote:
> Hi James,
> My memory's a bit hazy on this, but do you see everything you want to see if
> you prefix the community string with a "@" in your cacti config?



Hi Dale,

As per my original email, I am prefixing the routing-instance name on
the SNMP get's;

snmpwalk -v 2c -c TEST-SNMP@SecretCommunity 10.254.242.1 .iso | grep ifDesc

Without the routing-instance name the SNMP gets timeout. I can prefix
it as default@SecretCommunity which will for example bring back all
the interfaces on the MX not in any VRf/routing-instance.

So it seems I have to specify a routing instance when using the config
from my original post, and I can specify "default@" to see interfaces
in the default table, I can also specify
A.Nother.Routing-Instance.Name@SecretCommunity and see interfaces in
that RI too, but nothing I can do seems to pull all interfaces when
making the SNMP get from within the RI when compared to making the get
from a host default.inet0.

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

Re: [j-nsp] JUNOS precision-timers for BGP

[Timur Maryin]

Hi Adam,


On 25-Apr-16 17:16, Adam Chappell wrote:


Currently in a situation troubleshooting consequences of high CPU usage
with a number of aggravating factors. Most sensitive to the scarcity of CPU
resources however is a number of BGP sessions with aggressive timers.


skip


I'm aware of PR1044141 which apparently causes pain when used in
conjunction with traceoptions, but I'm keen to understand if others have
operational experience.



If you seek to reduce load on RPD you should not enable excessive 
traceoptions for sure :)


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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[Dale Shaw]

Hi James,

On 28 Apr 2016 1:46 AM, "James Bensley"  wrote:
[...]
> Any info and help with getting all interfaces returned when polling
> from within a routing instance would be appreciated.

My memory's a bit hazy on this, but do you see everything you want to see
if you prefix the community string with a "@" in your cacti config?

(e.g. if the string is "public", try configuring cacti to use "@public")

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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[James Bensley]

On 27 April 2016 at 17:10, Phil Mayers  wrote:
> On 27/04/16 16:58, Per Westerlund wrote:
>>
>> That is default behavior, but you can access other RI's interfaces by
>> explicitly using the RI name. No way to reach all IFs at once via a RI.
>
>
> I'm a bit confused now.
>
> I just tested (SRX240H running 12.3X48-D15.4) and I can see all interfaces
> when hitting an IP inside a routing-instance, as well as in inet.0.
>
> We do *not* have "routing-instance-access" under the "snmp" block, but can
> still make SNMP queries to a routing instance; the docs suggest this should
> not work, so I'm not sure what's going on.

Yes I would expect it to NOT work inline with Per's comments and that
is whats happening for us. From the old Cacti box which is in inet0
(no routing instance) we can hit that community string and get all
interfaces return.

On 27 April 2016 at 17:01, Phil Mayers  wrote:
> You've configured this community string to map to a routing-instance. Try
> removing it this config item, and just putting the "clients" directly under
> the community.

The problem is that the new Cacti box is only routable to/from the
MX's inside the routing-instance, we want it to be "securely" (take
that with a pinch of salt!) seperated from other traffic and routing.
So this is going to be a problem if the MX's have to be polled from
within inet0. All Cisco boxes are polled inside a management VRF, I
would expect Junos to be able to do this, it seems tome like it would
be a fairly common requirement (to have SNMP traffic seperated into
it's own routing instance).

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

Re: [j-nsp] Problem with BGP

[Krasimir Avramski]

Hi,
What is the reason of using "local-as
"
feature? You can try to set "loops 2" option as described in the link.

Best Regards,
Krasi


On 28 April 2016 at 09:58, Johan Borch  wrote:

> Hi
>
> Both cisco and Juniper have as-override configured on their external
> session. But the problem is when I shut down the juniper peer. Routes
> receieved from cisco is still hidden and looped.
>
> Johan
>
> On Wed, Apr 27, 2016 at 11:02 PM, Mark Tinka  wrote:
>
> >
> >
> > On 27/Apr/16 19:59, Johan Borch wrote:
> >
> > > Hi
> > >
> > > I have a problem that perhaps the experts on this list can help me shed
> > > some light on :)
> > >
> > > The problem involves two PE routers one Cisco IOS and one Juniper MX.
> > MPLS
> > > & co between them. Each PE have a VRF, same route-target. Each of these
> > > PE-routers have a BGP session inside the VRF that connects to a
> customer
> > > site via supplier and a leased line. These leased lines should be
> > redundant
> > > for each other.
> > >
> > > Both BGP sessions use local as AS65534 and supplier on other side is
> > > AS65535. Sessions are up and I'm receiving routes from supplier in each
> > PE.
> > >
> > > Now to my problem.
> > >
> > > If I cut the leased line on the Cisco PE it will populate the vrf
> routing
> > > table on the Cisco PE with routes from the Juniper PE learned over
> MPLS,
> > no
> > > problem.
> > > If I cut the leased line on the Juniper PE then Juniper PE should learn
> > the
> > > routes from the Cisco PE, but all routes are hidden and Juniper thinks
> > that
> > > AS65534 is looped.
> > >
> > > If I check a route on Juniper PE it says:
> > >
> > > AS path: $MY_MPLS_NET_AS 65534 65535 $SUPPLIER_AS $SUPPLIER_AS I
> (Looped:
> > > 65534) (sorry for the obfuscation)
> > >
> > > State: 
> > >
> > > Hidden reason: reason not available
> > >
> > > VRF on Juniper side is configured with:
> > > autonomous-system 64560 independent-domain
> > >
> > > What am I missing? Can I tell JunOS do not think it is a loop somehow?
> > > Would it be easier to peer with different ASN from each PE?
> >
> > Do you have "as-override" configured on the Juniper VRF?
> >
> > Mark.
> >
> ___
> 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

Re: [j-nsp] Problem with BGP

[Johan Borch]

Hi

Both cisco and Juniper have as-override configured on their external
session. But the problem is when I shut down the juniper peer. Routes
receieved from cisco is still hidden and looped.

Johan

On Wed, Apr 27, 2016 at 11:02 PM, Mark Tinka  wrote:

>
>
> On 27/Apr/16 19:59, Johan Borch wrote:
>
> > Hi
> >
> > I have a problem that perhaps the experts on this list can help me shed
> > some light on :)
> >
> > The problem involves two PE routers one Cisco IOS and one Juniper MX.
> MPLS
> > & co between them. Each PE have a VRF, same route-target. Each of these
> > PE-routers have a BGP session inside the VRF that connects to a customer
> > site via supplier and a leased line. These leased lines should be
> redundant
> > for each other.
> >
> > Both BGP sessions use local as AS65534 and supplier on other side is
> > AS65535. Sessions are up and I'm receiving routes from supplier in each
> PE.
> >
> > Now to my problem.
> >
> > If I cut the leased line on the Cisco PE it will populate the vrf routing
> > table on the Cisco PE with routes from the Juniper PE learned over MPLS,
> no
> > problem.
> > If I cut the leased line on the Juniper PE then Juniper PE should learn
> the
> > routes from the Cisco PE, but all routes are hidden and Juniper thinks
> that
> > AS65534 is looped.
> >
> > If I check a route on Juniper PE it says:
> >
> > AS path: $MY_MPLS_NET_AS 65534 65535 $SUPPLIER_AS $SUPPLIER_AS I (Looped:
> > 65534) (sorry for the obfuscation)
> >
> > State: 
> >
> > Hidden reason: reason not available
> >
> > VRF on Juniper side is configured with:
> > autonomous-system 64560 independent-domain
> >
> > What am I missing? Can I tell JunOS do not think it is a loop somehow?
> > Would it be easier to peer with different ASN from each PE?
>
> Do you have "as-override" configured on the Juniper VRF?
>
> Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] A conceptual advice on QoS is needed

[Victor Sudakov]

Dear Colleagues,

I have read the "Day One: Deploying Basic QoS" book. There are a
couple of questions left concering EX4200 switches.

1. In a BA classifier, traffic is assigned to a forwarding-class and a
loss-priority. It is quite clear how to use forwarding-classes,
but where and how do I use the loss-priority parameter? I figure it's
probably used as a hook in the scheduler config somewhere, but where
exactly?

Moreover, it seems that when I classify traffic as 
"forwarding-class XXX loss-priority high", it simply gets discarded
on default scheduler-maps.

2. How come I cannot set loss-priority in a port-based classifier?

3.  The book says: "It is strongly advised to ensure that every
forwarding-class for which any traffic may appear on an interface to
which the scheduler-map is applied has a corresponding scheduler. If
no scheduler is identified for a forwarding-class, and traffic arrives
on that interface for that class, it will receive no explicitly
configured service (for example, no buffers, no transmit-rate) and
will therefore suffer very poor service unless the interface is
completely unused by other traffic."

Is it possible to configure a single dummy FIFO egress scheduler which
would be forwarding-classes and loss-priority agnostic? There are
interfaces where I only need to apply rewrite-rules on egress without
prioritizing. 

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp