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

[raf]

Le 02/09/2016 à 10:02, Paul S. a écrit :

Are you ok with putting your patches on something like github?



Yep I have to take the time to do it next week :)

--
Raphael Mazelier

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

Re: [j-nsp] IPV6 over MPLS

[raf]

Le 30/08/2016 à 20:46, Saku Ytti a écrit :

On 30 August 2016 at 15:27, Alexander Arseniev  wrote:



I would decouple edge services from core signalling.


The more I learn SP networks the more I think this approach is the way 
to go.



I would do 6PE
until the day I forklift into IPv6 only core and do 4PE.



I don't think that keeping ipv4 address in the core is a real problem.
With decoupling services from the signaling, we can even use whatever 
addresses in the core. But yes when all the stacks will be primarily 
developed over ipv6, then yes I will also switch. (we have some time left).


--
Raphael Mazelier

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

Re: [j-nsp] IPV6 over MPLS

[raf]

Le 30/08/2016 à 15:48, Olivier Benghozi a écrit :

If you have only RSVP-TE, you may have a look at this (inet6 shortcuts) which 
might be an alternative to 6PE for you:
https://forums.juniper.net/t5/TheRoutingChurn/Traffic-engineering-inet6-shortcuts-to-connect-IPv6-islands-Part/ba-p/192763
 





Honestly I didn't understand well what inet6 shortcuts does.
Anyway implementing 6PE was straightforward, and all is finish and work 
as expected.


--
Raphael Mazelier

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

Re: [j-nsp] IPV6 over MPLS

[raf]

Le 30/08/2016 à 14:27, Alexander Arseniev a écrit :

Hello,

If You don't care whether IPv6 packets take RSVP or LDP LSP, then You
could just enable LDPv6 everywhere (JUNOS 16.1 onwards) and save on
rewriting NHs from IPv4-mapped IPv6 to proper IPv6.



No I only have RSVP and don't want to activate LDPv6 :)


For VPNv6 You would still need NH rewriting as VPNv6 NH is still
IPv4-mapped IPv6 even if carried over BGP-over-IPv6.


No vpnv6 for now.


--
Raphael Mazelier

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

[j-nsp] IPV6 over MPLS

[raf]

Hello list,


So I have now a properly configured MPLS network with a standard 
configuration :) All my traffic goes trough LSPs except the IPv6 one 
which it a bit frustrating.


The actual configuration is a separate ivp6 bgp mesh. No need for inet6-vpn.

I've read that the simplest method is to use 6PE with ipv6 labeled 
unicast. That's look simple, but if I understand correctly I can just 
wipe all my v6 loopbacks and intercos.
Is there an alternative using my actual v6 bgp mesh, and just mapping 
the v6 traffic on existing LSPs.


Can I trick with ipv6 mapped loopback enabled by 'mpls ipv6-tunneling ? 
rewriting nh ?




PS :
This will certainly be my last request for a while.
I learn a lot with you guys.
Thanks for having been patient with me :)

Regards,

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

Re: [j-nsp] Monitoring Route Announcements

[raf]

Le 29/08/2016 à 21:32, Theo Voss a écrit :

Hi Alex,

thanks for your mail. Know those public tools, it’s about monitoring incoming 
prefixes from peers, customers and upstreams on our edge. Observium, thanks 
raf, might be a possibility, will check this out. Thought that anybody has 
implemented this inside his network and is able to share some insights or 
concepts.




Doing your home made probe will be relatively easy since all the metrics 
you want are already available via snmp.


The real challenge is to properly define the logic of the probes.
What do you want to check specifically ? trending ? anomalies ?

--
Raphael Mazelier


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

Re: [j-nsp] Monitoring Route Announcements

[raf]

Le 29/08/2016 à 16:14, Theo Voss a écrit :

Hi folks,

we’d like to monitor the volatility of the amount of route announcements on 
specific BGP sessions on Juniper MX (14.2+). Goal is displaying the amount of 
announced prefix over time and generating alerts (kind of anomaly detection). 
Has anbody built such a solution with existing (open source) tools based on 
Juniper MX? If yes, what kind of tools have you used and how did you extract 
the data from the MX (snmp?). Appreciate ideas and thougts!



I think all the metrics you want is already available from snmp.
For example with Observium you can have some nice graph like that.

