Re: [j-nsp] ACX EVO - funky auto complete

[Vincent Bernat via juniper-nsp]

On 2024-05-30 11:52, Ola Thoresen via juniper-nsp wrote:

This is fun...


 > show version
(...)
Model: acx7348
Junos: 23.4R1-S1.11-EVO

 > show lldp neighbors*//*
^
'neighbors ' is ambiguous.
Possible completions:
   neighbors    Show LLDP neighbor information
   neighbors-vlan-name-tlv-list  Show list of Vlan-Name in the LLDPDU of 
the interface


Exact same version, same hardware, I don't get this bug.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX10008 power supply configuration

[Vincent Bernat via juniper-nsp]

Thanks!

In the meantime, I got additional information from our SE but I have 
failed to report them here.


The switches on the PSU to select which inputs are enabled are just here 
for monitoring. If you enable both inputs and loose one, it will use the 
same amount of power on the remaining input than if it was configured 
with only a single input. The only difference is that you won't get an 
alarm.


Therefore, using 30A, you must be prepared to have 5000W on a single 
input, so around 22A (in Europe). Therefore, using 16A inputs won't 
work. If you are using 20A, the max would be 2700W on a single input, so 
around 12A.


As the PSU is "platinium", it should have around 90% efficiency at full 
load, so I would expect it should work with 3000W. But, I suppose there 
is additional margin of errors taken into account.


Another interesting info, is that if you mix 20A and 30A, you'll get 
20A. But once you switch the last 20A one to 30A, all PSU will switch to 
30A automatically. So, you can upgrade from 20A to 30A, one PSU at a time.


On 2024-03-01 16:06, Richard McGovern wrote:

Not sure if this may help you or not.

Rich

Richard McGovern

Sr Sales Engineer, Juniper Networks

978-618-3342

I’d rather be lucky than good, as I know I am not good

I don’t make the news, I just report it

A close-up of a sign Description automatically generated


Juniper Business Use Only

On 2/18/24, 11:54 PM, "Mark Tinka"  wrote:

On 2/17/24 17:12, Vincent Bernat via juniper-nsp wrote:

 > Hey!

 >

 > I am a bit lost on how the MX10008 power supplies work. My main

 > question is how much power will be drawn if a power feed is lost?

 >

 > If we take the JNP10K-PWR-AC2 dual feed with high power (30-A)

 > setting, configured for dual feed, it can draw 5500 W. In Europe

 > (230V), I suppose it means it will draw 12A on one feed and 12A on the

 > other. This is not clearly stated.

 >

 > What happens if we lost one feed? I suppose it would fall back at 5000

 > W, so it would draw 22A on the remaining feed, but maybe it could just

 > fallback to half the power at 12A?

 >

 > If it would fallback at 5000 W, I don't understand why there are DIP

 > switches to configured mono or dual feed. We could just not plug the

 > second feed and be done with it.

 >

 > Also, on the power supply, there are these markings:

 >

 > INPUT1 OR INPUT2: PER INPUT 28.5A, 5000W MAX

 > INPUT1 AND INPUT2: PER INPUT 16A, 5500W MAX

 >

 > But again, it is unclear if the choice is done by configuring the

 > switches or if this depends on the number of actuel inputs used. If I

 > configure the DIP switches to use both input, do I still get 16A per

 > input if one feed fails?

 >

 > Ideally, when configured in high power mode, it could fallback to

 > ~3700W when on one feed, but I suppose this would marked more clearly

 > in the documentation. This would mean 33kW when full, 16.5kW when

 > loosing half the power supplies (unlikely if they are dual feed) and

 > 22kW when loosing one feed.

 >

 > Otherwise, we'll run in 20A mode, get 30kW with 6 power supplies, or

 > 15kW with half of them or 16.2kW with half of the feeds.

Sounds like the kind of question best answered by your SE.

Mark.


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

[j-nsp] MX10008 power supply configuration

[Vincent Bernat via juniper-nsp]

Hey!

I am a bit lost on how the MX10008 power supplies work. My main question 
is how much power will be drawn if a power feed is lost?


If we take the JNP10K-PWR-AC2 dual feed with high power (30-A) setting, 
configured for dual feed, it can draw 5500 W. In Europe (230V), I 
suppose it means it will draw 12A on one feed and 12A on the other. This 
is not clearly stated.


What happens if we lost one feed? I suppose it would fall back at 5000 
W, so it would draw 22A on the remaining feed, but maybe it could just 
fallback to half the power at 12A?


If it would fallback at 5000 W, I don't understand why there are DIP 
switches to configured mono or dual feed. We could just not plug the 
second feed and be done with it.


Also, on the power supply, there are these markings:

INPUT1 OR INPUT2: PER INPUT 28.5A, 5000W MAX
INPUT1 AND INPUT2: PER INPUT 16A, 5500W MAX

But again, it is unclear if the choice is done by configuring the 
switches or if this depends on the number of actuel inputs used. If I 
configure the DIP switches to use both input, do I still get 16A per 
input if one feed fails?


Ideally, when configured in high power mode, it could fallback to ~3700W 
when on one feed, but I suppose this would marked more clearly in the 
documentation. This would mean 33kW when full, 16.5kW when loosing half 
the power supplies (unlikely if they are dual feed) and 22kW when 
loosing one feed.


Otherwise, we'll run in 20A mode, get 30kW with 6 power supplies, or 
15kW with half of them or 16.2kW with half of the feeds.

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

Re: [j-nsp] Hardware configuration for cRPD as RR

[Vincent Bernat via juniper-nsp]

Juniper does not have a lot of guidelines on this. This is a bit 
surprising to us too. I would have expect some guidelines about IRQ and 
CPU pinning. It seems they think this does not matter much for a RR.


However, cRPD comes with better performance than vRR and therefore, 
Juniper pushes to cRPD instead of vRR.


On 2024-02-08 08:50, Roger Wiklund via juniper-nsp wrote:

Hi

I'm curious, when moving from vRR to cRPD, how do you plan to manage/setup
the infrastructure that cRPD runs on?

BMS with basic Docker or K8s? (kind of an appliance approach)
VM in hypervisor with the above?
Existing K8s cluster?

I can imagine that many networking teams would like an AIO cRPD appliance
from Juniper, rather than giving away the "control" to the server/container
team.

What are your thoughts on this?

Regards
Roger


On Tue, Feb 6, 2024 at 6:02 PM Mark Tinka via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:




On 2/6/24 18:53, Saku Ytti wrote:


Not just opinion, fact. If you see everything, ORR does nothing but adds

cost.


You only need AddPath and ORR, when everything is too expensive, but
you still need good choices.

But even if you have resources to see all, you may not actually want
to have a lot of useless signalling and overhead, as it'll add
convergence time and risk of encouraging rare bugs to surface. In the
case where I deployed it, having all was not realistic possibly, in
that, having all would mean network upgrade cycle is determined when
enough peers are added, causing RIB scale to demand triggering full
upgrade cycle, despite not selling the ports already paid.
You shouldn't need to upgrade your boxes, because your RIB/FIB doesn't
scale, you should only need to upgrade your boxes, if you don't have
holes to stick paying fiber into.


I agree.

We started with 6 paths to see how far the network could go, and how
well ECMP would work across customers who connected to us in multiple
cities/countries with the same AS. That was exceedingly successful and
customers were very happy that they could increase their capacity
through multiple, multi-site links, without paying anything extra and
improving performance all around.

Same for peers.

But yes, it does cost a lot of control plane for anything less than 32GB
on the MX. The MX204 played well if you unleased it's "hidden memory"
hack :-).

This was not a massive issue for the RR's which were running on CSR1000v
(now replaced with Cat8000v). But certainly, it did test the 16GB
Juniper RE's we had.

The next step, before I left, was to work on how many paths we can
reduce to from 6 without losing the gains we had made for our customers
and peers. That would have lowered pressure on the control plane, but
not sure how it would have impacted the improvement in multi-site load
balancing.

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


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

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

Re: [j-nsp] Hardware configuration for cRPD as RR

[Vincent Bernat via juniper-nsp]

On 2023-12-07 15:21, Michael Hare via juniper-nsp wrote:

I recognize Saku's recommendation of rib sharding is a practical one at 20M 
routes, I'm curious if anyone is willing to admit to using it in production and 
on what version of JunOS.  I admit to have not played with this in the lab yet, 
we are much smaller [3.5M RIB] worst case at this point.


About the scale, I said routes, but they are paths. We plan to use add 
path to ensure optimal routing (ORR could be another option, but it is 
less common).

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

[j-nsp] Hardware configuration for cRPD as RR

[Vincent Bernat via juniper-nsp]

Hey!

cRPD documentation is quite terse about resource requirements: 
https://www.juniper.net/documentation/us/en/software/crpd/crpd-deployment/topics/concept/crpd-hardware-requirements.html


When used as a route reflector with about 20 million routes, what kind 
of hardware should we use? Documentation says about 64 GB of memory, but 
for everything else? Notably, should we have many cores but lower boost 
frequency, or not too many cores but higher boost frequency?


There is a Day One book about cRPD, but they show a very outdated 
processor (Sandy Lake, 10 years old).


Is anyone using cRPD as RR with a similar scale and can share the 
hardware configuration they use? Did you also optimize the underlying OS 
in some way or just use a stock configuration?


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

Re: [j-nsp] QFX5100-48S-AFI/AFO vs QFX5100-48S-3AFI/AFO

[Vincent Bernat via juniper-nsp]

 ❦ 27 October 2021 00:31 +02, Thomas Bellman via juniper-nsp:

> (And hey, Juniper, how about making those management ports actually
> useful, and connect them to an IPMI controller with support for Serial
> Over LAN?  That would be super helpful, especially when you are e.g.
> upgrading Junos on them.)

In this case, let them be a shared port between IPMI dans JunOS. Like
what is done in Facebook Wedge switches.
-- 
You tread upon my patience.
-- William Shakespeare, "Henry IV"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Looking for Hints: Best Practices to PUSH prefix-list on MX platform with 16.x and UP

[Vincent Bernat via juniper-nsp]

 ❦ 13 August 2021 11:44 +03, Saku Ytti via juniper-nsp:

> You could have something like this:
>
> groups {
>   IRR {
>  ...
>}
> }
>
> Then always generate complete new prefix lists in NMS into a single file.
>
> And have script do:
>
> edit groups
> delete IRR
> load merge https://nms/irr.junos
> commit and-quit

To tighten a bit:

edit groups
delete IRR
edit IRR
load merge relative https://nms/irr.junos
commit and-quit
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vQFX cpu cores and ram

[Vincent Bernat via juniper-nsp]

Hello Aaron,

For VCP, I am using 1G and 1 vCPU, same for VFP. I am using 19.4R1. As
the wiki suggests 2GB and 4GB, this seems quite comfortable. My setup
may be too simplistic compared to yours. See for example
https://github.com/vincentbernat/network-lab/tree/master/lab-juniper-vqfx-vxlan-symmetric
which works fine with 1G for each.

It may just be that the memory and CPU need to be increased for each
interface. In non-lite mode, the vMX has this kind of requirements.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)

-Original Message-
From: aaron--- via juniper-nsp 
Sent: 23 June 2021 04:43 +02
Subject: [j-nsp] vQFX cpu cores and ram
To: Juniper NSP

> From: aa...@digitalcrossroad.org
> Subject: vQFX cpu cores and ram
> To: Juniper NSP 
> Date: Wed, 23 Jun 2021 04:43:36 +0200 (CEST) (3 hours, 28 minutes ago)
>
> Hi All,
>
> If you have experience running vQFXs, what are you setting for cpu cores and 
> ram?
>
> I'm using eve-ng to get around group_fwd_mask issues[1] such that I
> can have lacp and lldp working right out of the box.
>
> The defaults on the github page do not seem enough, as if I set those
> values, I can't even get lacp bundles to come up, once I bump the
> resources, the bundles come up.
>
> I've asked my SE, but I would like to know what the community has set in 
> their environments?
>
> Thanks,
> Aaron
> 1. 
> https://interestingtraffic.nl/2017/11/21/an-oddly-specific-post-about-group_fwd_mask/
> --
>
> ___
> 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] Overlay physical interfaces and Overlay next-hop

[Vincent Bernat]

They are from my Juniper SE. Maybe there is some KB explaining that, but
at the time, there was not.
-- 
Grief can take care of itself; but to get the full value of a joy you must
have somebody to divide it with.
-- Mark Twain

-Original Message-
From: "Phan Thanh Tung (FPT Smart Cloud) via juniper-nsp" 

Sent: 24 mars 2021 09:01 GMT
Subject: Re: [j-nsp] Overlay physical interfaces and Overlay next-hop
To: Vincent Bernat; Phan Thanh Tung via juniper-nsp

> From: "Phan Thanh Tung (FPT Smart Cloud)" 
> Subject: RE: [j-nsp] Overlay physical interfaces and Overlay next-hop
> To: Vincent Bernat , "Phan Thanh Tung (FPT Smart Cloud) via 
> juniper-nsp" 
> Date: Wed, 24 Mar 2021 09:01:58 + (47 minutes, 31 seconds ago)
>
> I am quite interested in the formula that calculates the number of next-hops 
> and interface-number you provide as reference.
>
> I would appreciate it if you could explain more clearly the parameters
> included in the above formulas corresponding to a specific context.
>
> -Original Message-
> From: Vincent Bernat [mailto:ber...@luffy.cx] 
> Sent: Wednesday, March 24, 2021 2:01 PM
> To: Phan Thanh Tung (FPT Smart Cloud) via juniper-nsp 
> 
> Cc: Phan Thanh Tung (FPT Smart Cloud) 
> Subject: Re: [j-nsp] Overlay physical interfaces and Overlay next-hop
>
>  ❦ 24 mars 2021 03:25 GMT, Phan Thanh Tung (FPT Smart Cloud) via juniper-nsp:
>
>> Junos allows to re-allocate the maximum number of physical interfaces 
>> and the maximum number of next hops reserved for use in an Ethernet 
>> VPN-Virtual Extensible LAN (EVPN-VXLAN) overlay network.
>>
>> [edit forwarding-options]
>> vxlan-routing {
>>   interface-num integer;
>>   next-hop integer;
>>   overlay-ecmp;
>> }
>>
>> https://www.juniper.net/documentation/en_US/junos/topics/reference/con
>> figuration-statement/interface-num-edit-forwarding-options.html
>>
>> https://www.juniper.net/documentation/en_US/junos/topics/reference/con
>> figuration-statement/next-hop-edit-forwarding-options-vxlan-routing.ht
>> ml
>>
>>
>> I don't know how to determine how many overlay physical interfaces and 
>> overlay next-hop have been used.
>
> There is a first hard limit of 16k virtual ports but you should stay below 
> 12k. Check with:
>
> request pfe execute command "show shim virtual vport" target fpc0 | count
>
> For next-hop, you can use:
>
> request pfe execute command "show nhdb summary" target fpc0
>
> This does not differentiate between next hops for VXLAN and next hops for the 
> remaining. If you increase the VXLAN one, you decrease the remaining 
> next-hops available by the same amount. On QFX 5110, the maximum is 45000 for 
> both. On QFX 5120, this is 61000. So, if you can manage a safe margin for 
> both next hops, you are fine.
>
> You can compute the number of next-hops manually with:
>
> - overlay: ARPs resolved via local IRBs ARP + Remote IRBs (number of
>   IRB per leaf*number of leaves) + Number of VRF with Type 5 * remote
>   VTEP with Type 5 + 1
> - underlay: 2 x Number of Layer-3 interfaces going towards each
>   spine + (Number of local-trunk-ports * number of vlans allowed on
>   each trunk port) + number of local access ports in each vlan + (Num
>   of Leaf-nodes – 1) * number of VLANs + 7
>
> For interface-num, this is the number of IRBs + number of routing-instances 
> that have at least one active Type 5 tunnel.
>
> Note, that was 2 years ago. Juniper has internal documentations about that, 
> so it may be better to ask JTAC for updates, notably an easier command to get 
> the result may be available.
> --
> Use the fundamental control flow constructs.
> - The Elements of Programming Style (Kernighan & Plauger)
> --
>
> ___
> 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] Overlay physical interfaces and Overlay next-hop

[Vincent Bernat]

 ❦ 24 mars 2021 03:25 GMT, Phan Thanh Tung (FPT Smart Cloud) via juniper-nsp:

> Junos allows to re-allocate the maximum number of physical interfaces
> and the maximum number of next hops reserved for use in an Ethernet
> VPN-Virtual Extensible LAN (EVPN-VXLAN) overlay network.
>
> [edit forwarding-options]
> vxlan-routing {
>   interface-num integer;
>   next-hop integer;
>   overlay-ecmp;
> }
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/interface-num-edit-forwarding-options.html
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/next-hop-edit-forwarding-options-vxlan-routing.html
>
>
> I don't know how to determine how many overlay physical interfaces and
> overlay next-hop have been used.

There is a first hard limit of 16k virtual ports but you should stay
below 12k. Check with:

request pfe execute command "show shim virtual vport" target fpc0 | count

For next-hop, you can use:

request pfe execute command "show nhdb summary" target fpc0

