Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?
For those of you interested in all the details around how the transit as well as host-inbound and host-outbound traffic is handled on juniper MX3D Trio architecture I'd recommend reading the following FREE book in its entirety. https://www.juniper.net/us/en/training/jnbooks/day-one/networking-technologi es-series/packet-walkthrough-mx-series/ It's an excellent book that will answer, among others, all your questions around where the ICMP might be delayed in the system and where and how it is handled. I'd say it's a must read for all NetEng/Arch working with Juniper MX. This is sure a very good resource (from the excellent David Roy). I've already read it in the past and forget most of it. So for icmp we are in the case of an "exception packet" that are "punted" to the RE. But the document did not detail what really happen in the RE. It mention that theses packets transit by gigabit ethernet interfaces in the TPP proprietary protocol, but nothing after. What daemon is in charge of handling TPP flow on the RE side ? rpd ? for icmp is at the end the packet go through the freebsd kernel (seems logic but). And what cause latency in response ? -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?
On 16/04/2019 15:52, Saku Ytti wrote: On Tue, 16 Apr 2019 at 16:35, Vincent Bernat wrote: Can you confirm that rpd is answering ICMP echo requests? I find this surprising as I would have expected the FreeBSD kernel to do that. You're probably right. So more likely is that LC CPU is busy doing programming RPD asked it to do, instead of giving ICMP towards RE. This is interesting discussion. It was always unclear to me what are handled by the freebsd kernel, rpd, or the micro junos kernel. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX5110 : Q-in-Q in VXLAN
On 10/09/2018 21:40, Raphael Maunier wrote: I was about to suggest this . If you only need to do A to B, I will suggest doing pseudowire instead of Evpn transport. But, you cannot end the pseudowire on a sub-if ( on MX you can ), on QFX, Interface are dedicated to one protocol Yep simple CCC should work (of memory it worked for me on a simple setup with only one P in the middle). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX5110 : Q-in-Q in VXLAN
On 10/09/2018 21:22, Raphael Maunier wrote: There is some limitation on the qfx due to the Broadcom chip. On the 10k, you don’t have all the limitations to the cheap chip ^^ On the 5100 you have a lot of limitation on the 5110, you have less, but not sure it support the double tag encapsulated frames (Broadcom) I have a bunch of evpn infrastructure deployed, but I never tried to use q-in-q, so not sure if 5k will support this. I have 10k’s in the lab I may be able to test it Got the same problem type of problem on EX5440 and QFX5100. There are (very) slow limit on label stacking due to the chip. Quoting the doc (Read https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html) : - Push of a maximum of three labels is supported in the MPLS edge switch if label swap is not done. - Push of a maximum of two labels is supported in the MPLS edge switch if label swap is done. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 v MX104
On 02/12/2017 16:26, Raphael Maunier wrote: There is no licence for the ports, I already made my first quote for a customer last week on this product Rebate are also lower not the same than the MX chassis. It’s not the same product, only 10G/100G, no interfaces cards, no services cards … This is the best MX product for years, I’m glad to see Juniper listening to their partner and finally decided to build this version ( Hi Raphael, This is indeed an interesting product and I'm thinking it could be a good candidate for replacing my old edge devices on my CDN infrastructure. A real router, a good density and the Junos toolbox on 1U. Sound good on the paper. What are the port details ? 8x10G ports and 4x100/40/10G which can be spitted ? Best, PS : can you give me some price detail in pv ? PS2 : How about your remote ? :) -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)
Is this the case for chassis MX104 and 80? Is your recommendation to run with indirect-next-hop on them as well? Correct me if I'm wrong but I think this is the default on all the MX since a long time. There as no downside afaik. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MC-LAG reliability
Hey, My experience with VirtualChassis with a lot of them (you know where) is globally positive. In fact I dot not remember when a VC completly fail. This is not a perfect techno but it do the job for very low cost of setup. On EX series you have no choice, afaik MC-LAG is not supported (unless on highend series). On QFX I would hesitate. My tests are OK. Running independent switches is more reliable indeed, but even with automation tool the cost of setup/maintenance is bit higher. (and in my actual work I have just no time to spend with network config unfortunately). -- Raphael Mazelier On 22/12/2016 15:15, Vincent Bernat wrote: Hey! How reliable should MC-LAG be considered on EX and QFX series (in a pure L2 setup)? I had a few bad experiences with virtual chassis where a hiccup usually translates to both switches becoming unavailable. This is pretty rare of course. MC-LAG would avoid those coordinated faults but is it otherwise as reliable as virtual chassis? Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper PTX1000
On 17/12/2016 05:28, Colton Conor wrote: Aaron, About 28k including hardware, license, and 12 months of support. Not bad for as many ports as it has, and full BGP. Hum interesting. Price list or ? A bit expensive I think for this type of box, for half the price we begun to talk... -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Soft removal of traffic from AE?
On 29/10/2016 18:26, Roger Wiklund wrote: Hi The question is actually regarding maintenance. I have 40+ dual homed servers, and I need to upgrade the switches. It's not feasible to steer traffic away on each server, therefore I asked about what can be done on the switch itself. In job-1 we have thousand of servers in this configuration. On Linux server we just remove the interface from the bond before upgrading the concerned switch, and re-add after. I didn't know if we loss frame or packet, but from an end user point view it was transparent. Even if, TCP will do his job, and on UDP based application there re-transmission or control mechanism. But if you cannot control the server side (this look strange by the way) you can just go on, after all lacp goal is also to provide redundancy. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design
On 27/10/2016 20:28, Karsten Thomann wrote: I'm a bit curious why until now no one mentioned MPLS Enabled Applications... Good one but much more theoretical. I like to have practical examples for my understanding of a new subject. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design
I would personally recommend "Mpls in the SDN Era" from Oreily. The first chapter are a really good practical introduction to MPLS and further chapters treat RVSP in detail. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX10002 as P Router
Le 17/04/2016 à 12:43, Saku Ytti a écrit : I'm not really clued-up on QFX5k. I know that that TCAM size may be challenge for stuff like lo0 protection. Control-plane scale may be challenging if you run BGP. But if you put Internet in VRF and run BGP free core, both of these are irrelevant. Yep that the plan, with separate RR (vrr or other). Very likely QFX5k will cover large percentage of P deployment use-cases. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX10002 as P Router
Le 16/04/2016 à 21:29, Saku Ytti a écrit : I wasn't curious on similarities, I was curious on dissimilarities :). I suspect it's exactly the same PEchip physically. And I have no complaint on that, I think multi-branding is excellent business strategy. Yep me too. At a much lower price, what do you think of using a qfx5100 as P/LSR router ? The mpls support look correct, and it have a lot of 10G ports. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Core network design for an ISP
Le 29/03/2016 15:46, Saku Ytti a écrit : That is just 10min look. It's very complicated approach yet not particularly secure one. But at least it's less broken than Cymru secure template. Few basic principles a) never use 'port', all bidir TCP needs 'active' and 'passive' rule separately b) never use prefix-list, always directional source/desination c) if you run l3 mpls vpn, always verify 'destination-address' d) have long list of permit/allow, then single discard at the end e) if standard makes statement about TTL/hop-limit, use it, it's super critical for ICMPv6 ND particularly f) only use 'tcp-established' to make rule more strict, not to have some handy catch-all return traffic permitter g) avoid high level of abstraction, people will need to be able to review it, preferably fast, bitrot is serious problem I have always found RE protection filter over-complicated and error prone. I stand with my very simple filter (8 terms) which are far for perfect (and it break one of your rule), but at least it was understable and work in my environnement. The easy part is to protect from the external, you can even use private IP on your core, or better dedicate a public subnet not announced in the DMZ. The difficult part is to protect your core from your customer. And then filter bgp, vrrp, etc... I think a collaborative repo on github from different source should be helpfull for all of us (I've grab many of the filter over the years, and can publish it if someone are interrested). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Core network design for an ISP
Le 25/03/2016 02:02, Luis Balbinot a écrit : For iBGP consider multiple loopback addresses for different families. I'd do v4 and v6 (6PE with MPLS) with one family and inet-vpn, l2vpn, etc on another one. Even with newer REs a full table is taking quite some time to come up. Multiple loopbacks are always a good idea. It make maintenance much more painless. One loopback for inet, one for inet6, one for *vpn. Also colleague of mine point that is good to separate familly who support GRES from those who not. For IGP keep a flat area, no need to segment. Agreed, flat design with least pfx possible. Eventually look at LFA (it does not cost much and it was cool to have pre-installed backup path). For IXs I'd recommend a separate routing-instance. This will help you avoid stuff like someone defaulting to you and transit deviations. OK, but this vrf would be leaked in the "dmz" vrf, so how do you avoid this kind of leaking ? For the default leak, what about a static default backup route ? -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Core network design for an ISP
Le 25/03/2016 16:37, Saku Ytti a écrit : It's minor benefit and I wouldn't separate MPCs based on this. Only reason I'd do edge/core MPC separation if I'm anyhow going to have enough MPC/ports to pull it off without extra CAPEX, then it would be no brainer. Interesting, but I have make the opposite, aka mixed edge and core link on MPC. The idea was to provide redundancy in case of one MPC failure. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Core network design for an ISP
Le 25/03/2016 16:20, Saku Ytti a écrit : On 25 March 2016 at 03:02, Luis Balbinot wrote: A good practice on MX480s would be to keep upstream and downstream ports at separate MPCs if possible. Depending on your config the standard 256M RLDRAM from some cards might be an issue in the not so near future. I'm not sure how much RLDRAM those NG cards have though. It should be safe for at least 1.5M IPv4 FIB + reasonable IPv6 FIB. It's pretty far future, unless you have large L3 MPLS VPN tables in addition. There are some other benefits running separate MPC for edge and core, but it might not make financial sense. Obviously you want core interfaces in separate MPCs, so having 3 MPC on smallest pop, and potentially just 1 interface in each core MPC, may be just too high premium for it. I would not specifically plan on separate MPC for edge+core, unless I'd knew that I'm going to have large VPN tables and 1.5M won't be enough. What the point to separate upstream and downstream port on different MPC ? (apart FIB size) -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Core network design for an ISP
There are so much debate on how to construct a good network core, but if you don't need special features, I will stay with something very simple : - IGP : ISIS (over OSPF because it doesn't relies on IP, more flexible, more simple) with only loopback - iBGP full mesh with DMZ in the main table/main vr (vrf provide more flexibility for a little increased complexity) - LDP for signaling MPLS (unless you really need FRR, and/or QOS) as always KISS is a good approach :) -- Raphael Mazelier Le 25/03/2016 00:57, Matthew Crocker a écrit : Hello, What is the current best practice for carrying full tables in MX series routers? I have 3 new MX480s coming soon and will use them to rebuild my core network (currently a mix of MX240 & MX80 routers). MPC-NG (w/ 20x1g & 10x10g MICS )& RE-S-X6-64G-BB. I’m running MPLS now and have full tables in the default route instance. Does it make more sense (i.e. more secure core) to run full tables in a separate virtual-router? I’ve been doing this small ISP thing for 20+ years, Cisco before, Juniper now, I’ve always bashed my way through. Looking for a book, NANOG presentation or guide on what is current best practice with state of the art gear. MPLS? BGP? IS-IS? LDP? etc. The network is a triangle (A -> B -> C -> A), MX480 at each POP, 10g connections between POPs, 10g connections to IX & upstreams. Most customers are fed redundantly from A & B Thanks -Matt ___ 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] Routing Engine filtering on EX with VRF
Le 22/03/2016 17:35, Scott Granados a écrit :
I believe this is correct. In order for a specific filter to have effect with
in an routing instance you have to apply that filter to the loopback else I
believe and am more than willing to be corrected but I believe the instance
takes on the characteristics of the global filter when no filter is applied to
the loopback within the instance.
Quoting the doc :
""You can create an individual loopback interface logical unit for each
and every VRF, such as lo0.x (x>1). When assigning the loopback
interface logical unit to one VRF, you can also apply the firewall
filter on the subinterface.
Additionally, the loopback0.0 logical unit (also referred as the default
loopback interface), which is associated with the default routing table,
can also have its own firewall filter. You can define multiple firewall
filters and apply them on different logical units of the loopback
interface. Which filter should take effect can be decided by the
following three rules:
If you configure Filter A on the default loopback interface and
Filter B on the VRF loopback interface, then the VRF routing instance
uses Filter B.
If you configure Filter A on the default loopback interface, but do
not configure a filter on the VRF loopback interface, then the VRF
routing instance does not use a filter.
If you configure Filter A on the default loopback interface, but do
not even configure a VRF loopback interface, the VRF routing instance
uses Filter A.
""
on my EX :
/* global loopback */
unit 0 {
family inet {
filter {
input protect-routing-engine;
}
address 1.1.1.14/32;
}
}
/* vrf internet loopback */
unit 2 {
family inet {
filter {
input protect-routing-engine;
}
address 1.2.2.114/32;
}
}
But for an interface which was on the 'internet' vrf :
interfaces ge-1/0/13
unit 0 {
family inet {
address 1.2.2.174/31;
}
}
internet {
instance-type vrf;
interface ge-1/0/13.0;
interface lo0.1;
route-distinguisher 10:14;
vrf-target target:10:10;
vrf-table-label;
}
The filter is never reached...
I will open a case on the Jtac.
--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Leaking from a vrf to inet0
Le 21/03/2016 18:12, Raphael Mazelier a écrit : Wow look nice. I will give it try. Can I specify a policy in the rib-groups ? So tested and nope. I will stuck with my strange (but working config) configuration. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Leaking from a vrf to inet0
Le 21/03/2016 17:21, chip a écrit :
Hi Raphael,
If I'm understanding what you want correctly you can use rib-groups
to do this.
routing-options {
rib-groups {
FROM-VRF-TO-GLOBAL {
import-rib [ SOURCE-VRF inet.0 ];
import-policy WHATEVER-POLICY-YOU-WANT;
}
}
}
Nope, this didn't work in this case (mp-bgp learned route to inet.0).
--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Leaking from a vrf to inet0
Le 21/03/2016 18:06, Daniel Dobrijałowski a écrit : Use auto-export and rib-groups together: http://www.juniper.net/documentation/en_US/junos15.1/topics/example/vpn-overlapping-vpns-using-automatic-route-export-configuring.html See "Configuring Overlapping VPNs and Additional Tables" section. Remember to read the last paragraph in that section, because usage of import-rib is not standard (primary table is not listed). It's very nice feature - you don't have to think about how you've received routes (interface, static, BGP, MP-BGP, IGP) and leak them all using single policy in rib-group declaration. Wow look nice. I will give it try. Can I specify a policy in the rib-groups ? -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Leaking from a vrf to inet0
set routing-instances INTERNET protocols bgp family inet unicast rib-group
INTERNET-to-MAIN-UCAST
set routing-instances INTERNET protocols bgp family inet6 unicast rib-group
INTERNET-to-MAIN-UCAST6
set routing-options rib-groups INTERNET-to-MAIN-UCAST import-rib INTERNET.inet.0
set routing-options rib-groups INTERNET-to-MAIN-UCAST import-rib inet.0
set routing-options rib-groups INTERNET-to-MAIN-UCAST6 import-rib
INTERNET.inet6.0
set routing-options rib-groups INTERNET-to-MAIN-UCAST6 import-rib inet6.0
Mhm I have just tested and it does not work this way for me.
Here a snipset of my conf :
rib-groups {
internet-to-inet0 {
import-rib [ internet.inet.0 inet.0 ];
import-policy ipv4-internet-out;
}
}
and in the vrf 'internet' :
protocols {
bgp {
group ibgp-internal {
type internal;
family inet {
unicast {
rib-group internet-to-inet0;
}
}
neighbor x.x.x.x;
}
}
}
without the neighbor knob activated, the pfx are not leaked.
--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Leaking from a vrf to inet0
Hello, I am currently evaluating how to migrate the internet dmz, and the public pfx of my customers into VRF. During the migration phase I have to leak pfx from vrf to the global table. Don't ask why, but I cannot do the leaking on the PE-CE side as it should normaly occur. So I want to do leaking on the remote PE from pfx learned via mp-bgp on the vrf to the global, and afaik it is not possible directly. I know that this topic have been discussed before, but if someone have some hints on how to do this the cleanest way possible. Options I found in old threads are : - use static routes with next-table (tested and work but completely manual) - use a lt interface between global and vrf (and use some routing protocol ?) - advertise twice the route in family inet in addition to inet-vpn, in order to leak it with rib-group (since rib-group only work when pfx is in a primary table) This last solution seems to be the less manual (I don't want to make config for each pfx) but seems tricky/ugly. I got a working setup with these but definitively looks weird. What are your opinions/hints ? -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VMX to VMX traffic on ESXi
I have got some strange problem with vmx on vmware.
First double check if all our vswitch are in promiscuous mode.
Check also if you use vxnet or e1000 type of interface, I've got erratic
problems with vxnet, and gave up with it.
Check the mac address mapping, and finaly check if you have proper
license installed ;) (I've spend one hour to find why one of my test vmx
does not anymore, before I found that the license have expired...)
--
Raphael Mazelier
Le 18/03/2016 21:49, serge vautour a écrit :
Hello,
I haven't had any replies in the Juniper VMX forum so I thought I'd try
here:
I have setup 2 VMX (each with a VCP & VPFE) on one ESXi host using Junos
VMX 15.1F4. Each VMX seems to be working fine on it's own. I can remotely
access the fxp0 interface.
I created a dedicated vswitch with promiscuous mode on for the GE
interface. I used this vswitch for the 3rd NIC on each VPFE. I did not
attach any physical NICs to the vswitch as I only want to use it for
VMX-VMX traffic. Each VMX sees all 8 GE with ge-0/0/0 being up. I configure:
user@LabVMX1> show configuration interfaces ge-0/0/0
description "Link to VMX2 ge-0/0/0";
unit 0 {
family inet {
address 10.5.5.0/31;
}
}
user@LabVMX2> show configuration interfaces ge-0/0/0
description "Link to VMX1 ge-0/0/0";
unit 0 {
family inet {
address 10.5.5.1/31;
}
}
I also added OSPF to each interface. VMX1 seems to work fine. It shows
in/out traffic. VMX2 only shows outbound traffic.
Using "monitor traffic interface ge-0/0/0" command I see:
VMX1:
14:56:57.489954 In IP 10.5.5.1 > 224.0.0.5: OSPFv2, Hello, length 56
14:57:02.079691 Out IP truncated-ip - 20 bytes missing! 10.5.5.0 > 224.0.0.5:
OSPFv2, Hello, length 60
VMX2:
14:57:48.925035 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 > 224.0.0.5:
OSPFv2, Hello, length 56
14:57:58.487367 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 > 224.0.0.5:
OSPFv2, Hello, length 56
VMX1 arp cache:
00:0c:29:a7:e9:09 10.5.5.1 ge-0/0/0.0 none
VMX2 arp cache is empty.
I never see any inbound packets on VMX2. I've tied ping same result. I
through this might be a broadcast/multicast problem so I tried configuring
static arp entries and then did a ping but this didn't help.
Any help would be appreciated.
Thanks,
Serge
___
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] Routing Engine filtering on EX with VRF
On EX, you should be able to protect the RE using a filter on lo0 in the main routing instance (not in the VRF itself). But be aware that this does not work on tha ACX-series (for some strange reason)... Yep the firewall filter work for interfaces that are on the main routing-instance. But for some reason the filter does not apply on traffic coming from interface placed in a vrf to the RE. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Routing Engine filtering on EX with VRF
Hi folks, Say I have an public IP on a interface in a VRF on a EX4550. I can have miss something, but I do not find how placing a good filter to protect the RE to be reach via this IP. I've test setting a loopback with the filter on the vrf, or directly set the filter on the family inet stanza of the interface. Nothing work (nothing is filtering, which is very bad). I wonder if someone has already hit this bug/fonctionnality ? Best, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Optimizing the FIB on MX
Le 20/02/2016 16:16, Raphael Mazelier a écrit :
Le 19/02/2016 14:08, Adam Vitkovsky a écrit :
Thanks for the clarification.
And again the Oreilly book "Mpls in the SDN ERA" have three great
chapters on the end speficic to theses problematics ("fast restoration").
--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Optimizing the FIB on MX
Le 19/02/2016 14:08, Adam Vitkovsky a écrit : No Multipath between iBGP paths would be similar to 'protect core' Multipath between eBGP and iBGP paths would be similar to 'unicast protection' Whereas in protection mode you use one active path and the other path is backup and in multipath both paths are active. Thanks for the clarification. The "advertise-external" would be needed in both cases to provide the alternate/backup path Indeed. As you pointed out the biggest pro is the flexibility this setup provides, you can have VRF for Peers and another for Transits. But I'm not aware of any performance issues, certainly the convergence is faster with BGP-PIC. I will try to move/split the DMZ in separate vrf. Seems to be a fun project, specialy the migration part. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Enable EVPN on existing mpls l3vpn network
Le 19/02/2016 17:44, Aaron a écrit : I love my bgp route reflector cluster... all my pe's neighbor with 2 bgp rr cluster members... anytime I want to add an address family to a pe, I add it to one rr cluster neighbor session, it bounces, once routes have been relearned over it, I add the af to the other rr neighbor session... No outage on pe. Love it Ah ! good approach. Will make it. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Optimizing the FIB on MX
Very interresting topic. Some questions about your setup : In 2) you set advertise-external, is it working the same by using multipath ? In 3) you set 'unicast protection'. It is the same thing as PIC 'protect core' knob ? If I understand correctly, before 15.1 PIC is only available on l3vpn, so my question is : Is it advisable to run the dmz/internet table in a vrf/routing instance on juniper ? and what are the pros/cons of doing that ? pros : PIC, more flexibily ? cons : more complex setup, performance issue (I've heard some storie about that) ? Best, -- Raphael Mazelier Le 18/02/2016 11:50, Adam Vitkovsky a écrit : The setup is really easy 1) carve up the FIB so that it allows for multiple next-hops (in our case pointer to a backup path) set routing-options forwarding-table export lb set policy-options policy-statement lb then load-balance per-packet 2)advertise the best external routes set protocols bgp group MX140-IBGP advertise-external << ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About the family ccc config stanza
Le 10/02/2016 19:13, sth...@nethelp.no a écrit : If you're using this for a port-based pseudowire (l2circuit) you only need "unit 0", not the "family ccc" part. Yep in theory. But on some platform the familly ccc stanza is mandatory, if not the encapsulation on the sub interface .0 remain ENET2, not Ethernet-CCC. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About the family ccc config stanza
The better to do is testing.
For example I have a case when I'm forced to used something like this :
ge-0/0/X {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
With encapsulation ethernet-ccc i'm wondering what other family was
expected ? but without the "familly " stanza it just not working :)
--
Raphael Mazelier
Le 10/02/2016 18:12, Pyxis LX a écrit :
Hi, All.
I'm not quite sure when to use the "family ccc" config stanza.
I know that this stanza should be used when applying a filter or a
policer, but what if I don't need one?
The official document is not quite clear about this, either:
http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway-pages/config-guide-mpls-applications/config-guide-mpls-applications-ccc-tcc.pdf
P.12: The vlan-ccc configuration does not have family ccc stanza, but
the extended-vlan-ccc configuration has.
Can this be safely omitted?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Slow performance of the KRT queue
Le 05/02/2016 19:32, Saku Ytti a écrit : I think the fundamental problem here is that these fixes are attempting to make the symptoms less pronounced, rather than address the problem. Yep. But it is better than nothing. I view the problem as desync of software and hardware state, we can advertise BGP route and attract traffic, even though we have not actually programmed that state to hardware. There should be inherent guarantee that what we claim is true in HW. I can accept that it takes time, that's separate problem. Sure. Convergence could be slow, no problem if it do not create blackhole. (then a backup default route is ok) I'm sure JNPR has the talent needed to fix this, but it might be more scary fix with wider impact on the infrastructure than management is ready to sign off. Agreed. But I was confident in the fact than Juniper will make significant re engenering of the junos core. Or equip all its routers with fast x86 cpu :p -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Slow performance of the KRT queue
Hey vincent,
Good to see you on the list :)
I think you've already read all threads of the long history of krt
queuing issue, on juniper (specialy this one
http://www.gossamer-threads.com/lists/nsp/juniper/40739).
I have to say, that even if the design problem remain, two minutes isn't
that bad. In the first day of MX80 with flowing enabling it took age
from the rib syncing down to the fib (friends report 20min in the worst
case). Juniper have made enhancement (or fix) in the last junos.
If you can, bench junos 14, or 15.
Is there some way to not advertise the default route in OSPF during the
convergence time? Like a criteria: don't advertise this route when the
KRT queue has 1000+ elements and until it reaches 0 (to avoid flapping).
I've heard that some event script have been made to test this, and to
dynamicly change the congirution of whatever, in your case the
annoucement of the default.
I hope that juniper still continue to work on this; even if this is due
to a design flaw wich may be very hard to fix; I think there are again
some quick fix to mitigate this problem.
For example, I think of a conservative mode, wich basicly should trigger
massive change of route and do :
- quick clear on the entire fib,
- quick install of some specific route (which was flaged).
- normal update
Or other, but provide some options to the operators.
Regards,
--
Raphael Mazelier
Le 05/02/2016 17:15, Brad Fleming a écrit :
Welcome to running a full table on the MX104. This is exactly what we found
when lab testing the devices. After months of working with JTAC we never found
a workaround. After several software updates and major configuration changes
there was never a way to resolve the issues. During a major convergence event
impacting a significant amount of the routes in a full table it took many
minutes to get RIB and FIB sync’d. In the meantime traffic was getting
blackholed. In the end we had to give up and roll bigger MX gear with much
bigger REs (and much more expensive).
On Feb 3, 2016, at 3:21 PM, Vincent Bernat wrote:
Hey!
I have a pair of MX104. Each one is receiving a full view and a default
through an external BGP session. They share an iBGP session. They
redistribute the default in OSPF (with a higher metric when the default
comes through the iBGP session). Nothing fancy.
If I shut the upstream port of one of the MX, the session goes down and
the RIB is quickly updated. Unfortunately, the KRT is quite slow to be
updated. A "show krt queue" shows there are many
deletion/addition/changes queued and they take about 2 minutes to be
processed.
Unfortunately, during this time, I have a lot of more specific routes
still pointing to a non-existant hop:
vbe@net-edge004.dk2# run show route 138.231.136.1 extensive table public.inet.0
| no-more
public.inet.0: 571546 destinations, 996364 routes (425305 active, 321183
holddown, 571058 hidden)
138.231.0.0/16 (2 entries, 1 announced)
TSI:
KRT queued (pending) change
138.231.0.0/16 -> {1.1.1.1}=>{indirect(1048578)}
Page 0 idx 1, (group v4-IBGP type Internal) Type 3 val 22b9ccb8 (grp rto)
Advertised metrics:
No metrics
(Queued)
Enqueued metrics 1: (for peers 0001 3.3.3.3)
Flags: Nexthop Change
Nexthop: Self
MED: 10
Localpref: 100
AS path: [61098] 25091 2200 2426 I
Communities: 25091:22413 25091:24115
[...]
Path 138.231.0.0 from 159.100.255.231 Vector len 4. Val: 1
*BGPPreference: 140/-101
Next hop type: Indirect
Address: 0x177743a0
Next-hop reference count: 877603
Source: 3.3.3.3
Next hop type: Router, Next hop index: 1048577
Next hop: 2.2.2.2 via xe-2/0/3.100
Session Id: 0x18
Next hop: 2.2.2.0 via xe-2/0/2.100, selected
Session Id: 0x17
Protocol next hop: 3.3.3.3
Indirect next hop: 0x19ec4b2c 1048578 INH Session ID: 0x1b
State:
Age: 16:57 Metric: 10 Metric2: 0
Validation State: unverified
Task: BGP_61098_61098.3.3.3.3+50640
Announcement bits (3): 2-KRT 3-BGP_RT_Background 4-Resolve tree
2
AS path: 8218 2200 2426 I
Communities: 8218:102 8218:2 8218:20110
Accepted
Localpref: 100
Router ID: 3.3.3.3
Indirect next hops: 1
Protocol next hop: 3.3.3.3
Indirect next hop: 0x19ec4b2c 1048578 INH Session ID:
0x1b
Indirect path forwarding next hops: 2
Next hop type: Router
Next hop: 2.2.2.2 via xe-2/0/3.100
Session Id: 0x18
Next hop: 2.2.2.0 via xe-2/0/2.100
Re: [j-nsp] understanding interface encapsulation, family ... and more
Le 05/02/2016 09:44, Emmanuel Halbwachs a écrit : Hello, Aaron (Thu 2016-02-04 21:04:40 -0600) : I'm a cisco guy coming into the juniper world. I'm trying to understand all these different interface family and encapsulation options.. [...] Is there a good book/class for this SP Layer 2 understanding of Junos ? I guess chapter 2 of http://shop.oreilly.com/product/0636920023760.do will help you. It did for me. The "Juniper MX Series" book from Oreilly is a must read for anyone who had to work on MX , and Juniper router. The new book "MPLS in the SDN era" is also interresting, regarding specificly vpn and other overlay scnenario. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper EX2200 virtual-chassis
On Ex2200 a standalone switch is already part of a virtual chassis. You have to configure two VC ports, and to preprovision the other member as backup (or linecard), it will boot and join the actual vc, without interruption. Be sure to have a backup of the configuration in case of disaster :) -- Raphael Mazelier Le 03/02/2016 14:34, Matthew Crocker a écrit : Hello, I have an EX-2200 in production and would like to add another to create a virtual-chassis. The current production unit will be the master and the new unit will be the backup.Does creating a virtual-chassis cause a RE reset? Will my production traffic take a hit? Thanks -Matt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RTBH
Le 16/01/16 05:42, Hugo Slabbert a écrit : Sure, but I didn't say that it's a problem to distribute/reflect the RTBH route via iBGP; I was specifically talking about injecting the RTBH route into your IGP (OSPF, IS-IS, etc.), which could lead to the types of issues reported by Johan originally. Ah ok I was mis understanding and agree with you. My IGP contains only my loopback, but I could understand how a laxist policy can inject /32 in it. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RTBH
Le 15/01/16 17:40, Hugo Slabbert a écrit : Sounds like the router that receives the initial RTBH /32 is re-advertising that to your other peers, i.e.: - RTBH box announces /32 with a.b.c.d/32 next-hop discard via BGP - RTBH BGP peer #1 receives and installs the route - that discard route on RTBH BGP peer #2 is picked up in its IGP export policy, so it exports it into your IGP - other RTBH BGP peers receive both the original BGP route from the RTBH box as well as the route RTBH BGP peer #1 injected into your IGP - IGP preference beats BGP, therefore remaining RTBH BGP peers prefer the IGP route that peer #1 injected Check your IGP export policy; you shouldn't be exporting the RTBH route into your IGP. I can missing the point, but this seems ok to redistribute rtbh route in your IBGP, because you don't want to make session to your rtbh feeder on all your routers ? And as generaly we configure IBGP session with next hop self, rtbh route are directed to the origin router. That's why the Niall setup is required, make an execption (do not nhs rtbh route) and set a next hop that is localy resolved, to discard. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX cluster across L2 vlan issue
While it was not really advisable to run fabric link over a stack of switches, (and not to have cluster stretched over datacenter) I have setup many srx cluster in a similar way. Two points to check : - obviously a separate single vlan by fabric link (untag on the srx side, even if it may work tagged). - jumbo frame (at least 9000), because fabric link use special frame (and long one). If the mtu remains at 1500, strange thing may happen. - no stp/whatever on the ports Regards, -- Raphael Mazelier. Le 13/01/16 17:04, james list a écrit : Hi experts, a customer of mine has implemented an SRX cluster HE(1400) over a L2 (vlan) infrastructure and is having sometime problems on the dual FAB links, which trigger basically a split brain. The cluster is geographically stretched and in one site the customer has Cisco Nexus 5k and on the other has Extreme switches. I’m not having a lot of info by the customer, I can only see that they have configured PVSTP on Cisco side and no STP protocol on Extreme side. Has anyone experienced problems in these kind of scenario ? I’m aware of the Juniper prerequisites stated here: http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/NT21/LAHAAppNotev4.pdf I’m looking for real experience and comments, what to check, any help, etc. Cheers, James ___ 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] QFX5200 and other software than JunOS
My bad. QFX5200 should support Onie, so should be supported by third party os. That was really great that juniper open his switchs. Le 07/12/15 19:28, Luca Salvatore a écrit : Juniper announced a while back (at their NXTWORK conference ) that the QFX5200 would be open. Best to reach out to your account rep to see exactly what the details are. The QFX5200 isn't shipping just yet, i believe it the 32 port one will be Q1 2016 and the 64 port will be Q2 We use lots of the QFX5100-24Q and they have been solid. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX5200 and other software than JunOS
Nope you couldn't install Cumulus or other "Open" network os on QFX5200. Switch need to support ONIE (Open Network Install Environment) to allow the installation of such network oses. Afaik Juniper OCX1100-48SX is the only switch that support onie. It was pretty much the same hardware as the QFX5100. -- Raphael Mazelier Le 05/12/15 12:02, Robert Hass a écrit : Hi I'm thinking about new QFX5200 and idea of software-less box (whitebox). Please correct me if I'm wrong - can I buy QFX5200 without software and install Cumulus Linux on it as 3rd party software ? (I'm doing this right now on Dell switches for one project) Rob ___ 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] Multi Core on JUNOS?
In fairness, concurrency is "teh hardz" on any platform, in any framework. You can use threads and shared memory then problems two you have. You can bodge it by serialising everything and pushing data between threads/processes with queues and using craploads of locking, but you typically want fast CPUs for that. Or you can cheat and coop multitask, but then you're back at IOS classic / JunOS rpd. You can write it in a concurrent-friendly language like Erlang (or maybe Go) but then you have problem employing developers on the cheap, and have to discard your existing codebase (yikes!) I'm sympathetic to Juniper/Cisco/etc. here - they've got huge codebases they can't afford to discard because of the years of accumulated real-world behavioural tweaks, but proper concurrency typically involves ground-up design principles. It's not a solved problem yet :o( The approach to run rpd on one core, and other process on avaibles one is a quick win. And optimizing the actual code before thinking in paralelism may be a faster approach to make speed gain ? I complelty agree that to make a good paralelized junos, major rewrite or complete rewrite must be engaged. Btw Junos on intel RE is fast enough for me. But not all on other cpu, specially on EX/QFX one... Perhaps Juniper should install x86 cpu on switch too (other vendor do this). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
Le 21/10/15 23:44, Chad Myers a écrit : On Oct 21, 2015, at 3:58 PM, Tarko Tikan wrote: hey, set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K Thats what I had in mind as well. I'm for that method as well. +1. When I begin to use Junos I was really surprised/frustated that I couldn't use tag/communities on connected, which break the classic logic of redistributing route in junos. That said this is even worse on other network os. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static route with tracking
Le 12/10/15 18:42, Eduardo Schoedler a écrit : You can try generate: http://www.juniper.net/documentation/en_US/junos14.2/topics/topic-map/policy-generated-route.html Yep generate with one contributing route pointing the gw ip. If you manage both side you can add bfd on the static route for faster detection. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
Le 08/10/15 18:46, Saku Ytti a écrit : On 8 October 2015 at 18:45, Giuliano (WZTECH) wrote: It's the step#1, they can get the underlaying OS to support SMP. But rpd is still 100% flat, run-to-completion. You can almost think of FreeBSD as hypervisor and rpd as virtual pc on top of it, it has own scheduler, memory management etc. IOS-XE is almost same architecture, Linux with flat ios as process. Otoh iosd is already slightly distributed and runs like 5 threads (but no meaningful routing work is distributed). Easy step#2 would be to give rpd affinity to push it on its own dedicated core. I think we are close to this step. Hard step#3 is to make rpd use multiple cores. JNPR seems to choose to DIY inside rpd and just launch threads. I personally would like to see rpd distributed to multiple OS processes, and capitalise more on FreeBSD's memory management and scheduling. But I'm not sure how to handle the IPC efficiently without large cost in data duplications across processes. In my opinion rpd should also be split in several process. I know there was a lot of interprocess communication/synchonisation, but this can be rethink. For example arista propose a central/fast db called sysdb to handle communication/sync to other process (see : https://www.arista.com/assets/data/pdf/EOSWhitepaper.pdf for detail). I don't know if was a good/viable approach, but on the paper it seems promising. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmx on aws
I heard that aws support is on the roadmap for vsrx. I don't think it make sense for vmx tought. For now older vsrx/firefly might work with some customisation. Le 06/10/15 18:09, Nikos Leontsinis a écrit : Anyone knows if the vmc can be imported as a vm on aws? -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
Le 03/10/15 02:41, Olivier Benghozi a écrit : I have heard that: 1) forget it about PowerPC CPUs (MX 80/104). 2) JunOS 15.1 uses a more recent FreeBSD 10 base (as said in the doc) with SMP activated; but I guess that as long as rpd won't be recoded accordingly, it won't be any faster. Same return here. For point 2, on 15 release the smp will at least permit that other process than rpd can run on another core (flowd). It may speed up a little operations, or not (if rpd have to wait constantly for others process state). The real challenge is to make rpd modular, and smp aware. First results are expected in Junos 16 afaik. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper vMX limitations
Le 29/07/15 22:13, Josh Baird a écrit : I was first told that vMX would ship with it's own Hypervisor. Then I heard it would ship as ESXi images. Ok, that's fine. But, alas, I have to install Ubuntu and run it as KVM guests? This is not what I was expecting. I wonder if VMware is on ge roadmap? Does anyone know? Yes for now the only supported deployment is on top of kvm. But when I asked Juniper, they told me that the vmware support is a priority on the roadmap. btw it was possible to run vmx on vmware but it was a bit tricky. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper vMX limitations
Le 29/07/15 19:15, Josh Baird a écrit : I hope the 128k RIB/FIB limitation is not correct. But who knows.. vMX is essentially vaporware to me at this point. Nope this isn't vaporware. I've got plenty of old version and the general beta was released. On unofficial version there is no limitation (except by the ram) of RIB/FIB on version I've tested. On official version if I remember correctly there is a unlimited option. (VMX-PRM-XXX I think). I could be wrong. And I still wait for the vmware support. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 Build
Le 25/07/15 16:54, Colton Conor a écrit : So how redundant an reliable would a MX480 be with two RE-2000's, 2 SCB's, and 4 AC power supplies? I know in the ideal world there would be two of these, but due to budget that is not an option. What have you seen fail on MX480's? I think this is good and stable router. In my opinion it would be preferable to have two mx480 (with one RE, one SBC each). In your scenario you'll have a very strong router, but it would not prevent for human error (or software). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 Build
Le 22/07/15 15:51, Colton Conor a écrit : We would be getting redundant (2) RE-2000's with redundant (2) standard SCB's. The configuration would be full BGP tables with 4 providers on 10G ports. The MS-DCP is a requirement for JFLOW on these older cards right? We would also use the MS-DCP for IPSec tunnels to Cisco ASAs. Any issues with Juniper MS-DPC talking to Cisco ASA? Might also do some NATting with the MS-DCP. I think your setup will be perfectly fine. regarding the flow, you have two options, inline jflow (with the help of ms-dpc) or software flow (this is what I am doing for now with no issues). I had not played with ms-dpc so I don't know if they are good at making ipsec (but as ipsec is a common standard and asas the most common device to make ipsec tunnel, I think this is safe ?). Don't know for the nat. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports
Le 14/07/15 15:45, Phil Mayers a écrit : L3VPN was our use-case; it may or may not do L2VPN, we don't have much use for it locally. If l3vpn is your case you can consider ex4550 (with caution). I use them as PE with some kind of succes. But.. there is some limitations you should be aware of : - the cpu is slow, even the snmp process can kill the control plane if there is too much polling - mpls : l2circuit is working, but not l2vpn, nor vpls. l3vpn is working but the number of routing instance is limited (arround 40 if I remember correctly. And the big one : no local leaking between routing instance. Very annoying. - snmp counter on sub interface (but there are workarround) Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 Limitations
Hello, I have no the full knowledge to disccussall of the points above, but the real point is where you come from ? mx80 ? and why you need an upgrade to (say) mx104 ? And for what I know: 1. MX104 like MX80 have no SBC, true. They are integrated router. So no redundancy on this point. 2. Yes. 8. If true it could be a real problem.BFD could be a huge resource consumer. 10. MX104 is an hardenned router. So the chassis can operate with a larger range than the MX80. But this is not the sole use case of mx104. So if you want to use it in a hard environnement you have to buy the good card. Seems logic to me. 11. What the point if the chassis is correcltly cooled ? The other points are really for special use case. If you need this kinds of feature you have to carefully test any router you want to use. Regards, Le 24/06/15 15:08, Colton Conor a écrit : We are considering upgrading to a Juniper MX104, but another vendor (not Juniper) pointed out the following limitations about the MX104 in their comparison. I am wondering how much of it is actually true about the MX104? And if true, is it really that big of a deal?: 1. No fabric redundancy due to fabric-less design. There is no switch fabric on the MX104, but there is on the rest of the MX series. Not sure if this is a bad or good thing? 2. The Chassis fixed ports are not on an FRU. If a fixed port fails, or if data path fails, entire chassis requires replacement. 3. There is no mention of software support for MACSec on the MX104, it appears to be a hardware capability only at this point in time with software support potentially coming at a later time. 4. No IX chipsets for the 10G uplinks (i.e. no packet pre-classification, the IX chip is responsible for this function as well as GE to 10GE i/f adaptation) 5. QX Complex supports HQoS on MICs only, not on the integrated 4 10GE ports on the PMC. I.e. no HQoS support on the 10GE uplinks 6. Total amount of traffic that can be handled via HQoS is restricted to 24Gbps. Not all traffic flows can be shaped/policed via HQoS due to a throughput restriction between the MQ and the QX. Note that the MQ can still however perform basic port based policing/shaping on any flows. HQoS support on the 4 installed MICs can only be enabled via a separate license. Total of 128k queues on the chassis 7. 1588 TC is not supported across the chassis as the current set of MICs do not support edge time stamping. Edge timestamping is only supported on the integrated 10G ports. MX104 does not presently list 1588 TC as being supported. 8. BFD can be supported natively in the TRIO chipset. On the MX104, it is not supported in hardware today. BFD is run from the single core P2020 MPC. 9. TRIO based cards do not presently support PBB; thus it is presently not supported on the MX104. PBB is only supported on older EZChip based MX hardware. Juniper still needs a business case to push this forward 10. MX104 operating temperature: -40 to 65C, but MX5, MX10, MX40, MX80 and MX80-48T are all 0-40C all are TRIO based. Seems odd that the MX104 would support a different temperature range. There are only 3 temperature hardened MICs for this chassis on the datasheet: (1) 16 x T1/E1 with CE, (2) 4 x chOC3/STM1 & 1 x chOC12/STM4 with CE, (3) 20 x 10/100/1000 Base-T. 11. Air-flow side-to-side; there is no option for front-to-back cooling with this chassis. 12. Routing Engine and MPC lack a built-in Ethernet sync port. If the chassis is deployed without any GE ports, getting SyncE or 1588 out of the chassis via an Ethernet port will be a problem. SR-a4/-a8 have a built-in sync connector on the CPM to serve this purpose explicitly. ___ 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] VME interfaces and lo0 filters
Le 15/06/15 16:12, Paul S. a écrit : Before I attempt to apply the filter on vme itself, is this supported (and the recommended way to do things)? Yep, see http://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/firewall-filter-ex-series-cli.html. Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX5100 IRB Interface counters
Le 13/06/2015 00:49, Stipo a écrit : Hi Raphael/List, I found that when updating JunOS to 14.1X53-D25.2 from 13.2, it appears interface counters are working "properly". A lot of frustration can now be avoided. I cannot find trace of these in release note. I have to find a unused 4550 to test this release. If it work, this will be a very good news. Even if the firewall filter is functionnal returning to a "normal" behaviour would be good. (mostly for my management/billing system). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper 10G Switch Options
Le 04/06/15 15:19, Colton Conor a écrit : We need a Juniper switch with at least 24 built in SFP+ ports. Looks like Juniper has a ton of options including the EX4500, EX4550, EX4600, and the QFX line which I don't know much about. This switch will be for aggregation purposes for an access network that has GPON OLT's with 10G uplinks on them. What do you recommend? Which has the latest hardware? Which is the most cost effective? Any limitations to be aware of? EX4600/QFX5100 are relatively new switchs, and use newer asics. I can say there were not completly bug free... But the situation is moving fastly and newer release fix a log of bugs. But they have 40G ports and higher density than EX4550. EX4550 in the other hand are not perfect, but stable and less expensive. For aggregation swithes with only 10G ports I will go with EX4550. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper EX4550 load balancing of MPLS traffic
Le 03/06/15 16:38, Mark Tinka a écrit : Yes, this is for Layer 2 traffic over native or LAG links. ECMP traffic would assume you're running IP/MPLS on the EX4550. Never ran IP/MPLS on the EX switches, so can't tell you. As I already mentionned here EX can do MPLS but have a lot of limitation. So if you plan to use EX as P router I advice to carefuly test/stage it. afaik ecmp is not supported on EX. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX5100 IRB Interface counters
Le 01/06/15 22:15, Stipo a écrit : Hi, I'm having an issue monitoring traffic statistics on IRB interfaces. The counters appear to only be counting control plane traffic. I need to monitor L3 traffic being forwarded on the interface. I've seen some references to this behavior in EX series switches, however not the QFX. I faced the same issue/fonctionnality some week ago :) EX/QFX share the same code, and some hardware, so no surprise here. So it's a known issue that all counters in irb/vlan/l3 sub interface only count traffic to/from the RE. Is there a way to accomplish this? I would be grateful for any assistance. The best workarround is to use firewall filter counters. I've used this on advice of the list, and it work very well. The only drawback is that you have to find the correct snmp oid for each counter, but it can easily be scripted. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP Route Reflectors
Le 01/06/15 10:26, Mohammad Khalil a écrit : Hi all I was reading some terms regarding BGP route reflectors and read the terms in-band and out-of-band route reflectors , I searched to see the difference but honestly nothing clear about it , can anyone please explain ? I suppose that is refering to the two main mode of design for RRs : - data traffic pass trough the RR, in band RR - data paths are not trought the RR, out of band RR -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] sip calls through srx fail after approx 15 min
Le 29/05/2015 15:42, Philip Wiberg a écrit : Another tip now that alg is discussed, you can disable alg in your custom apps aswell, that way there is no global effect. In The app conf: Application-protocol ignore; Ah yes, you have to put this in your sip-custom application. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] sip calls through srx fail after approx 15 min
Le 28/05/2015 21:19, Majdi S. Abbas a écrit : So are you saying that the sip alg can not be disabled? Or that I won't be able to get sip to work through the SRX without using the alg? Thanks for bringing up NAT, I did forget to mention our NAT setup. The provider requires that NAT and not PAT is used. I've accomplished that by source NAT for the pbx (perhaps I should switch to static NAT?). Welcome to the wonderful land of Voip . If I understand correctly you have your voip phone from a centrex like provider nated behind a srx. This is not a ideal setup, as already said. Voip protocol are not very nat friendly because sip(or other) embeded a lot of URIs. That say, SIP/RTP can work with nat in the middle, that just cause many complications... The question to leave enabled SIP ALG or not ? : well from a SP point of view I agreed with your provider, ALG must be disabled. Why ? because we don't really know what they are doing and may cause unexpected behaviour. In a other hand from a user point of view alg mitght help. (or not). I recommanded to disable it With the small trace you provide, I suspect the alg is not disabled. Have you reboot your srx (or your complete cluster if relevant) ? From my experience reboot is needed to completly disable it on srx (might be fixed on newer release?) So you could work with your nat setup. In my opinion that the role of the phones to open/leave pinhole open. So outgoing source nat must be sufficient. The real point is to correctly configure your sip phones (stun/ice/keep alive/nat traversal there are so many options). After that if you always have a timer issue , you have to tcpdump to find what cause the call to drop, and ask also your provider which must have some log Cause may : - fw sessions ending (idleing) rtp/sip ? - remote ending (keep alive not receveid ??) - local ending (the reverse) - etc... Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3300 : Pbm with inerfaces SFP
Le 26/05/15 18:25, deloin.rob...@laposte.net a écrit : Hello, I configured an EX3300-48T. The 4 interfaces SFP have the same configuration When I connect the optical fiber in the optical transceiver, I have the green led on the each interfaces. But if I can ping IP @ of the switch (or the gateway) on interfaces ge-0/1/0 and ge-0/1/1 , I can't ping the IP @ of the switch on interfaces ge-0/1/2 and ge-0/1/3. I don't understand why the interfaces ge-0/1/2 and ge-0/1/3 are not in order. I have the following error message: "No route to host" Can you help me to understand that ? By default xe-0/1/2 and xe-0/1/3 are reserved for VCP. So when you do "show interface terse" , you don't show them, but you show vcp interface instead. You can use these interface with the following command : request virtual-chassis vc-port delete pic-slot 1 port 2 request virtual-chassis vc-port delete pic-slot 1 port 3 Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 tunnel over IP on ex4200-24t
Le 12/05/15 12:55, Mark Tees a écrit : That's right. EX4500 series is different and supports a bunch more MPLS features :) More perhaps, but in my test ccc is not working :) Which I just noticed that since 12.2 apparently MPLS over RVI's and layer 3 sub-interfaces is apparently supported. Running 12.3R7 MPLS over RVIs is not working at all. On subif basics features work, and some other don't (l2circuirt for example fail silently). MPLS support on EX is very difficult to work with, features differ between model, the documentation is not up to date, etc... -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 tunnel over IP on ex4200-24t
Le 12/05/15 10:27, Mark Tees a écrit : l2circuit is not supported as that requires a two label stack to work. EX4200's can only switch a 1 label stack. Any traffic passed in P/LSR fashion that has more than 1 label in the stack gets dropped transparently from what I have seen, regardless of what the control plane/RE said. ccc/remote-interface-switch like in the link I sent earlier is the only way that works as far as I have seen. This is probably because of the 1:1 mapping of LSP to ccc direction. Strange, because what I tested on Ex4550 is the opposite : l2circuit are working, ccc not. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2 tunnel over IP on ex4200-24t
Le 12/05/15 05:59, Mark Tees a écrit : Hi Victor, The only way I am aware of that works with ex4200s is tunnelling over MPLS. This would require MPLS on the backbone to work. http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/mpls-ex-series-provider-edge-switches-ccc-cli.html Hum on my test even l2circiut (ccc) is not working on EX4200. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
Le 11/05/15 11:49, Mark Tinka a écrit : Juniper have never really had a proper router that comes in a switch form-factor. We are evaluating the ACX5000 platform for this, and it looks very promising; but its use of off-the-shelf silicon is getting in the way. The EX (certainly the 1U switches) are terrible routers; I can't speak to the capability of the big EX chassis', never tested them. Speaking about EX4550 I think they are OK for basic routing. In my use case (l3vpn, and customers demarcation) results are mixed. They worked, they are stable but : Remaining problems are : - l2vpn mess (I ve found a working config, but what a pain) - no-auto export, local leaking not working - and no statistics for subif That say, despite theirs limitations, I think they have a really good value for money. I just not correctly identify them when I bought them... (if only I had a better budget and more time :) -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
Le 11/05/15 11:31, Mark Tinka a écrit : On 11/May/15 11:11, Raphael Mazelier wrote: We have seen this on our EX4550 switches. The uplink toward the upstream routers is an 802.1Q LAG, where the aeX interface graphs actual traffic, but the aeX.Y interface just graphs control traffic. Yes this is the case with subif, vlan (irb like) if, etc... It never occurred to me that this was an issue since we do not use the EX switches for routing. But I can see how this could be a problem for you if you are offering services directly off the EX switch. That was the plan yes. If I had correclty evaluate/made more test, I have done this differently, and just use EX for what they are made (switching). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Counter on subinterface on EX
Le 11/05/15 11:27, Tore Anderson a écrit : It's quite annoying indeed. I wonder if someone ever faced this problem, and if there is some king of workarround. The goal is to monitoring traffic, and billing. The way I do it is to create input and output firewall filters for each configured family on the interface with a single term, which just does "count" and "accept". Then I poll those firewall counters. Tore Yes I've read that it could be a solution. Have you notive/hit some performance problems with this config ? Thks. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Counter on subinterface on EX
I've just realized there is another pretting annoying problem with EX series. It seems that is was not possible to count passing in subinterface (or vlan interface) on EX. Quoting the documentation : "Note: For logical interfaces on EX Series switches, the traffic statistics fields in show interfaces commands show only control traffic; the traffic statistics do not include data traffic. " This make me in real trouble for billing, as I mixed customers vlan(s) on physical ports in my architecture... I wonder if someone ever faced this problem, and if there is some king of workarround. The goal is to monitoring traffic, and billing. Thks. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vMX availability
A friendly PLM said the following was okay to post: "VMX FRS is 14.1R5 which is expected to be out by the 1st week of June." Ah good, I ve got a pricelist from Juniper, and price looks ok :) So we can move forward and test. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Buying a used Juniper
Le 05/05/15 18:47, Colton Conor a écrit : What are the limitations of buying a used Juniper MX router? I assume there will be no JTAC support, but what would it take to licenses a used router to get JTAC support? I don't know if juniper allow this, but if yes I think the price will be prohibitive :) Does JTAC offer a one time support call fee for unlicensed routers? I don't think so. And why Juniper will make this ? Juniper (as well as other network vendor) don't like grey market. The router in question would be a MX480. Used, we can get them for under 20K with redundant everything and 4 10G ports. New from Juniper I don't even want to know what these would cost. Lets try it. Juniper can make aggressive price :) -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vMX availability
Le 04/05/2015 22:22, Josh Baird a écrit : I may need to talk to another sales partner, because I can't seem to even get a trial from the company that I am working with now. Depends on your country, but I may be easier and better to talk directly with juniper. Anyway the price is correct, but for RR, vRR or vSrx (Firefly perimeter) should be sufficient (?) Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vMX availability
Le 30/04/15 22:49, Daniel Rohan a écrit : The good advice I got when I asked this question a few months back was "talk to your SE". I did, and it was fruitful. I ll try it again so :) -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Thoughts on MX80 v MX104 RE performance
Le 23/04/15 18:22, Saku Ytti a écrit : Since 13.2 you could toggle rpd to 64b mode. Hum interresting. Anyone have feedback about that ? Stability ? -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Thoughts on MX80 v MX104 RE performance
Le 23/04/15 18:08, Mike Williams a écrit : I'm only seeing 64-bit Junos available for MX240 and up And they already have hugely powerful x86 REs as options. Correct me if I'm wrong but I think that only the kernel is boot in 64bits mode, but rpd and other problem still run 32bits.? Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Thoughts on MX80 v MX104 RE performance
Le 23/04/15 15:13, Saku Ytti a écrit : Yeah at least 10k has XEON. I don't really understand why vendors use PPC, is it mainly motivated by BOM or pincount/thermal or some other issues? Yes on cheap boxes, ppc processor still have a good power/price ratio. The real problem is the performance of junos on ppc. It can be acceptable on cheap switch (like the EX series), but not on MX. But yeah, JunOS relies on terrific single thread performance, but unsure how long they can get away with it. Juniper is aware of this problem, and work on this. Junos 15 should have limited smp capabilities (afaik rpd will still not be multi-thread). For some reason, IOS with equivalent CPU is much faster to converge. Cisco have made the effort to rewrite their os (and not only once, ios15, ios-xr, nxos, etc...). Juniper should make the same, and rewrite junos from scratch in my opinion, and I think the monolithic design of rpd should be rethinked. Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRF route leaking on EX4550
Le 21/04/15 16:02, Raphael Mazelier a écrit : Me again. I'm facing a problem when mixing rib-groups export and vrf import/export. When exporting routes from A to vrf X with rib-groups, these routes is candidate to be re-exported in mpbgp VPN X, which is not I want (result in routing loop). My current solution is to tag the exported routes via rib-groups import policy, and to explicitely exclude theses routes in the vrf-export policy. I'm not very happy whit that. I'm wonder if someone have already facing this problem, and have a better/alternative options. And finaly this do not work. Directly connected route leaking on EX is not supported ?! https://kb.juniper.net/InfoCenter/index?page=content&id=KB23027 If anyone have better workaround those mentionned in kb... Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRF route leaking on EX4550
Le 20/04/15 17:27, Raphael Mazelier a écrit : In my opinion rib-groups have a more complex syntax than auto-export wich seems natural to me. Anyway with the help of this documentation and templating feature of junos, I ll be able to make a relatively clear configuration. Me again. I'm facing a problem when mixing rib-groups export and vrf import/export. When exporting routes from A to vrf X with rib-groups, these routes is candidate to be re-exported in mpbgp VPN X, which is not I want (result in routing loop). My current solution is to tag the exported routes via rib-groups import policy, and to explicitely exclude theses routes in the vrf-export policy. I'm not very happy whit that. I'm wonder if someone have already facing this problem, and have a better/alternative options. Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRF route leaking on EX4550
Le 17/04/15 19:31, Ivan Ivanov a écrit : Hi Raphael, Check that link for differences between auto-export and rib-groups: http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349 Thanks for this excellent link. It's a must read. I don't see why to not use rib-groups except if they are not support too. In my opinion rib-groups have a more complex syntax than auto-export wich seems natural to me. Anyway with the help of this documentation and templating feature of junos, I ll be able to make a relatively clear configuration. Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Thoughts on MX80 v MX104 RE performance
Le 20/04/15 16:38, Mike Williams a écrit : And relatedly, has anyone heard any recent rumours around when Junos might take advantage of the second CPU? From the Freescale docs both CPUs are dual-core. I'll be very interested in some benchmarks of the actual mx104 RE. There two rumours : - an intel based RE for the mx104 (will make the perfect small router) for 2016 perhaps ? - an new junos realease SMP aware : probabily 100%, but afaik it will not concerned rpd, but it will only enable the fact that rpd run on one core, and other process on other one. Will be appreciable for sampled anyway. release in 15.0 ? Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VRF route leaking on EX4550
Hello, I've got a network with multiple customers vrf, defined mostly on EX4550. I have to leak some route (from a 'admin/service' instance) on all customers vrf. This work well with vrf-import/export. I've rectenly notice that auto-export is not implemented in EX junos code :( how I missed that on the initial design ? :) So leaking is currently not made localy, but this is working because all my vrf are double defined on two EX. The problem is if I lost one my EX, the leaked route will be widhdraw... (the other problem is that the traffic made ping pong) Any idea ? Am I forced to use rib-group ? and how it will inter-operate with mbgp import/export ? Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stable JunOS for MX80
Le 16/04/15 10:58, thiyagarajan b a écrit : Thanks All for your suggestions, Have taken 14.1R4 OS which has no bugs relating to our config. The memory (2GB RAM and Flash) would suffice? The best release will depends of our need. Basicly if you do not want sampling you are safe running stable 11.4 branch. Or use the jtac recommanded version : 12.3R8.7. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Recommended Junos version for EX-4500 virtual chassis
Hi, Currently running 12.3R7.7 with no apparent trouble. Previous versions were exhibiting memory leaks. I'm running dozen of EX4550 VC with 12.3R7.7. Running fine. I've tested 13.2X50, and I'm faced strange routing problem, so I'm stick with the 12.3 train. Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos MX series and Andrisoft Flow tools
Le 26/01/15 17:19, sth...@nethelp.no a écrit : As far as I know the software version cannot do IPfix. Yes, software flow are jflow or cflow v5. -- Raphael Mazelier AS39605 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos MX series and Andrisoft Flow tools
Le 26/01/15 16:03, John Brown a écrit : Hi Raphael, I curious as why you are using software flow. I thought the inline was better from a performance perspective on the router.. Bad experience with inline jflow on mx80, and also inline ipfix is a bit buggy, missing some field. It seems that juniper have fixed this on higher release, but I m happy with software flow for now. -- Raphael Mazelier AS39605 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos MX series and Andrisoft Flow tools
I'm testing wanguard with my mx.
The product is interresting, not perfect, but interresting.
I'm not using inline ipfix, but software flow with the below
configuration :
sampling {
input {
rate 1000;
}
family inet {
output {
flow-server 15.5.17.7 {
port 5678;
source-address 15.5.17.10;
version 5;
}
}
}
}
with Flow protocol : Netflow v5,v7 or v9, IPFIX.
The wanguard documentation specifie that if we are using juniper and
ipfix, we habe to choose Flow protocol "IPFIX with flows Timeout".
--
Raphael Mazelier
AS39605
Le 26/01/15 05:29, Jordan Whited a écrit :
If clocks are sync’d my best guess would be that your active and/or inactive
flow timeouts are longer than what is configured on the collector and it
doesn’t like that.
Try making them match the collector and if that doesn’t work make the MX
timeouts slightly shorter.
http://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/services-ipfix-flow-template-flow-aggregation-configuring.html
<http://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/services-ipfix-flow-template-flow-aggregation-configuring.html>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface / Errata / Update
Agreed on cheaper switch. High end EX series seems a bit different tought. Some big IX (Linx, FranceIX) run with vpls topologies on EX9200 series (with some issues :) ). Rectification: Linx does not use EX9200 switches but high end PTX 5000 switches. FranceIX use EX9200 switches. Sorry for the mistake (this is pulicly available informations) They both use VPLS but the design slighly differ. Update : Finally the VPLS issue on the France-IX seems to be fixed (with the help of the jtac). No problem since the new release was in production. -- Raphael Mazelier AS39605 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3 to the rack and L2 services over MPLS
Le 27/11/14 08:59, Sebastian Wiesinger a écrit : Is there any switch in the portfolio that would give you the ability to do L3 to the rack and still have multipoint L2 services implemented over it? VPLS or even better EVPN as L2 MPLS service would be required. My perfect setup would be: L3 to the rack switch with BGP and MPLS on top. Then over that implement your standard MPLS services for L2. I was unable to find such a device. It seems that if you want to do L2 services you need to lock yourself into QFabric or VCF. Vendor lock-in is something I want to avoid if possible. It's really annoying that they use the same technics under the hood in their fabrics but you can't do it without the fabric. Any thoughts? High end EX (EX9200) support MPLS and VPLS. Be warning that the VPLS code is far from perfect (the France-IX have some many issues due to VPLS for example). For cheaper I end with EX4550 that have correct MPLS/BGP support, and L2Circuit only. Regards, -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt
Le 19/11/14 20:48, Mark Tinka a écrit : On Wednesday, November 19, 2014 09:03:59 PM Philip Palanchi wrote: I'm curious to know what MPLS features or functionalities are lacking on the EX4550 in comparison to MX series. That's like asking what features or functionalities are lacking on a commercial airliner vs. a military fighter jet :-). Basically, a lot of difference in MPLS feature set between these platforms. This might be a good place to start: http://tinyurl.com/o5sekyu The "Related Documentation" sidebar has some nice tidbits too. As I played with EX4550 I can confirm that basic MPLS feature are supported (RSVP, LDP signalling, L3VPN, L2circuit), but with slow limit in term of path, vrf, etc... The EX9200 support VPLS but with some bug (thks to the FranceIX to debug the juniper code). -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface SOLVED
So to end this thread with some kind of success :)
And to sum up what work and what didn't.
So basic l2circuit (CCC/Ldp signaling) between my EX and MX with lt
interface finally work with a config as simple as :
EX side :
ge-0/0/10 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
l2circuit {
neighbor 10.10.176.10 {
interface ge-0/0/10.0 {
virtual-circuit-id 10666;
no-control-word;
}
}
}
MX side :
lt-1/1/10 {
unit 0 {
encapsulation ethernet-ccc;
peer-unit 1;
family ccc;
}
unit 1 {
encapsulation ethernet;
peer-unit 0;
family inet {
address 10.1.1.6/24;
}
}
}
l2circuit {
neighbor 10.10.176.13 {
interface lt-1/1/10.0 {
virtual-circuit-id 10666;
no-control-word;
}
}
}
What's wrong with my EX was the interco between the EX and the next core
router. When It was tagged everything work (ISIS, MBGP, LDP, L3VPN),
except the l2circuit ?!
Even if it was a bad idea to use tagged interco it's a bit surprising
(and remember the original idea was to backhaul transit customer to core
with vlan).
Little experiment with EX4550 give me also some result I can share :
- l2circuit with vlan-ccc encapsulation work as well, but with a liltte
trick in the interface configuration on the ex-side (unless the
l2circuit report Encapsultion Invalid) ex :
ge-0/0/10 {
encapsulation vlan-ccc;
vlan-tagging;
unit 66 {
encapsulation vlan-ccc; < this is redundant but needed
vland-id 66;
family ccc;
}
}
- connections ccc (rsvp based) seems to works as well, but I don't want
to use rsvp in my network by now.
- l2vpn ccc (bgp signalling) didn't work on EX, configuration passed
with ethernet-ccc encapsulation, not vlan-ccc so I think it was not
supported. This is uncool since I think it was the better approach.
Anyway the cool thing with l2circuit is that there was inter operable
with other vendor.
- vpls didn't work at all on EX4550 (but that's clear on the specsheat)
- l3vpn is quite limited in term of routing instance and route, but work.
Another things I try is to separate fib/rib to show how much route an
ex4550 can manage in his rib. OK I know this is bad idea :)
The answer is 300K route approx before rpd crash.
So no full view, even only in RIB.
After all this cheap switch was making his job. Good value for money.
Thks for all.
--
Raphael Mazelier
AS39605
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 13/11/14 01:29, Chip Gwyn a écrit : I was using RSVP at the time, sorry I left that part out. If you're getting one-way traffic it might be that one of the LSPs isn't up. --chip That's it but I wonder why ? EX side : rancid@sr-dc2-01# run show mpls lsp Ingress LSP: 1 sessions To FromState Rt P ActivePath LSPname 192.58.176.10 192.58.176.13 Up 0 * from-ex-to-mx Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To FromState Rt Style Labelin Labelout LSPname 192.58.176.13 192.58.176.10 Up 0 1 FF 300304- from-mx-to-ex Total 1 displayed, Up 1, Down 0 rancid@sr-dc2-01# run ping mpls rsvp from-ex-to-mx ! --- lsping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss So it's OK this way. MX side : rancid@cr-dc2-01# run show mpls lsp Ingress LSP: 1 sessions To FromState Rt P ActivePath LSPname 192.58.176.13 192.58.176.10 Up 0 * from-mx-to-ex Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To FromState Rt Style Labelin Labelout LSPname 192.58.176.10 192.58.176.13 Up 0 1 FF 300176- from-ex-to-mx Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 rancid@cr-dc2-01# run ping mpls rsvp from-mx-to-ex . --- lsping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss What could be missing ? Here is my config : http://pastebin.com/bHP9FFsp Thks. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 12/11/2014 16:38, Eric Van Tol a écrit : Now, to get back on topic: OP - we have some L2circuits on LT interfaces, but not with an EX on the other end. Is there any way you can try this by hairpinning a couple of GE ports on the MX80? Also, what's the reason behind using 'l2vpn' instead of 'l2circuit'? I see you are using private addressing on your interface - is there any chance that there are blanket filters applied to your interface using configuration groups or perhaps a forwarding table filter to prevent 1918 space from traversing your network? I have only 10G port on my mx80, but since there are not totally in prod, I will test that using a XFP DAC (and I finaly find an utitility for this cable :) No reason to use l2vpn, I've tried l2circuit too, and now connections (rsvp based ccc). I would prefer using l2vpn if it work since I think it's smarter to use bgp signalling; but l2circuit are acceptable. And no; no filter (I deactivate all filter...) With chip's configuration I've have some traffic (arp in one way), but nothing more. I think there is definitively something wrong with EX and l2vpn. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 11/11/14 22:29, chip a écrit : http://pastebin.com/YYfHk9M2 That should get you. *Caveats apply* but it does work =) --chip Thks you chip. With your configuration I've made some progress. Now I've got some arp replies on the CE connected to the EX : 2.1.1.5 > 2.1.1.6: ICMP echo request, id 26654, seq 11, length 64 17:42:39.031721 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 2.1.1.5 tell 2.1.1.6, length 46 17:42:39.031731 ARP, Ethernet (len 6), IPv4 (len 4), Reply 2.1.1.5 is-at 78:2b:cb:28:2d:55, length 28 The lt mac is correctly learn on the CE. But for one reason or another the mac address of the ce is not learn on the mx80 side ?! I'm just out of luck for this setup :( -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 11/11/2014 21:08, 👪Karl Brumund - lists a écrit : EX (and QFX) have limited MPLS capabilities. The data sheet is rather optimistic about the capabilities, and a bit misleading about such things as route limits Expecting a cheap switch with merchant silicon to do the same as an expensive MX with custom ASICs is asking for trouble. Seriously, just do L2. Customer port is access, MX80 is trunked. You’re just asking for trouble with MPLS and L2VPN. Much of the same opinion, from quite recent exposure. Cheers, mh Agreed on cheaper switch. High end EX series seems a bit different tought. Some big IX (Linx, FranceIX) run with vpls topologies on EX9200 series (with some issues :) ). Anyway. Redesigning my network at this stage might be challenging. I will try to let this work, and think about a new design in //. Thks. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Speculation on my side, but given the limited MPLS capabilities on EX switchs, control plane may work fine due to common code within the Juniper product line, but the forwarding plane fails you. This could explain why things look up/up, but without traffic. Well, you should be right. On the other the spec of the EX4550 specifie that l2vpn (at least l2circuit) should be working... And some other guys on the list report some kind of success with that. Thks. -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 10/11/2014 21:18, Hugo Slabbert a écrit : Correct. I think I see Rafael's issue, though. He has a mix of predominantly MPLS (probably L3VPN) customers that terminate L3 on the EX, which can handle that because that's internal routes only, not full tables. He also has a few transit customers coming through the EX, though. The EX (unlike the MX) can't handle a mix of L2 and L3 on the same port. His MX-EX touchdown is currently L3 on the EX in order to support his MPLS customers. He would need that EX port in L2 in order to carry customer VLANs through to the MX. If he does that, though, he'd need his L3 on the EX on VLAN interfaces, and per his comment: That's exactly my use case. ...that's apparently not supported, which means his MPLS customer setup would break in order to support switching his transit customers through the EX to the MX. Yes, and I have very few transit customers compared to my 'l3vpn' customers. I haven't done the L2VPN setup to LTs that you're working with, Rafael, so I can't help you out there. An alternative may be to move your L3 and MPLS config from the EX to the MX, but that has a bunch of downsides (loads up your 10G link with additional traffic that would have been only on the EX's backplane before; maintenance hit for moving all of the config; changes topology; more load on the MX80; etc). Yep moving my L3 and MPLS config to the MX is not an option. The main reason is because my EX are double attached to two MX. I can handle the lost of one EX with no problem (aside my transit cust, but that is marginal). Aside from that, I'll bow out for someone that might have worked with the LT setup you're attempting. It's frustrating because I think I'm very close, since the L2vpn/L2circuit comes up. I will try to capture the traffic to see what happen (some encapsulation problem). And even if the correct solution is to force my transit customer to use ebgp multihop, I need this plan B solution for some customers I cannot contact (sigh)... -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 10/11/14 18:40, Hugo Slabbert a écrit : What's the connection between the EX and the MX? Could you not just switch the customers through the EX to the MX and land them on tagged interfaces on the MX? I don't know all of your requirements, but perhaps the simple option works here? Ah good question. I have only one 10G ethernet back to back connection between the EX and the MX. And I want to use my EX as a router for managing the gateway of my clients on it. So I need BGP/MPLS on it, and unfortunelaty MPLS does not work on vlan interface on Ex :( I was a pseudo BGP/Tor design. It work well, but I does not want to use a dedicated MX80 port and switch to transit customers (wich are not the majority). If I had more money I had bought some MX480 :p -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Hello,
I'm redesigning my network, and I have to terminate some customer BGP
sessions (full view) on new EX4550 (no comment, ... )
Since the EX4550 does not support full view, I had to logicaly terminate
the session on a real router (MX80 in this case).
The logical way to do is to use bgp multi hop, but some of my customer
are unaware of changing their settings on their side.
So my plan is to use l2vpn (or l2circuit) between the EX and the MX, and
to use a virtual interface on the MX to end the sessions.
And reading some thread it seems that I have to use lt interface.
The l2vpn connections are OK on both side, but nothing is reachable (and
I have nothing to tcpdump yet).
Bellow is my config :
EX side :
interfaces {
ge-1/0/11 {
encapsulation ethernet-ccc;
unit 0;
}
}
routing-instances {
l2vpn {
instance-type l2vpn;
interface ge-1/0/11.0;
route-distinguisher 666:666;
vrf-target target:666:666;
protocols {
l2vpn {
encapsulation-type ethernet;
site EX {
site-identifier 1;
ignore-mtu-mismatch;
interface ge-1/0/11.0 {
remote-site-id 2;
}
}
ignore-encapsulation-mismatch;
}
}
}
}
MX side :
interfaces {
lt-0/0/10 {
unit 0 {
encapsulation ethernet-ccc;
peer-unit 1;
family ccc;
}
unit 1 {
encapsulation ethernet;
peer-unit 0;
family inet {
address 10.1.1.1/24;
}
}
}
}
routing-instances {
l2vpn {
instance-type l2vpn;
interface lt-0/0/10.0;
route-distinguisher 666:666;
vrf-target target:666:666;
protocols {
l2vpn {
encapsulation-type ethernet;
site cr-dc2-01 {
site-identifier 2;
ignore-mtu-mismatch;
interface lt-0/0/10.0;
}
}
}
}
}
Any suggestions ? or other way to do ? (I ve tested l2circuit and it
does not work anyway)
--
Raphael Mazelier
AS39605
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