Regards,

--
Raphael Mazelier

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

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

[raf]

Le 19/08/2016 à 17:38, William a écrit :

My chat with jtac ended with blaming the monitoring SW, guys at check mk
blamed juniper thou someone would look at the problem if we paid!




Jtac answer doesn't surprise me. There are no quick fixes apart 
completely rewrite/rethink the way of snmp is implemented on junos. 
(which it obviously buggy)


Answer from check_mk community is more frustrating. I ve got the same 
style of answer from the Obversium author (fix your s***y hardware).
While they are right in some way, they refused to saw how bad their 
softs was as polling snmp, specially interface MIBs.


The right way of polling slow network devices ( ):
- caching the the oid of interfaces
- caching the relatively static information (speed, duplex, etc..., 
after all the are not intended to change everytime)

- do targeted get

Implementing quick patches this way in the poller code of Observium 
have decreased the polling time by 300%. (and mainly leave my EXs alive 
when they are polled).




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

Re: [j-nsp] RVSP signaled L3VPN and RRs

[raf]

Le 18/08/2016 à 18:42, Olivier Benghozi a écrit :

As the design is currently broken, it should be fixed anyway ; and if your 
loopbacks are already in the IGP, it should just work.



I finally take the courage to fix my RRs configuration and (surprise) 
all is working fine by now.


--
Raphael Mazelier

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

Re: [j-nsp] RVSP signaled L3VPN and RRs

[raf]

Le 18/08/2016 à 18:00, Hugo Slabbert a écrit :

On Thu 2016-Aug-18 17:13:09 +0200, raf <r...@futomaki.net> wrote:





Picking the Ps are RRs seems weird.  Generally your Ps would just be in
the IGP but be BGP free.  There's nothing "wrong" with it per se, it's
just an odd choice as generally you want your Ps to be lightweight and
just label-switch without carrying heavy tables, whereas making them RRs
means a bunch of RE utilization, which is the opposite of that objective.


Completely agree. If I had to restart from scratch I will certainly 
separate Ps and use virtual RRs.


The NHS choice on the RRs is also an odd one.  Again, it's not
necessarily "wrong" but it's not a standard choice and could lead to
interesting behaviours.  That your saying you couldn't easily take off
NHS from the RRs makes me wonder what the constraints are there.





If this were my environment, I'd want to take a step back and consider
why I'm doing in-path RRs on P routers when I also appear to have
constraints on that choice (not being able to toggle NHS easily) that
could make my life more difficult.



Also agree, but unfortunately I do not have much time left on this 
network...


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

Re: [j-nsp] RVSP signaled L3VPN and RRs

[raf]

Le 18/08/2016 à 18:00, Olivier Benghozi a écrit :

One must not use NHS for all routes on an RR, but only for external routes :)

policy-statement next-hop-self {
term iBGP {
from {
protocol bgp;
route-type internal;
}
then next policy;
}
term default {
then {
next-hop self;
}
}
}




Agreed but what if I don't have the opportunity/time/spunk to change 
this behavior ?



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

Re: [j-nsp] RVSP signaled L3VPN and RRs

[raf]

Le 18/08/2016 à 17:35, Daniel Verlouw a écrit :

Hi,

you only need to do this on your RRs, not on your PEs. And make sure
your RRs don't set NHS.



Hum my RRs do NHS, and I don't think I could easily change this.
Without NHS this is effectively not needed as I already have the 
loopbacks of all my PEs in inet.3 populated via RSVP.


--
Raphael Mazelier


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

Re: [j-nsp] RVSP signaled L3VPN and RRs

[raf]

Le 18/08/2016 à 17:16, Olivier Benghozi a écrit :

Did you set protocols mpls traffic-engineering mpls-forwarding ?



Not yet. I will try.
I understand that this option is for install LSPs in inet.0 for 
forwarding only (and not for route resolution).

This is good, but why it is needed ?

--
Raphael Mazelier



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

[j-nsp] RVSP signaled L3VPN and RRs

[raf]

Hello list,

I know this topic has already discussed here but I got some trouble in 
getting these working properly.


I got a simple topology consisting of 4 PE routers, and 2 P routers 
acting as in-path RRs.


For whatever reason I want to use RSVP as LSP signaling protocol.
I configured a full mesh of LSPs between PE only.