This does not differentiate between next hops for VXLAN and next hops
for the remaining. If you increase the VXLAN one, you decrease the
remaining next-hops available by the same amount. On QFX 5110, the
maximum is 45000 for both. On QFX 5120, this is 61000. So, if you can
manage a safe margin for both next hops, you are fine.

You can compute the number of next-hops manually with:

- overlay: ARPs resolved via local IRBs ARP + Remote IRBs (number of
  IRB per leaf*number of leaves) + Number of VRF with Type 5 * remote
  VTEP with Type 5 + 1
- underlay: 2 x Number of Layer-3 interfaces going towards each
  spine + (Number of local-trunk-ports * number of vlans allowed on
  each trunk port) + number of local access ports in each vlan + (Num
  of Leaf-nodes – 1) * number of VLANs + 7

For interface-num, this is the number of IRBs + number of
routing-instances that have at least one active Type 5 tunnel.

Note, that was 2 years ago. Juniper has internal documentations about
that, so it may be better to ask JTAC for updates, notably an easier
command to get the result may be available.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Database size on JunOS

[Vincent Bernat]

Hey!

With a configuration file around 5 MB, we get a pretty big configuration
database:

% gunzip -c /config/juniper.conf.gz | wc
  122092  331622 4452705
router> show system configuration database usage
Maximum size of the database: 409.99 MB
Current database size on disk: 145.00 MB
Actual database usage: 69.82 MB
Available database space: 340.17 MB

How 5MB of text could translate to 145/69 MB in binary format?

The configuration file is "big" because we have some IRR-generated
policies.

Moreover, on a QFX10k, the partition for /var/rundb is quite small
(1GB). Is there a way to bump that, dynamically or through a reinstall?

Thanks.
-- 
Condense soup, not books!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netflow config for MX204

[Vincent Bernat]

 ❦ 12 avril 2020 11:43 +03, Saku Ytti:

>> We just export flows in-band. Just seems simpler, and has been reliable
>> for close to 10 years.
>
> in-band is right, Trio can export the flow itself, you will kill your
> performance if you do non-revenue port export.

What's a "non-revenue port"?
-- 
When in doubt, tell the truth.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VLAN sub-interfaces in VRR em0?

[Vincent Bernat]

 ❦  4 novembre 2019 11:02 -05, Jason Lixfeld :

> Running the JunOS VRR image on EVE-NG trying to get a vlan
> sub-interface working on em0:

It doesn't work when using virtio, but it works with e1000. Dunno if
EVE-NG allows you to pick which NIC device to use.
-- 
Don't go around saying the world owes you a living.  The world owes you
nothing.  It was here first.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VTEP Scale

[Vincent Bernat]

 ❦ 25 septembre 2019 18:19 +03, Mohammad Khalil :

> Am working with a customer of mine for DC refresh project.
> Per the requirements , I have been asked about VTEP scale numbers for our
> proposed switches which I cannot find to be honest.
> Our product is QFX5120-48Y
>
> Any ideas would be appreciated.

You should ask Juniper, the documentation about that is (AFAIK) not
public. On the QFX5110, there is a maximum of 16k virtual port. A
virtual port is either a remote VTEP or a VLAN assigned to an ethernet
switching interface. Then, you have these two settings:

 

 

-- 
"You have been in Afghanistan, I perceive."
-- Sir Arthur Conan Doyle, "A Study in Scarlet"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN on QFX5200

[Vincent Bernat]

Hello,

The QFX5110 is unable to route between a VXLAN and a layer 3 interface.
There is a hack documented here:

 
<https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-vxlan-qfx5110-l2-vxlan-l3-logical.html>

Such a setup is quite fragile. Only the QFX10k is able to act as a L3
gateway for VXLAN and be connected to non-VXLAN stuff. QFX5110 is only
able to act as a L3 gateway when routing between VXLANs.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Andrey Kostin 
 Sent: 25 septembre 2019 11:37 -04
 Subject: Re: [j-nsp] EVPN on QFX5200
 To: Vincent Bernat
 Cc: Liam Farr; juniper-nsp@puck.nether.net

> Thank you for reply.
> I meant a slightly different thing. Currently my setup is in lab stage
> with QFX5110 as spines and QFX5000 as leaves. I need to connect vlans
> running in EVPN-VXLAN fabric to an aggregation router, ideally two of
> them for redundancy. To have a redundant gateway for hosts sitting in
> VNIs I need to run EVPN L3 gateway somewere. It can be done either on
> aggregation routers or on QFX5110. Putting L3GW on routers means they
> have to run EVPN as well and effectively become leaves for VXLAN
> fabric. It may be a feasible solution in the future but for now we
> don't want to put EVPN-VXLAN in prod network. So, the another option
> is to run L3 gateways on spines and somehow route them to agg routers.
> Possible connectivity options between edge routers and spines could
> be:
> - have individual P2P routed links Spine-RTR and run BGP session
> between them. Balancing and redundancy in this case will be provided
> by BGP+ECMP and also limited by their capabilities.
> - have LACP to both Spines from each RTR and then L3 interface on each
> spine, BGP from each spine to each RTR. Load balancing is provided by
> BGP multipath+ECMP+LACP. In this case LACP bundle from spines POV is
> switched. Direct connection between spines is necessary in this case.
> ROuters in this topology play CE role for VXLAN fabric but connected
> to spines instead of leaves.
>
> Any recommendations or links to BCP are appreciated.
>
> Kind regards,
> Andrey
>
> Vincent Bernat писал 2019-09-21 01:34:
>> ❦ 20 septembre 2019 11:47 -04, Andrey Kostin :
>>
>>
>> I am not familiar with MPLS. You need to use QFX10k for the spines as
>> the QFX5k are not able to route VXLAN outside (or not able to route at
>> all).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN on QFX5200

[Vincent Bernat]

 ❦ 20 septembre 2019 11:47 -04, Andrey Kostin :

> Could you advise about various external connectivity options for
> EVPN-VXLAN fabric? Let's say there are two spines that centrally route
> VXLAN vnis and some leaves. Spines are CEs from core MPLS network
> perspective. I understand that EVPN can be extended to the PE router
> and L3-gateways run on them, but probably not right now. What is a
> proper way to connect spines to PE router or pair of PE routers? I'm
> looking into running EBGP from each spine to [each] PE router over
> routed P2P interface. Are there possible flaws in this topology? Is
> direct connection needed between spines in this case?

I am not familiar with MPLS. You need to use QFX10k for the spines as
the QFX5k are not able to route VXLAN outside (or not able to route at
all).
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN on QFX5200

[Vincent Bernat]

 ❦ 20 septembre 2019 11:55 +12, Liam Farr :

> I'm running VXLAN with ingress-node-replication in prod, can you
> explain what you mean by havoc?

When using EVPN, prefer using "set protocols evpn multicast-mode
ingress-replication". Using "set vlans XXX vxlan
ingress-node-replication" will send replicated packets to all VTEP,
including the ones not advertising the Type 3 route. See
:

> Retains the QFX1 switch’s default setting of disabled for ingress
> node replication for EVPN-VXLAN. With this feature disabled, if a
> QFX1 switch that functions as a VTEP receives a BUM packet
> intended, for example, for a physical server in a VLAN with the VNI of
> 1001, the VTEP replicates and sends the packet only to VTEPs on which
> the VNI of 1001 is configured. If this feature is enabled, the VTEP
> replicates and sends this packet to all VTEPs in its database,
> including those that do not have VNI 1001 configured. To prevent a
> VTEP from needlessly flooding BUM traffic throughout an EVPN-VXLAN
> overlay network, we strongly recommend that if not already disabled,
> you disable ingress node replication on each of the leaf devices by
> specifying the delete vlans vlan-name vxlan ingress-node-replication
> command.

In turn, this may exhaust the resources of the Broadcom
chipset (Trident2 or Trident2+) if you have a lot of VLANs and/or a lot
of VTEPs.
-- 
Talkers are no good doers.
-- William Shakespeare, "Henry VI"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN on QFX5200

[Vincent Bernat]

 ❦ 19 septembre 2019 16:25 -04, Andrey Kostin :

> You can also try to use this scrips to generate configs for your
> specific configuration:
> https://github.com/JNPRAutomate/ansible-junos-evpn-vxlan/

I would stay away from most of the random examples available on Internet
(even ones from Juniper). For example, the above is using
ingress-node-replication in the "vlan" directive. This will bring havoc
in your network.

Start with the following documentation which is correct:
 


Also, be sure to read the following page to know the limitations:
 


Notably, the QFX5200 is not able to route VXLANs.
-- 
Write clearly - don't sacrifice clarity for "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN - BGP attribute propagation on MXes

[Vincent Bernat]

 ❦  1 juillet 2019 16:38 +02, Guillermo Fernando Cotone 
:

> Does anyone have implemented BGP attribute propagation using EVPN route
> type-5?
> We're trying to get BGP community propagation over an EVPN L3VNI, but so
> far we had no luck. I've no idea if there's any knob to enable this.
>
> Our use-case is to connect BGP islands through an EVPN backbone, and we
> expect BGP attributes, such as communities, to be propagated over the
> backbone. Pretty much standard IP-VPN behavior. Also referenced here:
> https://tools.ietf.org/html/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02#section-4.2
>
> I'm not sure if this is actually supported on Juniper. We're
> running 17.3R3-S2.2.

We didn't had any luck either with 18.1R3-S5 on QFX. I didn't push the
issue to JTAC as we have found another way to implement what we wanted.
-- 
He jests at scars who never felt a wound.
-- Shakespeare, "Romeo and Juliet, II. 2"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LACP is not running between two VMX

[Vincent Bernat]

 ❦ 25 avril 2019 09:31 +01, :

> I haven't tried MC-LAG, but I used standard LAG (with LACP).
> The problem I faced was that the standard Linux bridges (usually used to
> simulate virtual p2p links between vMX-es won't forward BPDUs including LACP
> (and I did not find a way to hack around at that time)

You can play with /sys/class/net/br0/bridge/group_fwd_mask. Well, in
fact, you can't:

hat:/sys/class/net//bridge/group_fwd_mask
Date:   January 2012
KernelVersion:  3.2
Contact:net...@vger.kernel.org
Description:
Bitmask to allow forwarding of link local frames with address
01-80-C2-00-00-0X on a bridge device. Only values that set bits
not matching BR_GROUPFWD_RESTRICTED in net/bridge/br_private.h
allowed.
Default value 0 does not forward any link local frames.

Restricted bits:
0: 01-80-C2-00-00-00 Bridge Group Address used for STP
1: 01-80-C2-00-00-01 (MAC Control) 802.3 used for MAC PAUSE
2: 01-80-C2-00-00-02 (Link Aggregation) 802.3ad

Any values not setting these bits can be used. Take special
care when forwarding control frames e.g. 802.1X-PAE or LLDP.
-- 
Go not to the elves for counsel, for they will say both yes and no.
-- J.R.R. Tolkien
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN-VXLAN: Mixing QFX and EX

[Vincent Bernat]

 ❦ 16 avril 2019 20:09 +00, Richard McGovern :

> 5110, can NOT route between VLAN/IP and VXLAN, today.  This is a
> future (some 19.x?).

It is believed to be able to do that now:
 
https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-vxlan-qfx5110-l2-vxlan-l3-logical.html

I was not able to reproduce with 17.4 but I'll try again with 18.1
tomorrow.
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN-VXLAN: Mixing QFX and EX

[Vincent Bernat]

 ❦ 16 avril 2019 17:32 +00, Ian :

> Much appreciated reply.
>
> My understanding is EVPN-VXLAN uses anycast on all spines. All spines
> would have the same IP address (that is the gateway IP). Considering
> the limitations of the EX4600 you pointed out (which I assume is due
> to the Broadcom chipset), means in a case of mixing EX4600 with
> QFX5110, then the routing between VXLAN could only occur on the spines
> (assuming a QFX5110 or similar model supporting this) which
> effectively means traffic would trombone back and forth from the
> leaves to the spines rather than remain local to the switch even if
> the servers are on neighboring physical ports on the EX4600 leaves.
>
> Am I making right assumptions?

It depends on how you assign subnets to each leaves. For example, if
each leaf gets its own subnet, local traffic would be L2 only and stay
on the EX4600 leaves. On the other hand, if you assign two different
subnets, routing between them will require the traffic to go to the
spine, even if the source and destination are attached to the same leaf.

Also, note that if you plan to use QFX5110 as edge for your VXLAN
network, you may run into the following limitation:

(QFX5110 switches only) By default, routing traffic between a VXLAN and
a Layer 3 logical interface—for example, an interface configured with
the set interfaces interface-name unit logical-unit-number family inet
address ip-address/prefix-length command—is disabled. If this routing
functionality is required in your EVPN-VXLAN network, you can perform
some additional configuration to make it work. For more information, see
Understanding How to Configure VXLANs on QFX5110 Switches and Layer 3
Logical Interfaces to Interoperate.



It means a QFX5110 is not able to route between a family inet interface
and a family ethernet-switching interface when it implies doing VXLAN
encapsulation/decapsulation. QFX10k is able to do that without any
issue. Juniper provides a documented workaround, but it's quite recent.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN-VXLAN: Mixing QFX and EX

[Vincent Bernat]

 ❦ 16 avril 2019 11:04 +00, Ian :

> Thank you, Vincent.
>
> That is weird; it was a very simple layout illustration, I am attaching it 
> again.
>
> Ultimate goal is to reduce broadcast domain size while having the
> resources be able to participate in L2 without over-sizing it and
> without using spanning-tree overheads and its risks.

OK. So, the main question is whatever you are expecting to route between
VXLAN (or between a VXLAN and a VLAN). EX4600 is only able to do L2
stuff with VXLAN. 5110 is able to route between VXLAN and may be able
under some conditions to route between a VLAN and a VXLAN.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)
___
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?

[Vincent Bernat]

 ❦ 15 avril 2019 15:09 +03, Saku Ytti :

>> I'm afraid this is not a valid test to prove the effect of relative process
>> priorities within the RE, doing this you're slowing down the clock on the
>> complete RE simulation as a whole (all simulated processes slowed down
>> equally).
> ..
>
>> Again this could be because these kinds of operations have lower process
>> priority than the process handling ping.
>
> ACK, RPD is involved in ICMP and RIB/FIB management, and to the OS
> it's just single thread (in this context, newer RPD does have few
> separate OS threads). So what you'd need to do, is have RPD run some
> high priority task. BGP churn which will cause FIB changes likely is
> good candidate as way to cause variant delay to ICMP.

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.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN-VXLAN: Mixing QFX and EX

[Vincent Bernat]

I think your attachment has been stripped. Do you plan to have a L3
gateway somewhere? Be sure to read this page to understand what you can
and cannot do with VXLAN on each model:

 
https://www.juniper.net/documentation/en_US/junos/topics/concept/vxlan-constraints-qfx-series.html

Notably:

(QFX5100, QFX5200, QFX5210, EX4300-48MP, and EX4600 switches) Routing
traffic between different VXLANs is not supported.
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Ian via juniper-nsp 
 Sent: 16 avril 2019 05:13 +00
 Subject: [j-nsp] EVPN-VXLAN: Mixing QFX and EX
 To: juniper-nsp

> Experts,
>
> New to Junos, I am currently working on a small network with a
> spine-leaf design that would initially consist of two QFX5110 spine
> and four EX4600 leaf. Each leaf would connect to each spine with two
> 40GbE.
>
> The logical layout representation is as follow, only one link designed for 
> simplicity
>
> [spine_leaf.png]
>
> I have been provided EX4600 for leaf and QFX5110 for spine. I plan on
> using EVPN-VXLAN and wanted to know, except for the large number of
> configuration and need for automation of VXLAN configuration, if
> somebody would see any problem mixing EX4600 and QFX5110 in such
> setup.
>
> Many thanks for feedbacks.
>
> I.
> ___
> 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] Event script to advertise DHCP issued IP in LLDP?

[Vincent Bernat]

 ❦  8 avril 2019 18:25 -07, Matt Peterson :