So there is a problem in resolving route of my L3vpn as there is no 
route in inet.3 for my RRs.


I've changed resolution of bgp.inet.0 to inet.0 on RRs and PEs.
(I ve read this is not the only method, but I don't to deploy LDP or to 
make LSPs between P and PEs).


It help and I can see all routing tables populated.

However I ve got strange issues resulting in data path being broken, but 
not on all VRFs ?! and lot of logs like this "Couldn't find MPLS tunnel 
for NH id"


What I've missed ?

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

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

[raf]

Le 17/08/2016 à 17:28, Catalin Dominte a écrit :

I usually create a snmp filter to avoid polling interfaces ending in .0. If you 
poll an ex2200 / 3300 / 4200 it spends a long time polling the ifTable and 
ifxTable. The polling time is reduced considerably if .0 interfaces are dropped 
and I can poll the device every 5 minutes.



Yes snmp request can kill the control plane of EXs. For example 
Observium was killing my ex4550 (causing ldp sessions to drop and so 
on). I still consider that completely ridiculous...


With correct snmp filter the situation is less worse, but I still have 
to patch the Observium poller to let some breathes to my ex(s).
OK the Observium poller is quite aggressive (or stupid depend of the 
point of view :).




What is everyone using to monitor their EX2200/VC stacks?



I've made some ugly scripts in python to check via ssh the output of 
"show virtual-chassis".



We are using check_mk to monitor our network which is great, however due to
the way it polls or due to the low power of the ex2200 I'm unable to
monitor all the individual interfaces.


Check-mk is great, but do lot of snmpwalk to check network devices. (If 
I had time I will take a look to patch and make it use an interfaces cache)


--
Raphael Mazelier


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

Re: [j-nsp] ACX50xx l2circuit counters

[raf]

Le 20/06/2016 à 06:03, Nathan Ward a écrit :

Hi all,

I’m deploying some ACX5048 boxes, doing l2circuits from subinterfaces off to 
BNGs and so on.

We’re wanting to get counters for each l2circuit, or each subinterface, but as 
soon as a an l2circuit is attached to a subint, we lose all counters.

We can achieve what we want, more or less, by writing a ccc family firewall 
filter that matches anything and accepts+counts. It works, but it’s certainly a 
bit of a hack.

Does anyone have and tricks to make l2circuit counters work properly, or, is 
this a lost cause?

Have asked JTAC about this, and am waiting on a response for ~ 1 week now.



Well I guess this will be a lost cause :/
I have to use firewall counter as well for counting sub interface or 
vlan interface, which it less corner case in my opinion. It may be a 
chipset limitation ?


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

Re: [j-nsp] EX3400 switches, QSFP+ breakout

[raf]

Le 15/06/2016 à 15:31, Jim Troutman a écrit :

Anyone have any experience or opinions on the EX3400 switches?

Can anyone confirm that the software supports breaking out a QSFP+ ports
into 4x SFP+ (like with a QFX-QSFP-DACBO-1M) and configure as separate 10
GigE interfaces?

My SE says he thinks so, because QSFP+ specs are same as on the QFX, but
I'd like confirmation from someone who has actually done it.



I can be wrong, but if I reminder correctly someone state on this list 
that is not working. If it working it will make a cheap 16x10G ports.

(and perhaps that not what Juniper wants)

--
Raphael Mazelier

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

Re: [j-nsp] force-64bit

[raf]

Le 02/06/2016 à 00:02, Olivier Benghozi a écrit :

This is not completely contradictory with the Juniper doc ; as usual with the 
Juniper doc written with feet, you have to read between the lines:

-> Written in the doc: "Tip: You need not restart the routing protocol process (rpd) 
to use the 64-bit mode"
-> To be understood: "Joke: You need not restart rpd yourself, because it will be 
done automatically at the commit and ruin your network for about 10 minutes".




The famous commit roulette :)
It was a good addition if juniper can provide a way of seeing what will 
be impacted during a commit. (with a pub/sub model it should be trivial).


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

Re: [j-nsp] RE-S-X6-64G-BB

[raf]

Le 25/05/2016 à 23:33, Phil Rosenthal a écrit :


There is a different network card driver, so it would require a different 
kernel.


Ah ok. This RE come with a new embeded network card for the mngt, and 
Freebsd 6 does have not support for it; and juniper would not make the 
effort to backport it.
Juniper want their customer to test their new code. It can be scary for 
op, and understand the conservatism for this kind of stuff.
However I don't think 15 is such a big change. Ok the underlaying OS 
have a big jump in version and junos begun to use SMP.
But only for separate process, so from a sysadmin point of view it 
should be safe (as I m really confident with the stability of freebsd10).

Junos 16 with the separate thread in rpd will be a other story I think.


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

Re: [j-nsp] RE-S-X6-64G-BB

[raf]

Le 25/05/2016 à 18:52, Phil Rosenthal a écrit :


This new RE requires Junos 15.1R4 minimum.  If you have a reason to use 14.x or 
13.x, then this RE will not work for you.




This is really strange. I don't see technical reason why 14, 13 or even 
old one could not use a newer RE. After all it was just a newer CPU and 
more RAM.
It should work a least with one core and 4G enabled. Anyway moving to 15 
(in my preliminarily tests it seems to be a good release, no bug for 
now) have real advantages (mutli core finally), so why not give it a try ?


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

Re: [j-nsp] RE-S-X6-64G-BB

[raf]

Le 23/05/2016 à 18:57, Saku Ytti a écrit :


I think this is driven by not having options mostly, freescale isn't
there for today's control-plane scale
Yes absolutely; but as a side effect we should have a much reactive 
control plane while junos was primarily coded on x86; and porting on 
other architecture isn't the juniper best success.

Sure, it's better than logical-systems but still, it's added
complexity, which reduces availability. BOM of HW is small. I'd rather
pay premium to have more robust network.
On this point I disagree. Virtualization add a layer and a little 
overhead, but nowadays it's a mature and stable technologies.
And splitting things and decoupling them are always a good things for 
me. I talk about junos which was a relatively complex architecture; and 
splitting them between muliple vm(s) shoud be good.
Two other point come in my mind : the opportunity to have an second 
virtual standby RE, which it good for upgrade.
Or something I haven't considered at first, the reborn of real logicial 
systems (multi tenant).


Obviously this is only valid on high end device with good cpu and lot of 
RAM.


I don't understand your arguments. You're saying it's more complicated
to do IPC inside single machine than between two different machines?
No no. I just saying that splitting junos component between vm(s) could 
allow better CPU/Ram capping between them.
And it was a first step to distribute them. But as you mention it junos 
is rather monolithic.

The problem today for JunOS is, that largely everything is inside
single OS process. So it does not matter how good FreeBSD or Linux
kernel is doing this stuff, it matters how good Juniper is doing this
stuff. And Juniper isn't even planning on moving stuff away from RPD,
but rather introduce OS threads.

Yep unfortunately. I really think rpd design must be rethink-ed.


If we could move significant portions of the control-plane to another
VM, then we need to do IPC over network. If you can produce
control-plane which allows for this, then why distribute the work to
another VM, why not distribute it dedicated compute over network?
Sure; but often network components are relatively isolated of the rest 
of the DCs, so running all of them on a big hypervisor close to the 
forwarding engine make sense (at least for me).

Having said that, my concern on reliability wasn't on vendor itself
distributing work on VMs, but we, the customers, running our own VMs
in the router hardware, and I don't see any wins there, just reduced
availability of whole system.

Ah completely agree on this. Perhaps running small utilites vm (DNS, 
tools); but corner case use.


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

Re: [j-nsp] RE-S-X6-64G-BB

[raf]

Le 21/05/2016 à 22:26, Saku Ytti a écrit :

All vendors are pimping this like it's something customers have been
crying for ages. But who actually is planning to use their routers are
general purpose compute?
What advantages can it have?


I see some good point using this approach. These are mainly side effects 
however.
The first good effect is all platform will converge and use x86 
processors. (ok we all agree this is waste of power but as the soft is 
so optimized...)
So we will converge on one processor target which it a good news for the 
stability of the software, test and so on. We can hope for a real one OS 
for all platform. :)
Other thing I saw; is that we it will allow separating components of the 
NOS in multiple VMs with real QOS between VMs.

We could imagine running a vm dedicated to RR for example.