> In our environment we're using EX2300-C's as 10Gbps NID's for metro
> ethernet use *(meaning they're essentially a managed L2 switch with an
> in-band management IP). *These are configured without an IP address on the
> physical me0 interface, but instead receive an IP via DHCPv4 & v6 as a
> tagged "irb" VLAN interface *(note the dhcp retransmission-attempt,
> -interval, and force-discover options are crucial here - otherwise the unit
> will timeout all DHCP attempts prior to the interface having link up..).*
>
> We're trying to figure out an approach to define the "protocols lldp
> management-address" stanza with the current issued IP address.
> Unfortunately this command only accepts a static defined IP address, not an
> interface name. Upon looking at the possible events for a SLAX or Python
> script, only DHCP serving events exist - not DHCP client *(based off "help
> syslog" listing). *This is probably a feature request, but maybe another
> creative solution is possible? Thanks.

You may run your script on PFE_FW_SYSLOG_IP if you set the appropriate
firewall rule to match on DHCP answer. Your script will be executed
twice as this is not possible to make a difference between a DHCPOFFER
and a DHCPACK just with a family inet filter.
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Event script to advertise DHCP issued IP in LLDP?

[Vincent Bernat]

 ❦  8 avril 2019 18:25 -07, Matt Peterson :

> In our environment we're using EX2300-C's as 10Gbps NID's for metro
> ethernet use *(meaning they're essentially a managed L2 switch with an
> in-band management IP). *These are configured without an IP address on the
> physical me0 interface, but instead receive an IP via DHCPv4 & v6 as a
> tagged "irb" VLAN interface *(note the dhcp retransmission-attempt,
> -interval, and force-discover options are crucial here - otherwise the unit
> will timeout all DHCP attempts prior to the interface having link up..).*
>
> We're trying to figure out an approach to define the "protocols lldp
> management-address" stanza with the current issued IP address.
> Unfortunately this command only accepts a static defined IP address, not an
> interface name. Upon looking at the possible events for a SLAX or Python
> script, only DHCP serving events exist - not DHCP client *(based off "help
> syslog" listing). *This is probably a feature request, but maybe another
> creative solution is possible? Thanks.

Maybe: set interfaces me0 unit 0 family inet unnumbered-address
xe-0/0/0.0 ?
-- 
In the Spring, I have counted 136 different kinds of weather inside of
24 hours.
-- Mark Twain, on New England weather
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN/VXLAN experience

[Vincent Bernat]

 ❦ 22 mars 2019 13:39 -04, Rob Foehl :

> I've got a few really large layer 2 domains that I'm looking to start
> breaking up and stitching back together with EVPN+VXLAN in the middle,
> on the order of a few thousand VLANs apiece.  Trying to plan around
> any likely limitations, but specifics have been hard to come by...

You can find a bit more here:

 - 

 - 

-- 
I fell asleep reading a dull book, and I dreamt that I was reading on,
so I woke up from sheer boredom.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Distributed Mode for IPv6

[Vincent Bernat]

 ❦  2 octobre 2018 23:07 +0200, Mark Tinka :

>> Dunno with IS-IS, but with BGP, BFD is advertised as control plane
>> independent when using public IPv6 addresses. However, I've just noticed
>> that when using an IRB, BFD is handled by the control plane, both for
>> IPv6 and IPv4.
>
> It's clear that whether the BFD session is run in the PFE or the RE has
> a lot to do with how it was learned.

I am unsure if say that about ISIS vs BGP or about the difference
with/without an IRB. If the later, in both cases, it was learnt from a
BGP session. The only difference between the two setups is the local IP
of the BGP session is on an IRB interface.
-- 
The only way to keep your health is to eat what you don't want, drink what
you don't like, and do what you'd rather not.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Distributed Mode for IPv6

[Vincent Bernat]

 ❦  2 octobre 2018 20:13 +0100, James Bensley :

>> > Not exactly your scenario but we had the same problems with eBGP with
>> > IPv6 link-local addresses on QFX10K platform.
>> > Dev Team had replied that rather than hardware limitation it's more of
>> > a "design decision" to not distribute IPv6 LL BFD sessions on PFEs,
>> > it's the same behaviour across the MX/QFX/PTX portfolio and there are
>> > no plans to change it.
>
> I'd be interested to know if BFD works OK if you use public IPv6
> addresses for IS-IS adjacencies (although it's a waste of IPs, I'd
> still be curious).

Dunno with IS-IS, but with BGP, BFD is advertised as control plane
independent when using public IPv6 addresses. However, I've just noticed
that when using an IRB, BFD is handled by the control plane, both for
IPv6 and IPv4.
-- 
The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Vincent Bernat]

 ❦ 11 juillet 2018 18:17 GMT, Drew Weaver  :

> Is there a list of best practices or 'things to think about' when
> constructing a firewall filter for a loopback on an MX series router
> running version 15 of Junos?
>
> I'm slowly piecing it together by just 'seeing what is broken next'
> and I have found some issue specific examples on Juniper.net thus far
> that tend to help with some of the issues but if anyone has ever seen
> a decent comprehensive guide that would be tremendously useful.
>
> If anyone has seen anything like this let me know, if not no worries
> will just keep fixing the things one by one =)

There is a "Day One: Securing the Routing Engine" [0] about that. It is
missing IPv6 which is present in the O'Reilly book about the MX.

[0]: http://www.hiphop-resistance.com/juniperdayone/Securing_RouteEngine2.pdf
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX480

[Vincent Bernat]

 ❦ 17 juin 2018 12:05 +0200, Sebastian Becker  :

> 16.1R7 is a golden release.

Is it already released? Not listed here:
 https://www.juniper.net/support/downloads/?p=mx480#sw

Is 16.1R6-S4 considered almost equivalent?
-- 
The fashion wears out more apparel than the man.
-- William Shakespeare, "Much Ado About Nothing"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 ballpark

[Vincent Bernat]

 ❦ 27 mai 2018 13:24 +0700, Mark Tees  :

> Not sure if it’s licensed on FIB usage but I’m trying to gain an idea on
> both full table and partial table options.

For full FIB (or RIB?), you need the S-MX104-ADV-R2 license whose public
price is 2. However, the limitation is not enforced (you cannot even
add the license to the system, it's just a piece of paper). This kind of
license limitation doesn't exist with the MX80 (or with any other MX
from the same era). This license can be part of a bundle (you should
definitely look at bundles for the MX104, the pricing doesn't make much
sense). If you buy it separately, Juniper easily does at least 30% on
licenses. Personnally, I wouldn't pay anything for such a license since
the MX104 slow routing engine is unable to handle an Internet-sized FIB
without important downtimes during changes (1-2 minutes). You'll have to
select the routes you install in FIB if you want to minimize impacts
during changes and you'll need to be below the licensing limit (256k
routes I think).

I can't say anything about current pricing because I've bought mine more
than 3 years ago, but you should also consider if a MX204 or a MX150
would fit your needs. The routing engines are far more capable on these
(but they are a fixed chassis with only one routing engine).
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Managing large route-filter-lists

[Vincent Bernat]

 ❦ 22 mai 2018 08:48 +0200, Pavel Lunin  :

> Anyone knows if this "ephemeral configuration" thing is just a new fancy
> hipster-ish name of the dynamic database feature, which has been in JUNOS
> since 9.x and never really been widely used in production by normal
> people?

Documentation says it needs JunOS 16.2R2.
-- 
The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Managing large route-filter-lists

[Vincent Bernat]

 ❦ 21 mai 2018 14:51 -0400, Brian Rak  :

> We switched this over to using ephemeral configs:
> https://www.juniper.net/documentation/en_US/junos/topics/concept/ephemeral-configuration-database-overview.html
>
> This seems to have dramatically reduced configuration time (at the
> expense of being slightly less clear).
>
> It also has the bonus that our IRR filters no longer show up in the
> main configuration, and 'show | compare' is back to being fast again.
>
> The downside seems to be that these can blow up the router somehow...
> there's a big warning about it in the py-ez code:
> https://github.com/Juniper/py-junos-eznc/blob/master/lib/jnpr/junos/utils/config.py#L750

There are also some warnings about use with GRES and NSR. They explain a
bit about GRES, but they don't say what's wrong with NSR. For IRR, it
seems that if the static database contains an "allow all" and the
ephemeral database contains the IRR filter, you should be good. Did you
get Juniper to confirm your use case is correct?
-- 
"Not Hercules could have knock'd out his brains, for he had none."
-- Shakespeare
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX 5100 and vlan rewriting

[Vincent Bernat]

Hello Jonathan,

Thanks for your answer. With "inner-vlan-id-list", I get:

## Warning: 'inner-vlan-id-list' can be used only on interface with 
vlan-id/vlan-tags
## Warning: 'inner-vlan-id-list' is supported only on 
flexible-vlan-tagging mode

While the documentation says I should choose between
flexible-vlan-tagging and interface-mode trunk, adding
flexible-vlan-tagging fix the second warning. However, I am puzzled at
which vlan-id I should be using at the IFL level. I am not using QinQ.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Jonathan Call <lordsit...@hotmail.com>
 Sent: 17 mai 2018 14:30 GMT
 Subject: Re: [j-nsp] QFX 5100 and vlan rewriting
 To: Vincent Bernat; juniper-nsp@puck.nether.net

> Use the inner-vlan-id-list option:
>
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/vlan-translation-vlan-id-list-l2.html
>
> Jonathan
>
>
>
>
>
> From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> on behalf of Vincent 
> Bernat <ber...@luffy.cx>
> Sent: Thursday, May 17, 2018 3:17 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] QFX 5100 and vlan rewriting
>   
>
> Hey!
>
> I am a bit puzzled how to do VLAN rewriting with the QFX5100. With a MX,
> the following configuration would work:
>
> interfaces {
>  xe-0/0/0 {
>   unit 0 {
>    family bridge {
>     interface-mode trunk;
>     vlan-id-list [ 57 58 ];
>     vlan-rewrite {
>   translate 3 57;
>   translate 4 58;
>     }
>    }
>   }
>  }
> }
>
> With a QFX5100, running 17.4, there is no "vlan-id-list" under "family
> ethernet-switching" (but there is "inner-vlan-id-list" and there is
> "vlan-id-list" outside "family ethernet-switching"). If I don't specify
> anything, I get an error message saying to use "vlan members". However,
> the following configuration does not translate VLANs:
>
> interfaces {
>  xe-0/0/0 {
>   unit 0 {
>    family ethernet-switching {
>     interface-mode trunk;
>     vlan members [ vlan-57 vlan-58 ];
>     vlan-rewrite {
>   translate 3 57;
>   translate 4 58;
>     }
>    }
>   }
>  }
> }
> vlans {
>  vlan-57 vlan-id 57;
>  vlan-58 vlan-id 58;
> }
>
> Am I doing something wrong? Thanks!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] QFX 5100 and vlan rewriting

[Vincent Bernat]

Hey!

I am a bit puzzled how to do VLAN rewriting with the QFX5100. With a MX,
the following configuration would work:

interfaces {
 xe-0/0/0 {
  unit 0 {
   family bridge {
interface-mode trunk;
vlan-id-list [ 57 58 ];
vlan-rewrite {
  translate 3 57;
  translate 4 58;
}
   }
  }
 }
}

With a QFX5100, running 17.4, there is no "vlan-id-list" under "family
ethernet-switching" (but there is "inner-vlan-id-list" and there is
"vlan-id-list" outside "family ethernet-switching"). If I don't specify
anything, I get an error message saying to use "vlan members". However,
the following configuration does not translate VLANs:

interfaces {
 xe-0/0/0 {
  unit 0 {
   family ethernet-switching {
interface-mode trunk;
vlan members [ vlan-57 vlan-58 ];
vlan-rewrite {
  translate 3 57;
  translate 4 58;
}
   }
  }
 }
}
vlans {
 vlan-57 vlan-id 57;
 vlan-58 vlan-id 58;
}

Am I doing something wrong? Thanks!
-- 
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP

[Vincent Bernat]

Hey!

Some update which may be useful to future readers.

I had to add back the "ingress-node-replication" to the
vlans. Otherwise, when a VNI has more than a handful VTEPs (30 in my
case), replication doesn't seem to be done at all.

I have also hit another surprising limitation: the outer MAC address for
remote VTEP was wrong (same MAC address for all VTEP, despite the
next-hop database on both FPCs being correct) when not doing replication
(it was correct for broadcast packets). I am using external loopback
cables with a separate instance for routing to workaround the
issue. This is not pretty, but it is OK for my use case.

I am using the QFX5100 in a virtual-chassis (cannot use BGP EVPN type-1
routes due to interoperability issues). Maybe this is the source of the
problems (as this is not an usual setup to run BGP EVPN on). I am
currently on 17.4R1-S2.2. rpd on 14.1X53-D46.7 was crashing when I added
more remote VTEPs. Didn't had any other difference from 15.1 to 18.1.
-- 
If you tell the truth you don't have to remember anything.
-- Mark Twain

 ――― Original Message ―――
 From: Nitzan Tzelniker <nitzan.tzelni...@gmail.com>
 Sent: 11 avril 2018 21:02 GMT
 Subject: Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP
 To: Vincent Bernat
 Cc: juniper-nsp@puck.nether.net

> Try to remove the  "ingress-node-replication" from the vlans and add " set
> protocols evpn multicast-mode ingress replication "
> few months ago a TAC engineer told it to me
>
> "This knob will add all the remote VTEPs under the VNIs on local device
> even though the remote devices do not have these VNIs configured. This
> causes unnecessary flooding from local device to the remote."
>
> But to be honest I didn't check it yet
>
> Thanks
>
> Nitzan
>
> On Tue, Apr 10, 2018 at 12:42 PM Vincent Bernat <ber...@luffy.cx> wrote:
>
>> Hey!
>>
>> I am noticing an odd behaviour when using BGP EVPN on a vQFX: it assumes
>> that all VTEP have all the local VNIs. For example, on the local system,
>> I have VNI 654, 655 and 656. However, on the remote VTEP, I have only
>> 654 and 655. However, the local system still assumes VNI 656 should be
>> present:
>>
>> juniper@QFX1> show version
>> fpc0:
>> --
>> Hostname: QFX1
>> Model: vqfx-1
>> Junos: 17.4R1.16 limited
>> JUNOS Base OS boot [17.4R1.16]
>> JUNOS Base OS Software Suite [17.4R1.16]
>> JUNOS Crypto Software Suite [17.4R1.16]
>> JUNOS Online Documentation [17.4R1.16]
>> JUNOS Kernel Software Suite [17.4R1.16]
>> JUNOS Packet Forwarding Engine Support (qfx-10-f) [17.4R1.16]
>> JUNOS Routing Software Suite [17.4R1.16]
>> JUNOS jsd [i386-17.4R1.16-jet-1]
>> JUNOS SDN Software Suite [17.4R1.16]
>> JUNOS Enterprise Software Suite [17.4R1.16]
>> JUNOS Web Management [17.4R1.16]
>> JUNOS py-base-i386 [17.4R1.16]
>> JUNOS py-extensions-i386 [17.4R1.16]
>>
>> {master:0}
>> juniper@QFX1> show ethernet-switching vxlan-tunnel-end-point remote
>> Logical System Name   Id  SVTEP-IP IFL   L3-Idx
>>  0   192.0.2.11   lo0.00
>>  RVTEP-IP IFL-Idx   NH-Id
>>  192.0.2.13   570   1749
>> VNID  MC-Group-IP
>> 656   0.0.0.0
>> 655   0.0.0.0
>> 654   0.0.0.0
>>
>> {master:0}
>> juniper@QFX1> show route table default-switch.evpn.0
>>
>> default-switch.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown,
>> 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 1:192.0.2.11:1::010101010101010101::0/192 AD/EVI
>>*[EVPN/170] 00:03:49
>>   Indirect
>> 2:192.0.2.11:1::654::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:02:43
>>   Indirect
>> 2:192.0.2.11:1::655::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:01:20
>>   Indirect
>> 2:192.0.2.11:1::656::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:03:54
>>   Indirect
>> 2:192.0.2.13:1::654::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:41, localpref 100, from 192.0.2.100
>>   AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 2:192.0.2.13:1::655::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:04, localpref 100, from 192.0.2.100
>>   AS path: I, validation-state: unverified
>>   

Re: [j-nsp] MX104 and NetFlow - Any horror story to share?

[Vincent Bernat]

 ❦  1 mai 2018 14:30 GMT, Michael Hare  :

> chassis {
> afeb {
> slot 0 {
> inline-services {
> flow-table-size {
> ipv4-flow-table-size 7;
> ipv6-flow-table-size 7;
> }
> }
> }
> }
> }

On 15.1R6, I am using this without any issue:

   afeb {
slot 0 {
inline-services {
flow-table-size {
ipv4-flow-table-size 10;
ipv6-flow-table-size 5;
}
}
}
}
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP

[Vincent Bernat]

Hi Nitzan!

I already had the second bit. I've removed the
"ingress-node-replication" from "vlans", like you suggested and it works
as expected. Thanks!
-- 
A banker is a fellow who lends you his umbrella when the sun is shining
and wants it back the minute it begins to rain.
-- Mark Twain

 ――― Original Message ―――
 From: Nitzan Tzelniker <nitzan.tzelni...@gmail.com>
 Sent: 11 avril 2018 21:02 GMT
 Subject: Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP
 To: Vincent Bernat
 Cc: juniper-nsp@puck.nether.net