It will obviously not affect the
reliability of the system positively, while virtualisation is quite
proven and safe, there's still occasionally issues where one VM can
impact another VM.
I think the contrary. As I say it should allow running much better 
isolated process. And perhaps snmpd will not kill the enitre control 
plane...
OK this also possible inside one OS with a good software architecture 
but it is more complicated with the actual code.


--
Raphael Mazelier


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

Re: [j-nsp] MX80 base model

[raf]

Packet mode is working in srx1500 ?

This box is pretty new, and on the paper look a very versatile toolbox.

--
Raphael Mazelier

Le 12/05/2016 à 16:46, Giuliano Medalha a écrit :

It is an excelent option

We are testing it like metro router righ now

It has a lot of good mpls/vpls implementation ( packet mode ) and works fine

Good interfaces layout

But the problem is related to the business unit ... Of this box

The main function is ng firewall and not metro router

When the mpls functions have some problems of junos code the juniper business 
and development tesm unit could not help so much ... Or put it to solve in a 
low priority development queue in function to solve security problems first

But we will try ... It is an excelent box for that

Thanks a lot




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

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[raf]

Le 06/05/2016 à 19:17, Aaron a écrit :

As I recall, vpls bgp ad w/ldp sig worked interop between all these

  Cisco ASR9K
  Cisco ASR920 (2 flavors as I recall)
  Cisco ASR903
  Cisco ME3600
  Juniper MX104
  Juniper ACX5048

... all those in same vpls elan

Cool.


My l3vpn mpls vrf (routing-instance) on ACX is working fine... i learned
that it's different than cisco whereas static and direct connect routes are
automagically advertised into the vpl  so I wonder if this is what you
mean by auto-export.  If so, yes it's working. (I'm fairly new to Juniper,
and been doing cisco for several years and am accustomed to cisco mpls l3vpn
requiring redistribution of static and connected routes explicitly
configured)


If you use 'vrf-target' stanza, by default all route with these extended 
community will be imported and exported.
The auto-export 'stanza' allow to do local route leaking between two (or 
more) vrfs.
This is this special feature that do not work on EX4550 which force do 
to strange things.

... what do you mean by "worked on tagged link?"  if you mean am I tagging
the PE-CE handoff then the answer is yes... I get tagged frames on PE-CE, I
put those into a vlan, I put irb on top of vlan and I vrf (routing-instance)
the irb. Done.  Works.
I mean using a tagged link between P-PE. This is not recommended and I 
prefer back to back untag link for the core, but in some case it can be 
helpful.




I did a quick ELINE EVPL (mef-speak for vlan- based pw) which I think is
what you mean by ldp-based l2circuit... ( I did set protocols l2circuit
neighbor 1.1.1.1 interface ge-0/0/38.0 virtual-circuit-id 999 , ge-0/0/38.0
has encap vlan-ccc vlan-id 17 and family ccc) and did this to the other side
which was a cisco me3600 ( I need to test 9k soon and will ) ...me3600 was a
interface with service instance encap dot1q 17 rewrite sym pop thing and
xconnect 1.1.1.2 999 encap mpls)   works... done.

OK cool.

I want/need to test mef eline epl (port based l2circuit to carry all vlans)

I want/need to test mef etree eptree/evptree since I support some of that
too in my network, but not as much as eline and elan

Acx label stack ?  dunno did I read 3 somewhere ?  don't recall

Snmp counter on vlan or subint ?  dunno yet  but will probably soon find out
as solarwinds is watching a couple of my deployed acx's...  check back
later.



Thks for all theses feedbacks.

--
Raphael Mazelier

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

Re: [j-nsp] New to Juniper: loopback interface address for the re0 configuration group?

[raf]

In this example Raphael set two different addresses for fxp0 for each RE 
(.10, .11) and a 'virtual' one (.9) which reside only on the master RE.


I do not recommend the use of fxp0, (rather use in -band management, and 
serial oob in case of failure), unless you are totally sure of your 
management network.


--
Raphael Mazelier

Le 09/05/2016 à 14:19, Raphael Maunier a écrit :

Here the config for the 2 re
groups {
 re0 {
 system {
 host-name re0.mx1.fqdn;
 }
 interfaces {
 fxp0 {
 unit 0 {
 family inet {
 address 10.10.10.9/24 {
 master-only;
 }
 address 10.10.10.10/24;
 }
 }
 }
 }
 }
 re1 {
 system {
 host-name re1.mx2.fqdn;
 }
 interfaces {
 fxp0 {
 unit 0 {
 family inet {
 address 10.10.10.9/24 {
 master-only;
 }
 address 10.10.10.11/24;
 }
 }
 }
 }
 }

 
And then apply-group [re0 re1]






Raphael

On 09/05/16 14:11, "juniper-nsp on behalf of v" 
 wrote:


Hello,

I am new to networking and trying to understand the initial configuration on a 
Juniper MX router with dual REs:
http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/routing-engine-dual-initial-configuration.html

Step 6 is the following:
" Set the loopback interface address for the re0 configuration group:
[edit groups]
root@host# set re0 interfaces lo0 unit 0 family inet address 
address/prefix-length"

Why do I need to give the re0 group a loopback interface address in the first 
place?
What address should I give to the loopback interface?

Regards,
v
___
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] New to Juniper: loopback interface address for the re0 configuration group?

[raf]

Well the documentation can be confusing.

In re0 and re1 group you put the configuration specific to one RE. On my 
router I only set the host-name.
The loopback does not have to be different between the two RE, so you 
can let it on the standard hierarchy.


--
Raphael Mazelier


Le 09/05/2016 à 14:11, v a écrit :

Hello,

I am new to networking and trying to understand the initial 
configuration on a Juniper MX router with dual REs:
http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/routing-engine-dual-initial-configuration.html 



Step 6 is the following:
" Set the loopback interface address for the re0 configuration group:
[edit groups]
root@host# set re0 interfaces lo0 unit 0 family inet address 
address/prefix-length"


Why do I need to give the re0 group a loopback interface address in 
the first place?

What address should I give to the loopback interface?

Regards,
v
___
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] Virtual route reflector physical layout

[raf]

Le 06/05/2016 à 17:21, Mark Tinka a écrit :


Your RR's should be part of your IGP, otherwise iBGP won't work.

Yep my question is a non sense.

Having two links into your RR's is certainly recommended.
So I've always used core switches in my PoP's. The reason is simple -
core router ports are not cheap, as you rightly mention.


Wow such a debate here. I have no core switch and unfortunately not so 
much free port on my routers. (and is not going to change)
My topologies is multi pop, but with a classical design, edge routers, 
core router, and aggregation routers (RR clients).
I have some port on edge, and aggregation routers, but not on core 
router which are my preferred placement...


In our case, our CSR1000v-based RR's are running on HP servers. Those
connect into our 2 core switches in each PoP over Cat-6 into a copper
SFP in the core switch (as the core switch is an all-optical unit).

I'd also recommend connecting your iLO-equivalent ports on your RR's to
your internal management network, just to maintain some OoB access to
the hypervisor for future troubleshooting.


Yep all our servers have management and oob access. No problem on this part.
I will study the juniper 'shadow host', look interesting but a bit 
complicated.



--
Raphael Mazelier

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

Re: [j-nsp] [SPF:Passed] Re: EX4600 Vs QFX 5100 VS ACX 5048

[raf]

Le 05/05/2016 à 15:22, Aaron a écrit :

YW Raphael, I've tested and am still testing a lot of vpls with ACX5048...
what would you like to know ?  I'll try to help where I can

BTW, I'm motivated and required to figure out as much as I can on the
ACX5048... my boss just bought 14 of them !  (they have all 14 arrived in my
warehouse downstairs)  ...we've already deployed 2 in our live network.  One
is solely burning in as a P right now, forwarding nicely about ~2 gbps worth
of subscriber internet traffic just fine.  We will be moving over some gear
to it soon so it will soon become a PE for mpls l2vpn's and l3vpn's.  ...so
I gotta be comfortable with lots of this stuff before I go live (more live
than it already is  :)

Excellent.



Regarding VPLS on ACXI've tested ...

VPLS - BGP AD w/BGP Sig (I think known as rfc4761)
VPLS - BGP AD w/LDP Sig (I think known as rfc4762) - this is how my
pre-existing cisco gear defaults...so I will need to introduce juniper gear
into my cisco network as vpls bg ad w/ldp sig

And all is working as expected ?

I'm specially interesting in :

- l3vpn ldp/rvsp signaled (and is auto-export is working ?), and also is 
Mpls (ldp/rvsp signaled not the problem) work on tagged link ?

- l2circuit (ldp based), l2vpn (bgp/rvsp based)

Subsidiary question 1 : do you know if they are a maximum label stack 
depth on acx?
Subsidiary question 2 : have you test if the snmp counter on vlan, or 
sub interface work as expected ?


They are know limitations I know on Ex4550.


These tests were done with pretty much all of the following signaling
lsp/pw's to one another ...

Cisco ASR9K
Cisco ASR920 (2 flavors as I recall)
Cisco ASR903
Cisco ME3600
Juniper MX104
Juniper ACX5048


Good luck ;)



- I try to keep good notes on my findings during testing so please let me
know what you need and I'll try to dig it up, or recall it from memory



Thks.

--
Raphael Mazelier


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

[j-nsp] Virtual route reflector physical layout

[raf]

Hi guys,

I got a couple of questions about the implementation of virtual route 
reflector. For now I think I will use vrr from juniper, but other soft 
can do the job and the question is general to out of path RRs.


While there are 'virtual' components, they can be physical connected 
anywhere in the network. But as a critical part of the network they have 
to be connected at the right place. In an ideal world I would take two 
dedicated hypervisors for them, and connect them redundantly to the core 
router (back to back). But this is not a very cheap solution.


Some questions :

- are the (v)RRs really have to be part of the IGP ? with two or more 
paths to the core ?

- are the (v)RRs really have to be physically connected to routers ?

I know that Mark have deploy cisco CSR1000v, and I am interested about 
details on his setup, but interested on other scenarios also :)


Thks.

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

Re: [j-nsp] [SPF:Passed] Re: EX4600 Vs QFX 5100 VS ACX 5048

[raf]

Thanks aaron for the reply.

Vpls don't work on EX4550, the stanza does not even exist.
I'm interested in the result of  your test on acx.
Stanzas exists good starting point.
Do you test further ?

Regards,

Le 03/05/2016 à 22:00, Aaron a écrit :

Raphael , I had issues last year when trying to test VPLS on EX4550...i
don't recall that it worked

In my lab I see the following... seems like the EX4550 is less capable in
its routing-instance types when compared to the ACX5048

 ACX5048

agould@eng-lab-5048-1> show version
fpc0:
--
Hostname: eng-lab-5048-1
Model: acx5048
Junos: 15.1X54-D20.7
...

agould@eng-lab-5048-1# set routing-instances test instance-type ?

Possible completions:

   evpn EVPN routing instance

   forwarding   Forwarding instance

   l2backhaul-vpn   L2Backhaul/L2Wholesale routing instance

   l2vpnLayer 2 VPN routing instance

   mpls-internet-multicast  Internet Multicast over MPLS routing instance

   no-forwardingNonforwarding instance

   virtual-router   Virtual routing instance

   vpls VPLS routing instance

   vrf  Virtual routing forwarding instance


 EX4550

gvtc@eng-lab-ex4550-1# run show version
fpc0:
--
Hostname: eng-lab-ex4550-1
Model: ex4550-32f
JUNOS Base OS boot [12.2R1.9]
...

gvtc@eng-lab-ex4550-1# set routing-instances test instance-type ?

Possible completions:

   forwarding   Forwarding instance

   l2vpnLayer 2 VPN routing instance

   mpls-internet-multicast  Internet Multicast over MPLS routing instance

   no-forwardingNonforwarding instance

   virtual-router   Virtual routing instance

   vrf  Virtual routing forwarding instance


-Aaron





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

Re: [j-nsp] [SPF:Passed] Re: EX4600 Vs QFX 5100 VS ACX 5048

[raf]

Le 03/05/2016 à 15:48, Mark Tinka a écrit :



I look at ACX5048/QFX5100 to replace my EX4550 which act as 
customer/aggregation router (ISIS/BGP/MPLS/L3VPN/L2Circuit).
The Ex4550 do the job but have some limitations I already explain (slow 
RE, one MPLS label).
I wonder If one theses boxes do the job better than my old Ex. 
QFX5100/ACX5048 are the same hardware, but no one know the exact sofware 
difference ?
And talking to my SE, the pricing/licencing is quite confuse at the time 
(at least for the ACX series)...

So if anyone have feedback :)

--
Raphael Mazelier
___
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)

[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