> Try to remove the  "ingress-node-replication" from the vlans and add " set
> protocols evpn multicast-mode ingress replication "
> few months ago a TAC engineer told it to me
>
> "This knob will add all the remote VTEPs under the VNIs on local device
> even though the remote devices do not have these VNIs configured. This
> causes unnecessary flooding from local device to the remote."
>
> But to be honest I didn't check it yet
>
> Thanks
>
> Nitzan
>
> On Tue, Apr 10, 2018 at 12:42 PM Vincent Bernat <ber...@luffy.cx> wrote:
>
>> Hey!
>>
>> I am noticing an odd behaviour when using BGP EVPN on a vQFX: it assumes
>> that all VTEP have all the local VNIs. For example, on the local system,
>> I have VNI 654, 655 and 656. However, on the remote VTEP, I have only
>> 654 and 655. However, the local system still assumes VNI 656 should be
>> present:
>>
>> juniper@QFX1> show version
>> fpc0:
>> --
>> Hostname: QFX1
>> Model: vqfx-1
>> Junos: 17.4R1.16 limited
>> JUNOS Base OS boot [17.4R1.16]
>> JUNOS Base OS Software Suite [17.4R1.16]
>> JUNOS Crypto Software Suite [17.4R1.16]
>> JUNOS Online Documentation [17.4R1.16]
>> JUNOS Kernel Software Suite [17.4R1.16]
>> JUNOS Packet Forwarding Engine Support (qfx-10-f) [17.4R1.16]
>> JUNOS Routing Software Suite [17.4R1.16]
>> JUNOS jsd [i386-17.4R1.16-jet-1]
>> JUNOS SDN Software Suite [17.4R1.16]
>> JUNOS Enterprise Software Suite [17.4R1.16]
>> JUNOS Web Management [17.4R1.16]
>> JUNOS py-base-i386 [17.4R1.16]
>> JUNOS py-extensions-i386 [17.4R1.16]
>>
>> {master:0}
>> juniper@QFX1> show ethernet-switching vxlan-tunnel-end-point remote
>> Logical System Name   Id  SVTEP-IP IFL   L3-Idx
>>  0   192.0.2.11   lo0.00
>>  RVTEP-IP IFL-Idx   NH-Id
>>  192.0.2.13   570   1749
>> VNID  MC-Group-IP
>> 656   0.0.0.0
>> 655   0.0.0.0
>> 654   0.0.0.0
>>
>> {master:0}
>> juniper@QFX1> show route table default-switch.evpn.0
>>
>> default-switch.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown,
>> 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 1:192.0.2.11:1::010101010101010101::0/192 AD/EVI
>>*[EVPN/170] 00:03:49
>>   Indirect
>> 2:192.0.2.11:1::654::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:02:43
>>   Indirect
>> 2:192.0.2.11:1::655::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:01:20
>>   Indirect
>> 2:192.0.2.11:1::656::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:03:54
>>   Indirect
>> 2:192.0.2.13:1::654::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:41, localpref 100, from 192.0.2.100
>>   AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 2:192.0.2.13:1::655::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:04, localpref 100, from 192.0.2.100
>>   AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 3:192.0.2.11:1::654::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:08
>>   Indirect
>> 3:192.0.2.11:1::655::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:07
>>   Indirect
>> 3:192.0.2.11:1::656::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:07
>>   Indirect
>> 3:192.0.2.13:1::654::192.0.2.13/248 IM
>>*[BGP/170] 00:03:55, localpref 100, from 192.0.2.100
>>   AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 3:192.0.2.13:1::655::192.0.2.

[j-nsp] VXLAN, BGP EVPN, remote VTEP

[Vincent Bernat]

Hey!

I am noticing an odd behaviour when using BGP EVPN on a vQFX: it assumes
that all VTEP have all the local VNIs. For example, on the local system,
I have VNI 654, 655 and 656. However, on the remote VTEP, I have only
654 and 655. However, the local system still assumes VNI 656 should be
present:

juniper@QFX1> show version
fpc0:
--
Hostname: QFX1
Model: vqfx-1
Junos: 17.4R1.16 limited
JUNOS Base OS boot [17.4R1.16]
JUNOS Base OS Software Suite [17.4R1.16]
JUNOS Crypto Software Suite [17.4R1.16]
JUNOS Online Documentation [17.4R1.16]
JUNOS Kernel Software Suite [17.4R1.16]
JUNOS Packet Forwarding Engine Support (qfx-10-f) [17.4R1.16]
JUNOS Routing Software Suite [17.4R1.16]
JUNOS jsd [i386-17.4R1.16-jet-1]
JUNOS SDN Software Suite [17.4R1.16]
JUNOS Enterprise Software Suite [17.4R1.16]
JUNOS Web Management [17.4R1.16]
JUNOS py-base-i386 [17.4R1.16]
JUNOS py-extensions-i386 [17.4R1.16]

{master:0}
juniper@QFX1> show ethernet-switching vxlan-tunnel-end-point remote
Logical System Name   Id  SVTEP-IP IFL   L3-Idx
 0   192.0.2.11   lo0.00
 RVTEP-IP IFL-Idx   NH-Id
 192.0.2.13   570   1749
VNID  MC-Group-IP
656   0.0.0.0
655   0.0.0.0
654   0.0.0.0

{master:0}
juniper@QFX1> show route table default-switch.evpn.0

default-switch.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 
hidden)
+ = Active Route, - = Last Active, * = Both

1:192.0.2.11:1::010101010101010101::0/192 AD/EVI
   *[EVPN/170] 00:03:49
  Indirect
2:192.0.2.11:1::654::50:54:33:00:00:0f/304 MAC/IP
   *[EVPN/170] 00:02:43
  Indirect
2:192.0.2.11:1::655::50:54:33:00:00:0f/304 MAC/IP
   *[EVPN/170] 00:01:20
  Indirect
2:192.0.2.11:1::656::50:54:33:00:00:0f/304 MAC/IP
   *[EVPN/170] 00:03:54
  Indirect
2:192.0.2.13:1::654::50:54:33:00:00:11/304 MAC/IP
   *[BGP/170] 00:02:41, localpref 100, from 192.0.2.100
  AS path: I, validation-state: unverified
> to 203.0.113.13 via xe-0/0/0.0
2:192.0.2.13:1::655::50:54:33:00:00:11/304 MAC/IP
   *[BGP/170] 00:02:04, localpref 100, from 192.0.2.100
  AS path: I, validation-state: unverified
> to 203.0.113.13 via xe-0/0/0.0
3:192.0.2.11:1::654::192.0.2.11/248 IM
   *[EVPN/170] 00:04:08
  Indirect
3:192.0.2.11:1::655::192.0.2.11/248 IM
   *[EVPN/170] 00:04:07
  Indirect
3:192.0.2.11:1::656::192.0.2.11/248 IM
   *[EVPN/170] 00:04:07
  Indirect
3:192.0.2.13:1::654::192.0.2.13/248 IM
   *[BGP/170] 00:03:55, localpref 100, from 192.0.2.100
  AS path: I, validation-state: unverified
> to 203.0.113.13 via xe-0/0/0.0
3:192.0.2.13:1::655::192.0.2.13/248 IM
   *[BGP/170] 00:03:55, localpref 100, from 192.0.2.100
  AS path: I, validation-state: unverified
> to 203.0.113.13 via xe-0/0/0.0

The remote system, 192.0.2.13 (also a vQFX), never send anything that
would hint it can handle VNI 656. I have also verified by sniffing on
the wire that the remote system is in fact receiving VXLAN packets for
VNI 656:

Frame 807: 106 bytes on wire (848 bits), 106 bytes captured (848 bits)
Ethernet II, Src: MS-NLB-PhysServer-05_86:71:7e:03 (02:05:86:71:7e:03), Dst: 
MS-NLB-PhysServer-05_86:71:69:03 (02:05:86:71:69:03)
Internet Protocol Version 4, Src: 192.0.2.11, Dst: 192.0.2.13
User Datagram Protocol, Src Port: 3471, Dst Port: 4789
Virtual eXtensible Local Area Network
Flags: 0x0800, VXLAN Network ID (VNI)
Group Policy ID: 0
VXLAN Network Identifier (VNI): 656
Reserved: 0
Ethernet II, Src: 50:54:33:00:00:0f (50:54:33:00:00:0f), Dst: Broadcast 
(ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

My BGP EVPN configuration is pretty simple and I rely on auto RT:

protocols {
bgp {
group evpn {
type internal;
multipath;
multihop;
family evpn signaling;
}
}
evpn {
encapsulation vxlan;
extended-vni-list all;
multicast-mode ingress-replication;
}
}

switch-options {
vtep-source-interface lo0.0;
vrf-import EVPN-VRF-VXLAN;
vrf-target {
target:65000:1;
auto;
}
}
policy-options {
policy-statement EVPN-VRF-VXLAN {
then accept;
}
}
vlans {
vlan-client1-654 {
vlan-id 654;
vxlan {
vni 654;
ingress-node-replication;
}
}
vlan-client1-655 {
vlan-id 655;
vxlan {
vni 655;
ingress-node-replication;
}
}
vlan-client1-656 {

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

 ❦ 29 mars 2018 15:36 +0100,  :

> Ok so you have the FIB level load-sharing enabled 
> Do you have BGP multipath configured with the multiple-as option too?
> set protocols bgp group foo123 multipath multiple-as
>
> -Though from the outputs it seem like everything is set up right.
> You have the same metric2 (cause ebgp) so should be fine.
> And the next-hop is copied form the inactive route to active one.

I am using iBGP, so everything comes from the same AS. Each neighbor is
a route reflector distributing a distinct set of routes. I have tried to
add multiple-as nonetheless, but no change.

The good news is that half of the VTEP are using one next-hop and the
other half the others one. If I put down a BGP session and back, the
next hops are still distributed over the sets of VTEP. This is not
ideal, but this enough for my situation.
-- 
Go not to the elves for counsel, for they will say both yes and no.
-- J.R.R. Tolkien
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

 ❦ 29 mars 2018 13:40 +0200, Sebastian Wiesinger  :

>> vbe@net-connect001.gv2> show route 10.16.39.3 extensive
>> 
>> inet.0: 236 destinations, 908 routes (236 active, 0 holddown, 0 hidden)
>> 10.16.39.3/32 (4 entries, 1 announced)
>> TSI:
>> KRT in-kernel 10.16.39.3/32 -> {list:indirect(131094), indirect(131205)}
>> *BGPPreference: 140/-501
>> Next hop type: Indirect, Next hop index: 0
>> Address: 0xb21c210
>> Next-hop reference count: 3
>> Source: 10.64.0.5
>> Next hop type: Router, Next hop index: 1885
>> Next hop: 10.64.0.23 via xe-0/0/46.181
>> Session Id: 0x0
>> Next hop type: Router, Next hop index: 1767
>> Next hop: 10.64.128.23 via xe-1/0/47.183, selected
>> Session Id: 0x0
>> Protocol next hop: 10.64.0.23
>> Indirect next hop: 0xc5ceb00 131205 INH Session ID: 0x0
>> Protocol next hop: 10.64.128.23
>> Indirect next hop: 0xc5b8780 131094 INH Session ID: 0x0
>
> Interesting, which JunOS version is that? It looks slightly different
> here:
>
> root@storage-leaf-1# run show route 172.16.0.11/32 extensive 
>
> inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
> 172.16.0.11/32 (1 entry, 1 announced)
> TSI:
> KRT in-kernel 172.16.0.11/32 -> {list:172.17.1.0, 172.17.2.0}
> *IS-IS  Preference: 18
> Level: 2
> Next hop type: Router, Next hop index: 0
> Address: 0xb21c290
> Next-hop reference count: 5
> Next hop: 172.17.1.0 via et-0/0/48.0 weight 0x1, selected
> Session Id: 0x0
> Next hop: 172.17.2.0 via et-0/0/49.0 weight 0x1
> Session Id: 0x0
> State: 

This is:

Model: qfx5100-48s-6q
Junos: 17.3R2.10

Maybe because this is a route learnt from a route reflector?
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

 ❦ 29 mars 2018 12:22 +0200, Sebastian Wiesinger  :

>> # run show route 10.16.39.3
>> 
>> inet.0: 240 destinations, 1808 routes (240 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>> 
>> 10.16.39.3/32  *[BGP/140] 00:38:24, localpref 500, from 10.64.0.5
>>   AS path: I, validation-state: unverified
>>   to 10.64.0.23 via xe-0/0/46.181
>> > to 10.64.128.23 via xe-0/0/47.183
>
> Can you do a 'run show route 10.16.39.3 extensive'?

Here is the full output. There are two selected paths (and two
additional paths which are not used due to lower preference).

vbe@net-connect001.gv2> show route 10.16.39.3 extensive

inet.0: 236 destinations, 908 routes (236 active, 0 holddown, 0 hidden)
10.16.39.3/32 (4 entries, 1 announced)
TSI:
KRT in-kernel 10.16.39.3/32 -> {list:indirect(131094), indirect(131205)}
*BGPPreference: 140/-501
Next hop type: Indirect, Next hop index: 0
Address: 0xb21c210
Next-hop reference count: 3
Source: 10.64.0.5
Next hop type: Router, Next hop index: 1885
Next hop: 10.64.0.23 via xe-0/0/46.181
Session Id: 0x0
Next hop type: Router, Next hop index: 1767
Next hop: 10.64.128.23 via xe-1/0/47.183, selected
Session Id: 0x0
Protocol next hop: 10.64.0.23
Indirect next hop: 0xc5ceb00 131205 INH Session ID: 0x0
Protocol next hop: 10.64.128.23
Indirect next hop: 0xc5b8780 131094 INH Session ID: 0x0
State: 
Local AS: 65199 Peer AS: 65098
Age: 2:15:52Metric2: 0
Validation State: unverified
Task: BGP_65098_65098.10.64.0.5
Announcement bits (4): 0-KRT 2-BGP_Listen.0.0.0.0+179 4-Resolve 
tree 2 6-Resolve tree 3
AS path: I (Originator)
Cluster list:  10.64.0.0
Originator ID: 100.64.0.23
Accepted Multipath
Localpref: 500
Router ID: 10.64.0.5
Indirect next hops: 2
Protocol next hop: 10.64.0.23
Indirect next hop: 0xc5ceb00 131205 INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.64.0.23 via xe-0/0/46.181
Session Id: 0x0
10.64.0.0/18 Originating RIB: inet.0
  Node path count: 1
  Forwarding nexthops: 1
Next hop type: Interface
Nexthop: via xe-0/0/46.181
Protocol next hop: 10.64.128.23
Indirect next hop: 0xc5b8780 131094 INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.64.128.23 via xe-1/0/47.183
Session Id: 0x0
10.64.128.0/18 Originating RIB: inet.0
  Node path count: 1
  Forwarding nexthops: 1
Next hop type: Interface
Nexthop: via xe-1/0/47.183
 BGPPreference: 140/-501
Next hop type: Indirect, Next hop index: 0
Address: 0xb3a3730
Next-hop reference count: 2
Source: 10.64.128.4
Next hop type: Router, Next hop index: 1767
Next hop: 10.64.128.23 via xe-1/0/47.183, selected
Session Id: 0x0
Protocol next hop: 10.64.128.23
Indirect next hop: 0xc5b8780 131094 INH Session ID: 0x0
State: 
Inactive reason: Not Best in its group - Cluster list length
Local AS: 65199 Peer AS: 65098
Age: 2:16:00Metric2: 0
Validation State: unverified
Task: BGP_65098_65098.10.64.128.4
AS path: I (Originator)
Cluster list:  10.64.128.1 10.64.128.0
Originator ID: 100.64.0.23
Accepted MultipathContrib
Localpref: 500
Router ID: 10.64.128.4
Indirect next hops: 1
Protocol next hop: 10.64.128.23
Indirect next hop: 0xc5b8780 131094 INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.64.128.23 via xe-1/0/47.183
Session Id: 0x0

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

 ❦ 29 mars 2018 02:08 GMT, Nikolas Geyer  :

> As someone else has mentioned are you sure you have per-packet load
> balancing policy exported in forwarding-options for all protocols?

What do you mean by "all protocols"? I just have:

set routing-options forwarding-table export loadbalance
set policy-options policy-statement loadbalance then load-balance per-packet

I have nothing in "forwarding-options".
-- 
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

So, after trying 17.3R2 and 14.1X53-D63, I have the same behavior with
17.3 and rpd is crashing with 14.1X53.

I have also looked at what the FPC thinks, but I am unsure how the
lookup is done:

TFXPC0(net-connect001.gv2 vty)# show l2 manager mac-table detail

[...]
route table name   : default-switch.4

  mac counters
maximum   count
0   3

 mac address  0a:e3:40:00:00:d9
 bd_index 3
 learn vlan   0
 FwdEntry Addr0x297ee932
 entry flags  0x14
 need sync flag   False
 retry count  0
 In ifl list, In RTT Table
 entry iflvtep.32769
 entry hw ifl vtep.32769
 entry seq number 0
 entry epoch  0
 stp_index0
 hardware information
 
pfe id  0
[...]

TFXPC0(net-connect001.gv2 vty)# show interfaces vtep.32769
 Completes command
statisticsInterface statistics
targeting Show ae link targeting

TFXPC0(net-connect001.gv2 vty)# show interfaces vtep.32769

Logical interface vtep.32769 (Index 570, Alias-Index 0 Peer-Index 0 ifl address 
0x297ee478)
Channel Mode DISABLED (channel1 6  channel2 0)
  Flags: (0x8000) Up SNMP-Traps
  GEN Flags: (0x)
Addresses:
  Media address: Family: Unspecified (0), Chan: 0, Length: 0
IRB ifl BD index 65535
VTEP IP address 10.16.39.3
VTEP L2 RTT index 4
VTEP L3 RTT index 0
VTEP interface type (remote)
Vxlan encapsulation NH id 0
VTEP flags 0x0x0
Reroute Ref: 0, Restore Ref: 0, LRID: 0
Residue Stats in: 0 out: 0
Protocols:
  Protocol: BRIDGE, MTU: 65535 bytes, TCP MSS 0 bytes, Flags: 
0x01400c00, Route table: 4
Maximum labels: 0
Mesh-group index: 0
Input filter: 0, Output filter: 0, Interface class: 0, Dialer Filter: 0
Input Simple Filter: 0, Output Simple Filter: 0
Input implicit filters: None
Output implicit filters: None
L2 Input policer: 0, L2 Output policer: 0
Input policer: 0, Output policer: 0
RPF fail-filter: 0, Reroute Ref: 0, Restore Ref: 0
STP Index: 0, Unicast nh_id: 0, Unicast Token: 98
L2 IFF multi BD : 1, Forwarding Nexthop : 0, Flags 0x0
Media:
  Type: VxLAN End Point, Encapsulation: Ethernet (0x000E)
  MTU: 4294967295 bytes, Flags: 0x
Dependencies:
  Parent ifl index: 570
Storm control:
  BC: 0, UC: 0, Flags: 0x1
Creation time: Mar 29 08:40:19 2018

So, from here, I don't know where to go.

TFXPC0(net-connect001.gv2 vty)# show route ip prefix 10.16.39.3

IPv4 Route Table 0, default.0, 0x8:
Destination   NH IP Addr  Type NH ID Interface
- ---  - -
10.16.39.3 Unilist 131332 RT-ifl 0

[...]

IPv4 Route Table 7, :vxlan.7, 0x0:
Destination   NH IP Addr  Type NH ID Interface
- ---  - -
10.16.39.310.64.128.23Indirect 131457 RT-ifl 0 
xe-1/0/47.183 ifl 566


So, if it uses the table 7, there is only one next-hop. If it uses the
table 0, there are two hops.

TFXPC0(net-connect001.gv2 vty)# show nhdb id 131457 extensive
   ID  Type  InterfaceNext Hop AddrProtocol   Encap MTU 
  Flags  PFE internal Flags
-    -  ---  --     
 --  --
131457  Indirect  xe-1/0/47.183  -  IPv4  Ethernet 
0  0x  0x

BFD Session Id: 0
Indirect Target:
 (no-jtree)
   ID  Type  InterfaceNext Hop AddrProtocol   Encap MTU 
  Flags  PFE internal Flags
-    -  ---  --     
 --  --
 1767   Unicast  xe-1/0/47.183  10.64.128.23   IPv4  Ethernet 0 
 0x  0x

  Routing-table id: 0

-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Nitzan Tzelniker <nitzan.tzelni...@gmail.com>
 Sent: 28 mars 2018 19:44 GMT
 Subject: Re: [j-nsp] BGP EVPN, VXLAN and ECMP
 To: ber...@luffy.cx
 Cc: juniper-nsp@puck.nether.net

> Not sure I understand you but both can run 17.3R2 (just time of
> installation )
>
>
> On Wed, Mar 28, 2018 at 10:16 PM Vincent Bernat <ber...@luffy.cx> wrote:
>
>>  ❦ 28 mars 2018 19:06 GMT, Nitzan Tzelniker <nitzan.tzelni...@gmail.com> :
>>
>> > The 5100 run 15.1X53-D63 and the 5110 17.3R2
>>
>> Do you mean the other way around? No 15.1X53 for the 5100.
>> --
>> Use statement labels that mean something.
>> - The Elements of Programming Style (Kernighan & Plauger)
>>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

 ❦ 28 mars 2018 19:06 GMT, Nitzan Tzelniker  :

> The 5100 run 15.1X53-D63 and the 5110 17.3R2

Do you mean the other way around? No 15.1X53 for the 5100.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

Thanks!

I'll try with 15.1X53 too.
-- 
For courage mounteth with occasion.
-- William Shakespeare, "King John"

 ――― Original Message ―――
 From: Nitzan Tzelniker <nitzan.tzelni...@gmail.com>
 Sent: 28 mars 2018 19:06 GMT
 Subject: Re: [j-nsp] BGP EVPN, VXLAN and ECMP
 To: ber...@luffy.cx
 Cc: juniper-nsp@puck.nether.net

> Yes I have two routes in vxlan.inet.0
>
> nitzan@qfx5100> show route 10.111.44.222
>
> inet.0: 111 destinations, 111 routes (111 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 10.111.44.222/32*[OSPF/10] 1w5d 21:39:34, metric 4
> > to 10.111.33.99 via et-0/0/48.0
>   to 10.111.33.100 via et-0/0/49.0
>
> :vxlan.inet.0: 77 destinations, 77 routes (77 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 10.111.44.222/32*[Static/1] 1w1d 01:48:50, metric2 4
> > to 10.111.33.99 via et-0/0/48.0
>   to 10.111.33.100 via et-0/0/49.0
>
>
> The 5100 run 15.1X53-D63 and the 5110 17.3R2
>
> Nitzan
>
>
> On Wed, Mar 28, 2018 at 9:54 PM Vincent Bernat <ber...@luffy.cx> wrote:
>
>> Hey!
>>
>> Which version of JunOS are you running? I am on 17.4R1. I see that
>> 18.1R1 was just released, I may try it tomorrow. Do you also have
>> a :vxlan.inet.0 table and does it show two paths too?
>>
>> In my configuration, I have:
>>
>> set routing-options forwarding-table export loadbalance
>> set policy-options policy-statement loadbalance then load-balance
>> per-packet
>> set protocols bgp group v4-UNDERLAY multipath
>> set protocols bgp group v4-EVPN multipath
>>
>> The PDF document is helpful. It says:
>>
>> > The QFX5100/QFX5110 can only install VTEP next hops in the PFE; it
>> > cannot install ESI next hops. This means that, for any given overlay
>> > destination, only one remote VTEP can be selected. To send traffic to
>> > the selected VTEP, traffic can be load balanced at the underlay layer
>> > through the two spine nodes.
>>
>> I need to do more tests, as the other provided commands may hint this is
>> just a display issue.
>> --
>> The lunatic, the lover, and the poet,
>> Are of imagination all compact...
>> -- Wm. Shakespeare, "A Midsummer Night's Dream"
>>
>>  ――― Original Message ―――
>>  From: Nitzan Tzelniker <nitzan.tzelni...@gmail.com>
>>  Sent: 28 mars 2018 18:36 GMT
>>  Subject: Re: [j-nsp] BGP EVPN, VXLAN and ECMP
>>  To: ber...@luffy.cx
>>  Cc: juniper-nsp@puck.nether.net
>>
>> > Hi,
>> >
>> > Just check with 5110 and 5100 and on both I see two next hops
>> > but I am using OSPF for the underlay
>> > I think that you have multipath under BGP from the fact that we see two
>> > paths under inet.0 but do you have forwarding-table policy with
>> > "load-balance per-packet" ?
>> >
>> > BTW take a look here
>> >
>> https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/lb-evpn-vxlan-tn.pdf
>> >
>> >
>> > Thanks
>> >
>> > Nitzan
>> >
>> >
>> > On Wed, Mar 28, 2018 at 5:27 PM Vincent Bernat <ber...@luffy.cx> wrote:
>> >
>> >> Hey!
>> >>
>> >> I am trying to setup a Juniper QFX5100 as a VTEP with a very classic
>> >> setup. Everything works as expected, but the setup is only using one
>> >> possible path from the underlay network.
>> >>
>> >> I have the route to the other VTEP like this:
>> >>
>> >> # run show route 10.16.39.3
>> >>
>> >> inet.0: 240 destinations, 1808 routes (240 active, 0 holddown, 0 hidden)
>> >> + = Active Route, - = Last Active, * = Both
>> >>
>> >> 10.16.39.3/32  *[BGP/140] 00:38:24, localpref 500, from 10.64.0.5
>> >>   AS path: I, validation-state: unverified
>> >>   to 10.64.0.23 via xe-0/0/46.181
>> >> > to 10.64.128.23 via xe-0/0/47.183
>> >> [BGP/140] 00:38:24, localpref 500, from 10.64.128.6
>> >>   AS path: I, validation-state: unverified
>> >> > to 10.64.128.23 via xe-0/0/47.183
>> >> [BGP/140] 00:38:24, localpref 500, from 10.64.0.3
>> >>   AS path: I, validati

Re: [j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

Hey!

Which version of JunOS are you running? I am on 17.4R1. I see that
18.1R1 was just released, I may try it tomorrow. Do you also have
a :vxlan.inet.0 table and does it show two paths too?

In my configuration, I have:

set routing-options forwarding-table export loadbalance
set policy-options policy-statement loadbalance then load-balance per-packet
set protocols bgp group v4-UNDERLAY multipath
set protocols bgp group v4-EVPN multipath

The PDF document is helpful. It says:

> The QFX5100/QFX5110 can only install VTEP next hops in the PFE; it
> cannot install ESI next hops. This means that, for any given overlay
> destination, only one remote VTEP can be selected. To send traffic to
> the selected VTEP, traffic can be load balanced at the underlay layer
> through the two spine nodes.

I need to do more tests, as the other provided commands may hint this is
just a display issue.
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
-- Wm. Shakespeare, "A Midsummer Night's Dream"

 ――― Original Message ―――
 From: Nitzan Tzelniker <nitzan.tzelni...@gmail.com>
 Sent: 28 mars 2018 18:36 GMT
 Subject: Re: [j-nsp] BGP EVPN, VXLAN and ECMP
 To: ber...@luffy.cx
 Cc: juniper-nsp@puck.nether.net

> Hi,
>
> Just check with 5110 and 5100 and on both I see two next hops
> but I am using OSPF for the underlay
> I think that you have multipath under BGP from the fact that we see two
> paths under inet.0 but do you have forwarding-table policy with
> "load-balance per-packet" ?
>
> BTW take a look here
> https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/lb-evpn-vxlan-tn.pdf
>
>
> Thanks
>
> Nitzan
>
>
> On Wed, Mar 28, 2018 at 5:27 PM Vincent Bernat <ber...@luffy.cx> wrote:
>
>> Hey!
>>
>> I am trying to setup a Juniper QFX5100 as a VTEP with a very classic
>> setup. Everything works as expected, but the setup is only using one
>> possible path from the underlay network.
>>
>> I have the route to the other VTEP like this:
>>
>> # run show route 10.16.39.3
>>
>> inet.0: 240 destinations, 1808 routes (240 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 10.16.39.3/32  *[BGP/140] 00:38:24, localpref 500, from 10.64.0.5
>>   AS path: I, validation-state: unverified
>>   to 10.64.0.23 via xe-0/0/46.181
>> > to 10.64.128.23 via xe-0/0/47.183
>> [BGP/140] 00:38:24, localpref 500, from 10.64.128.6
>>   AS path: I, validation-state: unverified
>> > to 10.64.128.23 via xe-0/0/47.183
>> [BGP/140] 00:38:24, localpref 500, from 10.64.0.3
>>   AS path: I, validation-state: unverified
>> > to 10.64.0.23 via xe-0/0/46.181
>>
>> :vxlan.inet.0: 17 destinations, 21 routes (17 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 10.16.39.3/32  *[Static/1] 00:31:10, metric2 0
>> > to 10.64.128.23 via xe-0/0/47.183
>>
>> So, from an IP point of view, I have two available routes to the other
>> VTEP. In the :vxlan.inet.0 table, only one route is kept. I suppose the
>> problem is at this point.
>>
>> Looking at the forwarding table, I have only one indirect next-hop too:
>>
>> # show route forwarding-table family ethernet-switching bridge-domain
>> vlan-client1-543 extensive
>>Routing table: default-switch.bridge [Index 4]
>>Bridging domain: vlan-client1-543.bridge [Index 3]
>>VPLS:
>>Enabled protocols: Bridging, ACKed by all peers,
>>
>> [...]
>>Destination:  0a:e3:40:00:00:d9/48
>>  Learn VLAN: 0Route type: user
>>  Route reference: 0   Route interface-index: 575
>>  Multicast RPF nh index: 0
>>  P2mpidx: 0
>>  IFL generation: 142  Epoch: 0
>>  Sequence Number: 0   Learn Mask:
>> 0x4000
>>  L2 Flags: control_dyn
>>  Flags: sent to PFE
>>  Next-hop type: composite Index: 2045 Reference: 6
>>  Next-hop type: indirect  Index: 131317   Reference: 3
>>  Nexthop: 10.64.128.23
>>  Next-hop type: unicast   Index: 1928 Reference: 4
>>  Next-hop interface: xe-0/0/47.183
>>
>> So, how to ensure the two possible next-hops are copied to the
>> ":vxlan.inet.0" table?
>> --
>> Make input easy to prepare and output self-explanatory.
>> - The Elements of Programming Style (Kernighan & Plauger)
>> ___
>> 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

[j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

Hey!

I am trying to setup a Juniper QFX5100 as a VTEP with a very classic
setup. Everything works as expected, but the setup is only using one
possible path from the underlay network.

I have the route to the other VTEP like this:

# run show route 10.16.39.3

inet.0: 240 destinations, 1808 routes (240 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.16.39.3/32  *[BGP/140] 00:38:24, localpref 500, from 10.64.0.5
  AS path: I, validation-state: unverified
  to 10.64.0.23 via xe-0/0/46.181
> to 10.64.128.23 via xe-0/0/47.183
[BGP/140] 00:38:24, localpref 500, from 10.64.128.6
  AS path: I, validation-state: unverified
> to 10.64.128.23 via xe-0/0/47.183
[BGP/140] 00:38:24, localpref 500, from 10.64.0.3
  AS path: I, validation-state: unverified
> to 10.64.0.23 via xe-0/0/46.181

:vxlan.inet.0: 17 destinations, 21 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.16.39.3/32  *[Static/1] 00:31:10, metric2 0
> to 10.64.128.23 via xe-0/0/47.183

So, from an IP point of view, I have two available routes to the other
VTEP. In the :vxlan.inet.0 table, only one route is kept. I suppose the
problem is at this point.

Looking at the forwarding table, I have only one indirect next-hop too:

# show route forwarding-table family ethernet-switching bridge-domain 
vlan-client1-543 extensive
   Routing table: default-switch.bridge [Index 4] 
   Bridging domain: vlan-client1-543.bridge [Index 3] 
   VPLS:
   Enabled protocols: Bridging, ACKed by all peers, 
   
[...]   
   Destination:  0a:e3:40:00:00:d9/48
 Learn VLAN: 0Route type: user  
 Route reference: 0   Route interface-index: 575 
 Multicast RPF nh index: 0 
 P2mpidx: 0  
 IFL generation: 142  Epoch: 0   
 Sequence Number: 0   Learn Mask: 
0x4000
 L2 Flags: control_dyn
 Flags: sent to PFE
 Next-hop type: composite Index: 2045 Reference: 6
 Next-hop type: indirect  Index: 131317   Reference: 3
 Nexthop: 10.64.128.23
 Next-hop type: unicast   Index: 1928 Reference: 4
 Next-hop interface: xe-0/0/47.183

So, how to ensure the two possible next-hops are copied to the
":vxlan.inet.0" table?
-- 
Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BMP and IPv6

[Vincent Bernat]

 ❦  6 décembre 2017 10:01 +0100, Vincent Bernat <ber...@luffy.cx> :

>> Path Attribute - MP_REACH_NLRI
>> Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
>> Type Code: MP_REACH_NLRI (14)
>> Length: 30
>> Address family identifier (AFI): IPv6 (2)
>> Subsequent address family identifier (SAFI): Unicast (1)
>> Next hop network address (16 bytes)
>> Number of Subnetwork points of attachment (SNPA): 0
>> Network layer reachability information (9 bytes)
>> MP Reach NLRI length 184 invalid
>> [Expert Info (Error/Malformed): MP Reach NLRI length 184 invalid]
>>
>>    90 0e 00 1e 00 02 01 10 20 01 0d b8 00 01 00 00   ...
>> 0010   00 00 00 00 00 00 00 01 00 40 20 01 0d b8 00 53  .@ S
>> 0020   00 00..
>>
>> Moreover, when routes are withdrawn, the UPDATE message doesn't contain
>> withdrawn routes but come with a MP_UNREACH_NLRI which has the same
>> encoding problem.
>
> In fact, the MP NLRI is correctly encoded. This seems to be a bug in
> Wireshark.

This is https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14241.

Wireshark has been extended to decode Add-Path ID in IPv6 NLRI but this
ID is present only if the ADD-PATH capability has been negotiated,
something difficult to know for Wireshark as the OPEN message may have
been missed.

Sorry for the noise!
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BMP and IPv6

[Vincent Bernat]

 ❦  6 décembre 2017 08:35 +0100, Vincent Bernat <ber...@luffy.cx> :

> Path Attribute - MP_REACH_NLRI
> Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
> Type Code: MP_REACH_NLRI (14)
> Length: 30
> Address family identifier (AFI): IPv6 (2)
> Subsequent address family identifier (SAFI): Unicast (1)
> Next hop network address (16 bytes)
> Number of Subnetwork points of attachment (SNPA): 0
> Network layer reachability information (9 bytes)
> MP Reach NLRI length 184 invalid
> [Expert Info (Error/Malformed): MP Reach NLRI length 184 invalid]
>
>    90 0e 00 1e 00 02 01 10 20 01 0d b8 00 01 00 00   ...
> 0010   00 00 00 00 00 00 00 01 00 40 20 01 0d b8 00 53  .@ S
> 0020   00 00..
>
> Moreover, when routes are withdrawn, the UPDATE message doesn't contain
> withdrawn routes but come with a MP_UNREACH_NLRI which has the same
> encoding problem.

In fact, the MP NLRI is correctly encoded. This seems to be a bug in Wireshark.
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] BMP and IPv6

[Vincent Bernat]

Hey!

I am trying to collect route information using BMP:
 
https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-bmp-understanding.html

No problem with IPv4. I receive new routes and withdrawn routes without
any issue. However, for IPv6, the MP_REACH_NLRI path attribute is
incorrectly encoded (both Wireshark and GoBGP agree on this):

Path Attribute - MP_REACH_NLRI
Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
Type Code: MP_REACH_NLRI (14)
Length: 30
Address family identifier (AFI): IPv6 (2)
Subsequent address family identifier (SAFI): Unicast (1)
Next hop network address (16 bytes)
Number of Subnetwork points of attachment (SNPA): 0
Network layer reachability information (9 bytes)
MP Reach NLRI length 184 invalid
[Expert Info (Error/Malformed): MP Reach NLRI length 184 invalid]

   90 0e 00 1e 00 02 01 10 20 01 0d b8 00 01 00 00   ...
0010   00 00 00 00 00 00 00 01 00 40 20 01 0d b8 00 53  .@ S
0020   00 00..

Moreover, when routes are withdrawn, the UPDATE message doesn't contain
withdrawn routes but come with a MP_UNREACH_NLRI which has the same
encoding problem.

Border Gateway Protocol - UPDATE Message
Marker: 
Length: 39
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 16
Path attributes
Path Attribute - MP_UNREACH_NLRI
Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
Type Code: MP_UNREACH_NLRI (15)
Length: 12
Address family identifier (AFI): IPv6 (2)
Subsequent address family identifier (SAFI): Unicast (1)
Withdrawn routes (9 bytes)
MP Unreach NLRI length 184 invalid
[Expert Info (Error/Malformed): MP Unreach NLRI length 184 
invalid]

   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  
0010   00 27 02 00 00 00 10 90 0f 00 0c 00 02 01 40 20  .'@ 
0020   01 0d b8 00 07 00 00 ...

Again, with IPv4 routes, no such issue:

Border Gateway Protocol - UPDATE Message
Marker: 
Length: 28
Type: UPDATE Message (2)
Withdrawn Routes Length: 5
Withdrawn Routes
192.0.2.7/32
Withdrawn route prefix length: 32
Withdrawn prefix: 192.0.2.7
Total Path Attribute Length: 0

I have tried various versions (16.1, 17.1, 17.3) without any
change. Even if Juniper was implementing an earlier draft, encoding of
path attributes should still be correct. Has someone already get this
problem?
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Copper transcievers in QFX5100, EX4600 and ACX5048

[Vincent Bernat]

 ❦  5 décembre 2017 15:40 +0100, Karl Gerhard  :

> the official documentation for QFX5100, EX4600 and ACX5048 contains the 
> following statement:
> https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/port-panel-qfx5100-48S.html
> "Caution: Do not place a copper transceiver in an access port directly
> above or below another copper transceiver. Internal damage to the
> access ports and switch can occur. We recommend either using the top
> port row exclusively, or bottom port row exclusively, for copper
> transceivers."
>
> Does this apply only to Direct Attach Cables or copper SFP modules
> oder both? This is potentially a big thing for us since we would like
> to use copper SFP modules on some of our devices.

DAC cables are fine, only copper SFP modules are affected. The damage is
mechanical due to the SFP module being too high.
-- 
Don't diddle code to make it faster - find a better algorithm.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 v MX104

[Vincent Bernat]

 ❦  2 décembre 2017 14:58 GMT, Raphael Maunier  :

> Price-List:
> MX204   40350 $ 2M fib / 6M rib & 32 vrf
> MX204-IR 48350 $ No fib/rib limit (datasheet 
> performances) but 32 vrf
> MX204-R   64350 $ No limit

No additional licenses needed to enable ports? Those prices are
significantly lower than the prices for the MX104.
-- 
"You have been in Afghanistan, I perceive."
-- Sir Arthur Conan Doyle, "A Study in Scarlet"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)

[Vincent Bernat]

 ❦  1 décembre 2017 21:43 -0800, Chris Burton  :

> LACP and LLDP (and the like) are link local only protocols (would need
> to dig through the specifications to find the exact rules), they
> should not be forwarded by the bridge

802.1Q-2005, 8.6.3 and 8.13.4. However, some bridges are allowed to
forward those frames: two port mac relays can forward frames when
destination is 01-80-C2-00-00-03 (802.1Q-2011, dunno which part since
it's not freely available) and QinQ bridges can forward frames when the
destination is 01-80-C2-00-00-00 (LLDP frames can use those MAC
addresses since 802.1AB-2009, dunno if there is something similar for
LACP).
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Need Assistance

[Vincent Bernat]

 ❦  7 novembre 2017 10:52 +0500, sameer mughal  :

> Hi All,
>
> Kindly review below routes, can anyone please help me to prefer BGP over
> OSPF internal route?
> What will be the configuration, please?

set protocols ospf preference 180
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] STP in spine leaf architecture

[Vincent Bernat]

 ❦ 26 octobre 2017 18:35 +0530, Mehul gajjar  :

> Can anybody give me knowledge how Spanning tree behaviour in
> spine/leaf data center architecture where qfx as a spine and leaf too.

Hello,

There is no loop, so you don't need STP. You can still use it by placing
all leaf ports as edge.
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Using a QFX5100 without QFabric?

[Vincent Bernat]

 ❦ 24 octobre 2017 14:29 -0400, Andrey Kostin  :

> QFX5100 are good as L2 devices for aggregation, we use them in
> virtual-chassis. But be careful with planning any L3 services on
> them. First, don't put public IPs on them because TCAM for filters is
> tiny and programmed in a tricky for understanding way. As a result
> everything that doesn't fit in TCAM is silently allowed. We observed
> that lo0 filters were "bypassed" this way and switch was exposed to
> continuous brute-force attack.

That's scary! I remember having a commit error when I set too many
filters (in fact, too many source/destination combination, solved by
removing either source or destination from the filter), so there are
some checks in place. Which version were you using when you got the
problem? Is there an easy way to check if we are hit by that?

> Second thing I can recall is that MPLS works only on physical
> interfaces, not irb. And finally I had very mixed results when tried
> to PIM multicast routing between irb interfaces and have to give up
> and pass L2 to a router, didn't try it on physical ports though.

I had also some bad experience with IRB on QFX5100. For example,
unnumbered interfaces don't work on IRB. Also, I have also already
related here my troubles with IRB, routing daemons and MC-LAG. For some
reasons, it seems many features don't play well with IRB (at least on
14.1X53 train). I am now using them as L2 switches and as BGP RR (but no
routing) and so far, no problems.
-- 
Don't go around saying the world owes you a living.  The world owes you
nothing.  It was here first.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Inline J-Flow on MX104

[Vincent Bernat]

Hello,

I am trying to understand the impact of enabling inline J-Flow on the
MX104. There are various reports this could impact performance
negatively.

My oldest chassis are running 13.3R8. The release notes say about known
issues:

 - Performance degradation of 8 percent is observed on the maximum
   packet per second supported of J-Flow records exported. PR949965
 - Performance degradation of 8 percent is observed on the maximum
   packet per second supported of J-Flow records exported. PR950101

I don't have access to those PR. It is unclear for me if the performance
degradation is on the total bandwidth of the chassis or if there is an 8%
slow down on latency.

There are various reports saying this feature will also impact BGP
convergence times (which are already not great, notably on 13.3):

 http://seclists.org/nanog/2016/Mar/303
 https://lists.gt.net/nsp/juniper/53823#53823

They mention PR836197 which is marked resolved in 13.2R1. Can I then
expect J-Flow to not have a negative impact on 13.3R8? Or are there any
known issues solved in more recent versions?

Thanks!
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Many contributing routes

[Vincent Bernat]

Hey!

I am generating a default route to distribute with a policy statement
like that:

#v+
policy-statement v4-DEFAULT-ROUTE-GENERATE {
term v4-TRANSIT-ASX {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
term v4-TRANSIT-ASY {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
then reject;
}
#v-

This works just fine but there are a lot of contributing routes (about
400k) to the generated route. Is it harmless or will I run into trouble
for that?

Thanks!
-- 
A classic is something that everyone wants to have read
and nobody wants to read.
-- Mark Twain, "The Disappearance of Literature"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG on QFX5100

[Vincent Bernat]

 ❦ 10 juillet 2017 12:36 -0400, William McLendon  :

> if you are running a routing protocol over the particular VLAN on the
> MC-LAG peers (which is a supported config in Junos MC-LAG
> implementation) make sure you are running VRRP between the MC-LAG
> peers, even though it seems unnecessary.  VRRP seems required for any
> ARP sync to occur for a given IRB interface.  Without it one side can
> learn the ARP entry but not the other.  Clearing arp cache seems to
> fix it temporarily but then it pops up again after ARP ages out.
>
> We ran into this issue in a similar scenario with MC-LAG L2-only
> switches where you could only ping the default gateway from one node
> unless you issued a clear arp, and then it would work until ARP timer
> ran out again.  Once we configured VRRP that issue was resolved.

Which version do you use? I specifically configured VRRP for this reason
but still ran into ARP problems.
-- 
There's small choice in rotten apples.
-- William Shakespeare, "The Taming of the Shrew"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG on QFX5100

[Vincent Bernat]

 ❦  9 juillet 2017 09:07 GMT, "Jackson, William"  :

> We have been testing an MC-LAG active/active setup on qfx5100 using the 
> latest 14.1x53 code.
> We are seeing issues when using L3 in the MC-LAG.
> We are using IRB with VRRP on a number of vlans that face the downstream 
> client.
> It seems that in active/active both nodes process traffic even if they
> are not the VRRP master, so we have taken that into account.
>
> The issue we are seeing seems to be that the ARP sync is not working on the 
> ICCP between the peers.
> We can reach downstream nodes via one peer but not the other.
> And it works correctly on some vlans but not others so isn’t related to the 
> downstream client.
>
> JTAC is on it albeit at snail’s pace.
>
> Has anyone got this working on qfx5100 and can share some config
> examples?

I ran into similar limitations with the same version. I have tried both
MAC synchronization and VRRP. When packets hit the "wrong" node (the one
that didn't learn the neighbor information), they are not
forwarded. See:

 https://lists.gt.net/nsp/juniper/60956#60956

I got additional private feedback from people with similar issues
(MC-LAG and L3 forwarding). I didn't try to involve JTAC.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cheapest juniper router capable of lsys

[Vincent Bernat]

 ❦ 27 juin 2017 23:26 -0700, Chris Burton  :

> Interesting, in the kernel versions I tested I was not able to get it
> to work by just passing in the runtime changes to
> /sys/class/net//bridge/group_fwd_mask, I actually had to make
> changes to virtual bridge header file and recompile the kernel as
> there are/were safeguards in place to prevent someone from just making
> the runtime changes, which makes sense because this is a potentially
> dangerous change.  Recompiling is not a big deal, but would be
> interested to know which kernel versions you were able to get that to
> work with just runtime changes as that would save some time.

The different cases are handled here:
 
http://elixir.free-electrons.com/linux/v4.11.5/source/net/bridge/br_input.c#L275

fwd_mask_required is not tunable by the user. Unless you are using
VLAN-aware bridges _and_ QinQ, its value is 0. group_fwd_mask is the
live value you put in sysfs, so it should work. There is a safeguard
mechanism to deny acceptance of 01-80-C2-00-00-[00,0B,0C,0D,0F] when
setting the group_fwd_mask value.

I didn't test recently, but I have used this mechanism in the past for
LLDP. Which kernel are you using?
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cheapest juniper router capable of lsys

[Vincent Bernat]

 ❦ 27 juin 2017 22:40 -0700, Chris Burton  :

> Also, if you use KVM and linux bridge you can bypass the issues with
> the bridges not forwarding LLDP and LACP traffic, but you have to
> willing to dive into modifying certain parts of the virtual bridge
> network drivers and compile your own custom kernel, as by standards
> bridges are not supposed to forward the traffic related to LCAP and
> LLDP.  I have also heard that this can be bypassed by using Open
> vSwitch, but I have not tested that.  The only items I have not yet
> been able to get working are related to Ethernet OAM, but so far
> everything else I have tested has worked either directly or with some
> modification.

On Linux, you can tell the bridge to let LLDP and LACP traffic without
recompiling. This is done by altering the value of
/sys/class/net/brXX/bridge/group_fwd_mask. To let LLDP pass, you need to
put 0x4000 in it. For LACP, this is 0x4. So 0x4004 should let both of
them pass the bridge.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cheapest juniper router capable of lsys

[Vincent Bernat]

 ❦ 28 juin 2017 09:56 +1000, Dale Shaw  :

>> The downside of the vMX for experimentation is that it is very CPU
>> hungry. The dataplane VMs are using a busy loop to catch packets and
>> they will use 100% of the CPU you allocate to them. They also need a lot
>> of memory.
>
> For vMX, there is a "lite" flavour of the PFE image that uses DPDK in
> interrupt mode instead of poll mode.
>
> See:
> https://www.juniper.net/documentation/en_US/vmx15.1f6/topics/task/configuration/vmx-chassis-flow-caching-enabling.html

Good to know!

Unfortunately, when switching to lite-mode, the vFPC restarts but still
uses 100% CPU. I'll try to update to a more recent version.
-- 
If one cannot enjoy reading a book over and over again, there is no use
in reading it at all.
-- Oscar Wilde
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cheapest juniper router capable of lsys

[Vincent Bernat]

 ❦ 27 juin 2017 13:33 -0500, "Aaron Gould"  :

> I think on my vMX when I type "show version" it says "olive"  :|

For me, it looks like that:

juniper@vMX> show version
Hostname: vMX
Model: vmx
Junos: 16.1R1.7
JUNOS OS Kernel 64-bit  [20160624.329953_builder_stable_10]
JUNOS OS libs [20160624.329953_builder_stable_10]
JUNOS OS runtime [20160624.329953_builder_stable_10]
[...]

Maybe you have an early version (something before 14.1)?
-- 
The Public is merely a multiplied "me."
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cheapest juniper router capable of lsys

[Vincent Bernat]

 ❦ 27 juin 2017 10:53 -0500, "Aaron Gould"  :

> Thanks Vincent, a coworker and myself were able to fire up a few lsys's on 
> olive/vmx
>
> The problem I have the vmx/olive on my gns3 box is that I have
> forwarding issues with layer 2 type stuff.  I used GNS3/olive/vmx for
> lots of routing/mpls l3vpn testing, but layer 2 stuff never worked for
> me.  Is there a way to get l2circuit and bridging and vpls to work and
> actually pass traffic in vmx/olive ?

You seem to assume Olive and vMX are the same thing. I believe Olive was
a hack to run JunOS using FreeBSD. You got a control plane and no real
dataplane (all data forwarding was delegated to JunOS which I suppose
was able to do IP routing, but not bridging).

On the other hand, vMX comes with a supported JunOS VM as a control
plane and one or several VM acting as data plane. Those VM translate
instructions for the Trio chipset into x86 instructions. All features
available in a real MX should be available in the vMX. I didn't try
anything fancy myself, but IRB is running without any problem.

The downside of the vMX for experimentation is that it is very CPU
hungry. The dataplane VMs are using a busy loop to catch packets and
they will use 100% of the CPU you allocate to them. They also need a lot
of memory. The same applies for all other similar products from Juniper
(vSRX, vQFX). Older versions of the vSRX are lighter, notably the
Firefly appliance (vSRX 12.something).
-- 
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cheapest juniper router capable of lsys

[Vincent Bernat]

 ❦ 27 juin 2017 14:07 +0200, Youssef Bengelloun-Zahr  :

> Did you take a look at vMX or vSRX ? Not sure about l-sys support on
> those ?

vMX evaluation version supports l-sys. Didn't checked for vSRX. If there
is no need to forward packets, vRR is a nice alternative as it won't use
100% of the CPU.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cut-through forwarding statistics on QFX5100

[Vincent Bernat]

 ❦ 22 juin 2017 00:28 +0200, Thomas Bellman  :

> We have a QFX5100 on which we have enabled cut-throug forwarding
> ('set forwarding-options cut-through').  Now I am curious about
> how effective that is.  Is there any statistics one can dig out
> about how often the switch is able to do cut-through, and how
> often it has to fall back to store-and-forward?  I haven't found
> anything in 'show interfaces extensive', nor any other promising
> 'show' command.

Related question: why isn't cut-through the default mode? Is there any
downside of this mode (apart from forwarding invalid frames which
shouldn't matter much nowaday)?
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)
___
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)

[Vincent Bernat]

 ❦ 18 avril 2017 21:51 +0200, Raphael Mazelier  :

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

Documentation says:

> By default, the Junos Trio Modular Port Concentrator (MPC) chipset on
> MX Series routers is enabled with indirectly connected next hops, and
> this cannot be disabled using the no-indirect-next-hop statement.
-- 
Harp not on that string.
-- William Shakespeare, "Henry VI"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP4-MIB-v2

[Vincent Bernat]

 ❦ 27 mars 2017 21:15 GMT, Jeff Haas  :

>> I totally understand it's not possible to just fix the issue. Your best
>> bet is to convert the draft into a RFC and fix the issue here! ;-)
>
> After checking with Jürgen about RFC 4001 encoding (no better answer!)
> he confirms that we're missing the variable length length field in our
> generated OIDs.
>
> I'll make a point of filing a PR on this.  As noted elsewhere in
> thread, solving it might be ... interesting.

Thanks!

I won't hold my breath and will learn a bit more about YANG in the
meantime. ;-)
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP4-MIB-v2

[Vincent Bernat]

 ❦ 27 mars 2017 19:26 GMT, Jeff Haas  :

> To your relevant next point: If the junos mib is in error, what to do about 
> it?
>
> Very likely fixing the issue will cause mass amounts of unhappiness as
> people's existing scripts and mib walking code fails due to the new
> sub-indices.
>
> do the right thing, create misery? Leave it as is, document that it's
> wrong?

I totally understand it's not possible to just fix the issue. Your best
bet is to convert the draft into a RFC and fix the issue here! ;-)

Otherwise, use another table with the correct indexing?
jnxBgpM2PeerTableNew := jnxBgpM2PeerData.2?

Dunno if it's worth your time.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP4-MIB-v2

[Vincent Bernat]

 ❦ 27 mars 2017 16:10 GMT, Jeff Haas  :

>> I have been reported a (simple) bug in the implementation of the
>> BGP4-V2-MIB-JUNIPER. I know that if I open a JTAC case about this, I
>> will be asked a lot of unrelated questions, then I would be told that
>> since this never really worked, this is not the scope for JTAC.
>> 
>> So, as I know some Juniper people reads here, here is the bug. I'd be
>> happy to provide more details if needed.
>
> Read, yes.  Read on a timely basis, no.
>
> I also happen to be the author of the ietf mib that Juniper based this
> MIB on. :-)

Glad I have caught your attention and thanks for taking the time to answer!

>>jnxBgpM2CfgPeerLocalAddr OBJECT-TYPE
>>SYNTAX InetAddress (SIZE (4..20))
>>MAX-ACCESS read-create
>>STATUS current
>>DESCRIPTION
>>"The address of the local end of the peering session."
>>::= { jnxBgpM2CfgPeerEntry 4 }
>> 
>> (and similar for RemoteAddr). The important bit is the size: variable.
>> 
>> With SNMP, when an index has a variable length, except if it's the last
>> one _and_ the MIB says the size is IMPLIED, the length should be
>> prepended to the value.
>> 
>> So, 192.0.2.47 should be encoded to 4.192.0.2.47.
>
> Probably no.
>
> The headache here is that the underlying type is RFC 4001's
> InetAddress.  As you can see in the documentation in that RFC the
> expectation is that the InetAddressType is used to 'cast' the
> InetAddress to one of the underlying types; e.g. InetAddressIPv4.
> Let's pick on that example:
>
> InetAddressIPv4 ::= TEXTUAL-CONVENTION
> DISPLAY-HINT "1d.1d.1d.1d"
> STATUS   current
> DESCRIPTION
> "Represents an IPv4 network address:
>
>Octets   Contents Encoding
> 1-4 IPv4 address network-byte order
>
>  The corresponding InetAddressType value is ipv4(1).
>
>  This textual convention SHOULD NOT be used directly in object
>  definitions, as it restricts addresses to a specific format.
>  However, if it is used, it MAY be used either on its own or in
>  conjunction with InetAddressType, as a pair."
> SYNTAX   OCTET STRING (SIZE (4))

> So, while you're correct with regard to variable types, the
> expectation is that this is "cast" into a fixed sized octet string,
> which has implied length.

I didn't know about RFC 4001 so I may be mistaken, but it doesn't say
anything about the size requirement. Other than the comments in the MIB,
there is also no way to link InetAddress and InetAddressIPv4. This is
not just a matter of being able to pretty-print the IPv4, it's that we
cannot know how to split the index into its components.

> Given that net-snmp seems to recognize how to render the output from
> the MIB, I suspect others came to a similar conclusion.

Net-SNMP is not able to render the output of the MIB correctly if the
size is not specified. See, without the size:

$ snmptranslate -m BGP4-V2-MIB-JUNIPER 
iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.10.64.0.3.1.10.64.0.1
BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4.10.64.0.3.1.10.64.0.1

If I add the size:

$ snmptranslate -m BGP4-V2-MIB-JUNIPER 
iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.4.10.64.0.3.1.4.10.64.0.1
BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4."10.64.0.3".ipv4."10.64.0.1"

Other MIB implementations also using AddrType/Addr includes the size,
for example (on JunOS 14.1):

$ snmpgetnext net-tor-0114-1 IP-MIB::ipAddressTable
IP-MIB::ipAddressIfIndex.ipv4."10.64.0.3" = INTEGER: 567
$ snmpgetnext -On net-tor-0114-1 IP-MIB::ipAddressTable
.1.3.6.1.2.1.4.34.1.3.1.4.10.64.0.3 = INTEGER: 567
-- 
I was gratified to be able to answer promptly, and I did. I said I didn't know.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP add-path on QFX

[Vincent Bernat]

 ❦ 30 janvier 2017 13:47 +0100, Vincent Bernat <ber...@luffy.cx> :

>>>> > No ideas on what can be wrong with your configuration :(
>>>> > We run add-path on most MXes without any problems. Just tried with QFX 
>>>> > (not running bgp actually), add-path command is not hidden for me and 
>>>> > commit 
>>>> > check succeeds: 
>>>> 
>>>> Thanks for checking, that's helpful!
>>>> 
>>>> In fact, I am using routing instances. Like you, I can get add-path
>>>> send/receive outside a routing instance, but inside, add-path is
>>>> hidden. I assumed this was independent of the routing instance
>>>> (configured type virtual-router), so I didn't bother to check that.
>>>> 
>>>> Does "set routing-instances rr1 protocols bgp group apath family inet
>>>> unicast add-path ..." complete for you?
>>>
>>> Looks like routing-instances is the difference. Within routing-instance
>>> add-path does not complete for me too, neither on QFX nor on MX.
>>
>> So, I am trying to not use routing instances. Is there a way to tell a
>> BGP group to use a different primary RIB than inet.0 (for family inet
>> unicast)? There is the rib-group directive but it enforces that the
>> first member of the rib-group to be the primary RIB.
>
> In fact, I will switch to using logical-systems. The option is available
> in this case and works fine in lab.

But logical systems don't seem to be supported on a QFX 5100 (commands
accepted, but no logical systems created)... :-/
-- 
No violence, gentlemen -- no violence, I beg of you!  Consider the furniture!
-- Sherlock Holmes
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP add-path on QFX

[Vincent Bernat]

 ❦ 30 janvier 2017 11:45 +0100, Vincent Bernat <ber...@luffy.cx> :

>>> > No ideas on what can be wrong with your configuration :(
>>> > We run add-path on most MXes without any problems. Just tried with QFX 
>>> > (not running bgp actually), add-path command is not hidden for me and 
>>> > commit 
>>> > check succeeds: 
>>> 
>>> Thanks for checking, that's helpful!
>>> 
>>> In fact, I am using routing instances. Like you, I can get add-path
>>> send/receive outside a routing instance, but inside, add-path is
>>> hidden. I assumed this was independent of the routing instance
>>> (configured type virtual-router), so I didn't bother to check that.
>>> 
>>> Does "set routing-instances rr1 protocols bgp group apath family inet
>>> unicast add-path ..." complete for you?
>>
>> Looks like routing-instances is the difference. Within routing-instance
>> add-path does not complete for me too, neither on QFX nor on MX.
>
> So, I am trying to not use routing instances. Is there a way to tell a
> BGP group to use a different primary RIB than inet.0 (for family inet
> unicast)? There is the rib-group directive but it enforces that the
> first member of the rib-group to be the primary RIB.

In fact, I will switch to using logical-systems. The option is available
in this case and works fine in lab.
-- 
The surest protection against temptation is cowardice.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP add-path on QFX

[Vincent Bernat]

 ❦ 27 janvier 2017 20:08 +0300, Alexandre Snarskii  :

>> > No ideas on what can be wrong with your configuration :(
>> > We run add-path on most MXes without any problems. Just tried with QFX 
>> > (not running bgp actually), add-path command is not hidden for me and 
>> > commit 
>> > check succeeds: 
>> 
>> Thanks for checking, that's helpful!
>> 
>> In fact, I am using routing instances. Like you, I can get add-path
>> send/receive outside a routing instance, but inside, add-path is
>> hidden. I assumed this was independent of the routing instance
>> (configured type virtual-router), so I didn't bother to check that.
>> 
>> Does "set routing-instances rr1 protocols bgp group apath family inet
>> unicast add-path ..." complete for you?
>
> Looks like routing-instances is the difference. Within routing-instance
> add-path does not complete for me too, neither on QFX nor on MX.

So, I am trying to not use routing instances. Is there a way to tell a
BGP group to use a different primary RIB than inet.0 (for family inet
unicast)? There is the rib-group directive but it enforces that the
first member of the rib-group to be the primary RIB.

There is also "topology", but the documentation says that routes are
still placed in the default RIB.
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP add-path on QFX

[Vincent Bernat]

 ❦ 27 janvier 2017 20:08 +0300, Alexandre Snarskii  :

>> > No ideas on what can be wrong with your configuration :(
>> > We run add-path on most MXes without any problems. Just tried with QFX 
>> > (not running bgp actually), add-path command is not hidden for me and 
>> > commit 
>> > check succeeds: 
>> 
>> Thanks for checking, that's helpful!
>> 
>> In fact, I am using routing instances. Like you, I can get add-path
>> send/receive outside a routing instance, but inside, add-path is
>> hidden. I assumed this was independent of the routing instance
>> (configured type virtual-router), so I didn't bother to check that.
>> 
>> Does "set routing-instances rr1 protocols bgp group apath family inet
>> unicast add-path ..." complete for you?
>
> Looks like routing-instances is the difference. Within routing-instance
> add-path does not complete for me too, neither on QFX nor on MX.

Thanks for the confirmation. That's a pity for a control-plane
feature. I will rework the configuration to not use routing instances.
-- 
If one cannot enjoy reading a book over and over again, there is no use
in reading it at all.
-- Oscar Wilde
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP add-path on QFX

[Vincent Bernat]

 ❦ 27 janvier 2017 18:34 +0300, Alexandre Snarskii  :

>> I have upgraded some QFX to 16.1R3 but there is no difference with
>> 14.1X53-D40: add-path is an hidden command and only "receive" is
>> available ("send" is not accepted):
>> 
>>   set protocols bgp group batman family inet unicast add-path send ...
>> 
>> I have also tried on MX104 running 14.1R8. Feature explorer says this
>> should be supported since 13.2R2. But I am in the exact same situation:
>> add-path is a hidden command and only "receive" is available.
>> 
>> I wonder if I am not missing something obvious. Any tip would be
>> appreciated!
>
> No ideas on what can be wrong with your configuration :(
> We run add-path on most MXes without any problems. Just tried with QFX 
> (not running bgp actually), add-path command is not hidden for me and commit 
> check succeeds: 

Thanks for checking, that's helpful!

In fact, I am using routing instances. Like you, I can get add-path
send/receive outside a routing instance, but inside, add-path is
hidden. I assumed this was independent of the routing instance
(configured type virtual-router), so I didn't bother to check that.

Does "set routing-instances rr1 protocols bgp group apath family inet
unicast add-path ..." complete for you?
-- 
ROMEO:  Courage, man; the hurt cannot be much.
MERCUTIO:   No, 'tis not so deep as a well, nor so wide
as a church-door; but 'tis enough, 'twill serve.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] BGP add-path on QFX

[Vincent Bernat]

Hey!

I am using some QFX as route reflectors and would like to use BGP
add-path feature. The documentation says that QFX is a supported
platform[0] while the feature explorer says no QFX has support for
that[1].

[0]: 
http://www.juniper.net/techpubs/en_US/junos16.1/topics/example/bgp-add-path.html
[1]: 
https://pathfinder.juniper.net/feature-explorer/feature-info.html?fKey=3294=For+internal+BGP+(IBGP),+advertise+multiple+paths+to+a+destination

I have upgraded some QFX to 16.1R3 but there is no difference with
14.1X53-D40: add-path is an hidden command and only "receive" is
available ("send" is not accepted):

  set protocols bgp group batman family inet unicast add-path send ...

I have also tried on MX104 running 14.1R8. Feature explorer says this
should be supported since 13.2R2. But I am in the exact same situation:
add-path is a hidden command and only "receive" is available.

I wonder if I am not missing something obvious. Any tip would be
appreciated!
-- 
The human race has one really effective weapon, and that is laughter.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] BGP4-MIB-v2

[Vincent Bernat]

Hey!

I have been reported a (simple) bug in the implementation of the
BGP4-V2-MIB-JUNIPER. I know that if I open a JTAC case about this, I
will be asked a lot of unrelated questions, then I would be told that
since this never really worked, this is not the scope for JTAC.

So, as I know some Juniper people reads here, here is the bug. I'd be
happy to provide more details if needed.


The MIB says:

jnxBgpM2PeerEntry OBJECT-TYPE
SYNTAX JnxBgpM2PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry containing information about the connection with
 a remote BGP peer."
INDEX {
jnxBgpM2PeerRoutingInstance,
jnxBgpM2PeerLocalAddrType,
jnxBgpM2PeerLocalAddr,
jnxBgpM2PeerRemoteAddrType,
jnxBgpM2PeerRemoteAddr
}
::= { jnxBgpM2PeerTable 1 }

And jnxBgpM2PeerLocalAddr is:

jnxBgpM2CfgPeerLocalAddr OBJECT-TYPE
SYNTAX InetAddress (SIZE (4..20))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The address of the local end of the peering session."
::= { jnxBgpM2CfgPeerEntry 4 }

(and similar for RemoteAddr). The important bit is the size: variable.

With SNMP, when an index has a variable length, except if it's the last
one _and_ the MIB says the size is IMPLIED, the length should be
prepended to the value.

So, 192.0.2.47 should be encoded to 4.192.0.2.47.

Let's suppose we need to encode:

jnxBgpM2PeerRoutingInstance: 0
jnxBgpM2PeerLocalAddrType: 1 (code for ipv4)
jnxBgpM2PeerLocalAddr: 192.0.2.47
jnxBgpM2PeerRemoteAddrType: 1 (code for ipv4)
jnxBgpM2PeerRemoteAddr: 192.0.2.48

We should have:

0.1.4.192.0.2.47.1.4.192.0.2.48

But JunOS (at least 13.3 and 14.1) is using:

0.1.192.0.2.47.1.192.0.2.48
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] disaccord in output of "df" and "df " in Junos

[Vincent Bernat]

 ❦  9 janvier 2017 09:58 +0200, Martin T  :

> /dev/bo0s3f 1264808  844256 31936873%/cf/var
> /cf/var/jail1264808  844256 31936873%/jail/var
> /cf/var/log 1264808  844256 31936873%/jail/var/log
[...]

> As seen above, none of the mount-points matches /var/log. Now when I
> execute "df /var/log", then I expect it to be on /(and thus on
> /dev/da0s2a file-system), but for some odd reason it seems to be
> associated with /cf/var(and thus on /dev/bo0s3f file-system):
>
>
> $ df /var/log
> Filesystem  512-blocks   Used  Avail Capacity  Mounted on
> /dev/bo0s3f1264808 844616 31900873%/cf/var
> $
>
>
> Or another example where output of "df" and "df " do not match:
>
> $ df /usr
> Filesystem 512-blocksUsed Avail Capacity  Mounted on
> /dev/md1  1063984 1063984 0   100%/junos
> $
>
>
> What causes Junos(or underlying FreeBSD) to behave like that?

Unfortunately, there is no "stat" command that would help to have a
better picture. df will "stat" the file you provide to get the device it
is stored on and there search the device and its mountpoint to display the
result. Therefore, any "bind" mount is ignored. The mount point is not
translated to account for any chroot/jail the current process is running
in.

For /var/log, your shell is currently rooted in /jail, so the "absolute"
path is /jail/var/log which is in fact bound to directory /cf/var/log
whose mountpoint is /cf/var whose device is /dev/bo0s3f.
-- 
How apt the poor are to be proud.
-- William Shakespeare, "Twelfth-Night"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG reliability

[Vincent Bernat]

 ❦ 22 décembre 2016 15:15 +0100, Vincent Bernat <ber...@luffy.cx> :

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

A quick feedback on my tests with MC-LAG: it doesn't work well for
me. While pure L2 operations worked fine, I had huge difficulties
running BGP sessions terminated at the IRB, either by using MAC
synchronization or VRRP (or neither of them). Local IP delivery on the
IRB seems patchy: the MAC address for local delivery to the remove
switch is learned on the ICCP VLAN instead of the IRB VLAN.

I didn't tried too hard, so maybe I missed something. I didn't want an
HA setup for local delivery, so I first tried with neither MAC sync nor
VRRP. Then I have tried MAC synchronization (which was an improvement
from "reproducibly don't work for some BGP sessions" to "work for all
BGP sessions but break after one hour"), then VRRP (without MAC
synchronization). After reverting the whole stuff, even L2 operations
didn't work correctly until a reboot. Maybe only MAC synchronization is
broken and VRRP would have worked.

The issues also affected ICMP handling.

Tested with 14.1X53-D35 on a pair of QFX5100.
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG reliability

[Vincent Bernat]

Hey!

I also think that the VC is quite reliable. However, by design, it is a
bit fragile. rpd can die and take the whole VC down. I also remember
quite a few problems with upgrades but this is quite ancient, so maybe
this doesn't apply any more.

I didn't test much, but even on the EX3300 with 15.5, you seem to have
MC-LAG support (and no warnings from the CLI when using it). Dunno if
this is recent or not.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Raphael Mazelier <r...@futomaki.net>
 Sent: 22 décembre 2016 18:32 +0100
 Subject: Re: [j-nsp] MC-LAG reliability
 To: juniper-nsp@puck.nether.net

> 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG reliability

[Vincent Bernat]

Hey!

It's for a quite basic ToR setup: each server in the rack dual
linked. L2 only. No STP.

All servers have a couple of BGP sessions running through the
switches but they don't do any routing. Some of the QFX will act as
route reflectors, so they can have an IP on their IRB, but that should
be quite independant of this MC-LAG stuff, right?
-- 
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Alberto Santos <albertofsan...@gmail.com>
 Sent: 22 décembre 2016 17:29 +0100
 Subject: Re: [j-nsp] MC-LAG reliability
 To: Vincent Bernat
 Cc: juniper-nsp@puck.nether.net

> Hi,
>
> last time a colleague checked the PR list, VC had more issues than MC LAG.
> How your L2 setup looks like? Do you configure STP on your L2 network ? which 
> version? make sure the STP version you have today is officially
> supported by juniper when you implement it.
>
> if you have any routing protocol such as eBGP or OSPF runnung through these 
> switches, you should make sure you test before you convert it to a
> MC LAG setup.
>
> With juniper pyez, there is no excuse to keep this in a VC setup, you should 
> really consider MC LAG :), another good advantage that you get is
> ISSU instead of NSSU :D 
>
> cheers and merry xmas
>
> Alberto Santos CCIE #26648
> JNCIP-SP
> "...Fix your DNS, make it dual-stack, take your mail server and make it 
> dual-stack, take your web server and make it dual-stack..." by Randy
> Bush/RIPE IPv6
>
> On 22 December 2016 at 15:15, Vincent Bernat <ber...@luffy.cx> 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!
>  --
>  Many pages make a thick book, except for pocket Bibles which are on very
>  very thin paper.
>  ___
>  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

[j-nsp] MC-LAG reliability

[Vincent Bernat]

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!
-- 
Many pages make a thick book, except for pocket Bibles which are on very
very thin paper.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX: Proxy ARP and ARP cache

[Vincent Bernat]

 ❦ 15 novembre 2016 11:47 +0100, Vincent Bernat <ber...@luffy.cx> :

> For example, assume that the MX is 192.0.2.1/24 and we have two hosts,
> 192.0.2.14 and 192.0.2.15, which are connected to some interface to the
> MX. Therefore, the MX has the following entries in its cache:
>
> 06:ea:3c:00:00:62 192.0.2.14ae0.90   none
> 06:ea:3c:00:00:63 192.0.2.15ae0.90   none
>
> Then, 192.0.2.14 moves to another equipment and the MX receives a route
> to let it know how to contact it:
>
> 192.0.2.14/32  *[BGP/170] 00:11:52, localpref 100
>   AS path: 65002 65004 I
> > to 198.51.0.14 via ae1.180
>
> The ARP cache entry is left intact. The MX has no problem to ping
> 192.0.2.14 from now on. It uses the route, not the ARP cache
> entry. However, on ae0.90, the MX is also configured with "proxy-arp
> unrestricted". The idea is that 192.0.2.15 should be able to contact
> 192.0.2.14. The MX should fake an ARP answer and route the traffic.
>
> However, as long as the 192.0.2.14 entry stays in the ARP cache, the MX
> won't answer the ARP request. Once the entry is expired, this works as
> expected.

Another funny behavior is the inability to delete the ARP entry. Once a
more specific route is setup, it's not possible to use "clear arp" on
the entry ("clear arp vpn public hostname 192.0.2.14"). Once the route
is removed, the entry can be deleted.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX: Proxy ARP and ARP cache

[Vincent Bernat]

Hey!

I am in the process of migrating from one setup to another and I need
the MX to proxy some ARP requests in the process. I can't use "proxy-arp
unrestricted" as it would attract far too much traffic, so I am trying
to stick with "proxy-arp restricted".

The documentation says:

 The router or switch responds to ARP requests in which the physical
 networks of the source and target are different and does not respond if
 the source and target IP addresses are in the same subnet. The router
 or switch must also have a route to the target IP address.

This totally matches my case. However, I have noticed that when there is
an entry for the target IP in the ARP cache, there is no answer. This is
quite inconvenient for me.

For example, assume that the MX is 192.0.2.1/24 and we have two hosts,
192.0.2.14 and 192.0.2.15, which are connected to some interface to the
MX. Therefore, the MX has the following entries in its cache:

06:ea:3c:00:00:62 192.0.2.14ae0.90   none
06:ea:3c:00:00:63 192.0.2.15ae0.90   none

Then, 192.0.2.14 moves to another equipment and the MX receives a route
to let it know how to contact it:

192.0.2.14/32  *[BGP/170] 00:11:52, localpref 100
  AS path: 65002 65004 I
> to 198.51.0.14 via ae1.180

The ARP cache entry is left intact. The MX has no problem to ping
192.0.2.14 from now on. It uses the route, not the ARP cache
entry. However, on ae0.90, the MX is also configured with "proxy-arp
unrestricted". The idea is that 192.0.2.15 should be able to contact
192.0.2.14. The MX should fake an ARP answer and route the traffic.

However, as long as the 192.0.2.14 entry stays in the ARP cache, the MX
won't answer the ARP request. Once the entry is expired, this works as
expected.

The JTAC has been unhelpful on this case as they consider that something
that never worked is out of their scope.

Any tip on how to make this kind of setup works would be helpful.

Thanks!
-- 
One of the most striking differences between a cat and a lie is that a cat has
only nine lives.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BCP for filtering management access, system-wide

[Vincent Bernat]

 ❦ 25 juillet 2016 22:55 CEST, Jason Lixfeld  :

> Previously, I tried to apply filters to various lo0 units, thinking
> those were the only interface to the RE, but that didn’t seem to help
> for cases where the IPs were applied to interfaces other than lo0
> units.  And I haven’t been able to find a way to apply a filter or
> client list specifically to the ssh service itself like you can with
> snmp, for example.

Your filters to lo0 should be enough to secure the RE. What is your
platform? There is this "Day One" book that gives some tips on the
subject:
 
http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX104 capabilities question

[Vincent Bernat]

 ❦  9 juin 2016 16:40 CEST, "Aaron"  :

> Thanks, Let me test this claim that an acx5048 cannot hold a full bgp
> table…… anyone know a way to get a test bgp session for a full feed ?

With ExaBGP, you can use a MRT dump:
 https://github.com/YoshiyukiYamauchi/mrtparse

Here is one:
 http://data.ris.ripe.net/rrc00/latest-bview.gz
-- 
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Vincent Bernat]

 ❦  1 juin 2016 18:22 CEST, Phil Rosenthal  :

> Even on systems with many peers, 5+ full tables, and a full IGP mesh,
> I haven’t seen rpd much over 1GB of ram in use.  64bit rpd would only
> be beneficial if you have a need for a rpd process using more than 4GB
> of ram.

The other benefit would be the ability for rpd to make use of more CPU
registers and to be faster. On average, one could expect a 20% speedup
when recompiling for x86-64. I have absolutely no idea if such number
would apply to rpd.
-- 
He jests at scars who never felt a wound.
-- Shakespeare, "Romeo and Juliet, II. 2"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Independent /32s for Interfaces - anybody doing that?

[Vincent Bernat]

 ❦ 31 mai 2016 13:12 CEST, v  :

> I just read about using independent /32 addresses for interfaces and I
> would like to know whether anybody uses that. Found the following
> information about such a configuration:
> -This means that there is no relation between the addresses on the two ends 
> of an interface
> -This relies on the IGP to provide this relationship
> -This significantly reduces the burden of address management and 
> synchronization
> -Also, reconfiguration of topology is much easier
>
> Are there more pros and cons than that?
> Does anyone have experience with such a configuration?

Hi!

I believe that you are talking about unnumbered interfaces: you put a
/32 on a loopback and you tell other interfaces to use the loopback
address. For example:

interfaces {
lo0 {
unit 1 {
family inet {
address 203.0.113.3/32;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
unnumbered-address lo0.1;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
unnumbered-address lo0.1;
}
}
}
}

I find this scheme very convienent:

 1. You can use only one public IP address for the whole equipment.

 2. You have less configuration to do and this is less error-prone. An
IGP like OSPF would make each router discover the addresses of all
other routers automatically.

Unfortunately, the support vary widely accross vendors. I believe the
support is pretty good with Cisco. With Juniper, it really depends on
the equipment. The MX has pretty good support, but has some limitations
(for example, static BFD + unnumbered doesn't work). The QFX doesn't
support unnumbered interfaces in various places (like for example, on an
IRB interface). From what I have been told, Juniper has no plan to fix
that. Cumulus supports them too (but I can't testify on the completeness
of the support). Other vendors may have no support at all for this, so
you get into some kind of vendor-lockin if you rely on this.
-- 
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 base model

[Vincent Bernat]

 ❦ 25 avril 2016 19:34 -0400, Satish Patel  :

> Does MX104 base model has 10G ports are lock? Also do I need to pay to
> run BGP?

The MX104 comes in a lot of (license) derivatives. Some of them have the
ports unlocked, some other needs a licence to use the ports and some of
them can't use them (eg MX5). There is a presentation with all the info
you could ask from a Juniper representative. Also, the following link
seems to contain an accurate summary:
 https://sites.google.com/site/juniperbuilder/home/juniper-routers/mx104

-- 
He hath eaten me out of house and home.
-- William Shakespeare, "Henry IV"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Vincent Bernat]

 ❦  5 avril 2016 11:58 -0400, Phil Shafer  :

> Apologies.  I shot my mouth off.  JUNOS does not currently support
> this.  And RADIUS, being cleartext, is not suitable.
>
> LDAP (w/ SSL) would be a better solution, using something like:
>
> https://github.com/AndriiGrytsenko/openssh-ldap-publickey
>
> which plugs into openssh using the "AuthorizedKeysCommand" sshd_config
> statement.  But JUNOS doesn't ship openldap, so the only way to
> make this work would be an external web server can proxies requests
> into LDAP.  The AuthorizedKeysCommand would be a script that makes
> the HTTP request and formats the results.  The above LPK script
> could be put inside a perl web framework like Mojolicious.

Are we allowed to modify manually the /var/etc/sshd_conf file? Moreover,
I suppose it could be rewritten on each commit by mgd.
-- 
Nothing so needs reforming as other people's habits.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Vincent Bernat]

 ❦  4 avril 2016 22:23 -0400, Phil Shafer  :

> Me, I don't even like allowing passwords.  JUNOS now supports the
> "system services ssh no-passwords" knob to force the use of ssh
> keys over text passwords.  And your radius server will happily serve
> ssh keys.  Force the move away from passwords.

On which attribute can SSH keys be served?
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos PyEz on Solaris 10.

[Vincent Bernat]

 ❦ 23 mars 2016 12:57 -0500, David Lockuan  :

> I am testing the Junos Automation with PyEZ, I have installed it in Ubuntu
> and work fine.
>
> But my customer have Desktop PC with Solaris 10 and they want to test this
> library of Junos Python on their PC.
>
> Then, I had reviewed the documentation about this but it don't show me
> nothing about installing on Solaris, so I would like to know of somebody
> have test it over solaris?

You can also use "pip install junos-eznc". However, the pycrypto
dependency (through paramiko) could be difficult to pull depending on
what is installed on the workstation.
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)
___
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

[Vincent Bernat]

 ❦ 18 février 2016 10:50 GMT, Adam Vitkovsky  :

>> You are right. I didn't understand your answer the first time as I thought 
>> that
>> PIC was for "programmable integrated circuit", so I thought this was a plan
>> for Juniper to fix the problem with some dedicated piece of hardware.

> Sorry about that, I'll try to be more explicit in my future posts.
>
> The setup is really easy
[...]

Oh, many thanks for the detailed setup! I'll need some time to update to
15.1 and I'll get back to you with the results once this is done.

> 5)always prefer eBGP over iBGP*
> set policy-options policy-statement FROM_TRANSIT term INGRESS_POLICY_A then 
> preference 169 <
> -by default,
> If the MX140-A from our previous example loses its Transit link it will (via 
> BGP-PIC) immediately reroute traffic to MX140-B
> However by default MX140-B has a best path via MX140-A -so until it
> receives withdrawn from MX140-A it'll loop traffic back to MX140-A.
> That's why you want MX140-B to prefer it's local exit.
>
> *not sure what was Juniper and ALU thinking when they came up with the
> same protocol preference for eBGP and iBGP routes, there's a ton of
> reasons why you always want to prefer closest AS-EXIT.

Unfortunately, I don't have the same upstream on both MX and for some
routes, one of them may have a better route than the other. The two MX
are advertising just a default, so they can attract traffic that would
be better routed by their neighbor. I'll try to think a bit about what's
more important.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)
___
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

[Vincent Bernat]

 ❦ 18 février 2016 07:31 -0600, Colton Conor  :

> So is the MX-104 processor really that underpowered? I have heard
> reports that is was too underpowered for its pricepoint, and now I am
> starting to believe it. Vincent what are your thoughts? 

Well, I don't have enough experience with it. However, it's unfortunate
that it needs a pricey license to handle a full view but is not able to
accomodate it efficiently (without BGP PIC).
-- 
Work consists of whatever a body is obliged to do.
Play consists of whatever a body is not obliged to do.
-- Mark Twain
___
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

[Vincent Bernat]

 ❦ 17 février 2016 21:07 GMT, Alexander Arseniev  :

> True, one cannot match on "next-hop" in "condition", only on exact
> prefix+table name.
> But this can be done using "route isolation" approach.
> So, the overall approach is:
> 1/ create a separate table and leak a 0/0 route there matching on 0/0
> exact + next-hop ("isolate the interested route"). Use
> "instance-import" + policy.
> 2/ create condition
>
> policy-options {
>  condition default-to-upstream {
>   if-route-exists {
>0.0.0.0/0;
>table isolate-0/0.inet.0;
>   }
>  }
>
> 3/ use condition to match & reject the specifics:
>
> policy-options {
>  policy-statement reject-same-nh-as-0/0 {
>   term 1  {
>   from {
> protocol bgp;
>route-filter 0/0 longer;
> condition default-to-upstream;
>   next-hop 198.18.1.1;
> }
> then reject;
> }
>  term 2  {
>   from {
> protocol bgp;
>route-filter 0/0 longer;
>   next-hop 198.18.1.1;
> }
> then accept;
> }

Just by curiosity, I tried your approach and it almost work. However,
for some reason, the condition can match when there is no route in the
associated table. I didn't do exactly as you proposed, so maybe I am
doing something wrong. I am not really interested in getting to the
bottom of this matter. I just post my current configuration in case
somebody is interested:

 
https://github.com/vincentbernat/network-lab/blob/d984d6c5f847b96a131b240d91346b46bfaecac9/lab-vmx-fullview/vMX1.conf#L106-L115

If I enable term 4, it catches all routes whose next-hop is
192.0.2.129 despite the condition being false. In the RIB, I have many
routes whose next-hop is 192.0.2.129:

root@vMX1# run show route next-hop 192.0.2.129

inet.0: 1110 destinations, 1869 routes (1110 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0   [BGP/140] 00:38:12, MED 10, localpref 100
  AS path: 65002 ?, validation-state: unverified
> to 192.0.2.129 via ge-0/0/1.0
[OSPF/150] 00:37:31, metric 10, tag 0
> to 192.0.2.129 via ge-0/0/1.0
1.0.240.0/20   *[BGP/140] 00:38:12, MED 10, localpref 100
  AS path: 65002 3257 3356 4651 9737 23969 I, 
validation-state: unverified
> to 192.0.2.129 via ge-0/0/1.0
1.1.1.0/24 *[BGP/140] 00:38:12, MED 10, localpref 100
  AS path: 65002 8758 15576 6772 13030 226 I, 
validation-state: unverified
> to 192.0.2.129 via ge-0/0/1.0
[...]

But none of them make it to the FIB:

root@vMX1# run show route forwarding-table matching 1.1.1.0/24
Routing table: default.inet
Internet:

Routing table: __master.anon__.inet
Internet:

The peer.inet.0 table is empty:

root@vMX1# run show route summary
Autonomous system number: 64512
Router ID: 192.0.2.128

inet.0: 1110 destinations, 1869 routes (1110 active, 0 holddown, 0 hidden)
  Direct:  3 routes,  3 active
   Local:  3 routes,  3 active
OSPF:  2 routes,  1 active
 BGP:   1861 routes,   1103 active

upstream.inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 BGP:  1 routes,  1 active

Adding a static route to peer.inet.0 doesn't help (I added a discard
route). Switching the default to the peer doesn't change anything (term
3 also matches anything). Tested on vMX 14.1R1. Maybe a bug in
if-route-exists?
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp