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

[Richard McGovern via juniper-nsp]

Correction - QFX5110 can now route VLAN/IP to VNI via this configuration:

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

I was no aware this information had been put out there.  Min SW would be 
17.3R3, but 18.1R3-S[latest, now 4] would be recommended.

Please also note this functionality is not yet 100% supported as a Border Leaf 
for EVPN/VXLAN, so full "support" may not be yet available, despite the 
documentation.  I think this may be major reason this support has not yet been 
announced.  At least as far as I know, outside of this one link, I believe this 
is not announced or documented anywhere else.

Today I am using only 10K or MX as Border Leaf.

FYI


Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 4:09 PM, "Richard McGovern"  wrote:

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

I do believe that QFX5110 is not really "certified" as a EVPN/VXLAN Spine.  
Your design is what Juniper refers to as CRB - Centralized Route/Bridged.  That 
is, VXLAN L3 at the core, versus the edge.  The core is generally an IP Fabric. 
 

Do matter what, you would need either MX or QFX10K model to talk to outside 
IP world, at least today.  You could talk server to server with your DC, but 
not outside, which I assume is not what you want.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 9:37 AM, "Vincent Bernat"  wrote:

 ❦ 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] EVPN-VXLAN: Mixing QFX and EX

[Richard McGovern via juniper-nsp]

If you are going to try any code for EVPN/VXLAN testing, I would highly suggest 
using 18.1R3-S4, at least right now.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 4:21 PM, "Vincent Bernat"  wrote:

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

[Richard McGovern via juniper-nsp]

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

I do believe that QFX5110 is not really "certified" as a EVPN/VXLAN Spine.  
Your design is what Juniper refers to as CRB - Centralized Route/Bridged.  That 
is, VXLAN L3 at the core, versus the edge.  The core is generally an IP Fabric. 
 

Do matter what, you would need either MX or QFX10K model to talk to outside IP 
world, at least today.  You could talk server to server with your DC, but not 
outside, which I assume is not what you want.

Rich

Richard McGovern
Sr Sales Engineer, Juniper Networks 
978-618-3342
 

On 4/16/19, 9:37 AM, "Vincent Bernat"  wrote:

 ❦ 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] Mirroring IPv6 neighbor advertisements

[Jason Healy]

On Apr 16, 2019, at 12:46 PM, James Stapley  wrote:
> 
> This is the most relevant SNMP OID I've found:
> https://apps.juniper.net/mib-explorer/navigate.jsp#object=ipNetToPhysicalTable=Junos%20OS=17.3R3
> 
> That all needs to be regularly slurped into a database of some kind, and
> then you need some tools for your support agents / sysadmins to query it...
> 
> I've not yet gone much beyond thinking up the above, but it's going to need
> to be built at some stage!

James,

Thanks for your email.  After messing around a big longer, we finally settled 
on polling, as you mentioned above.

We started out with SNMP, but walking the tables took a fair amount of 
clock/cpu time.  We ran some tests and found that netconf over SSH had less 
overhead in our setup, even when accounting for the SSH setup and teardown.  We 
now have a script that happily sucks up the ND table once or twice a minute and 
parses all the entries.  The netconf output had some additional items (like 
ageout) that help us track adds, refreshes, and deletes (much like DHCP 
discover, renew, and release), which works better for our linear logging.  
Again, you could probably do just as much with SNMP, but this was easier to 
script and had better performance.

We haven't started on the "database" part just yet, but there are some things 
out there that have tried to do this:

http://netdisco.org

No idea if it handles IPv6 yet (been a few years since we've tried it), but on 
v4 it did most of the "accounting" type stuff you mentioned.

Thanks,

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

[Ian via juniper-nsp]

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?

I.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 16, 2019 3:37 PM, Vincent Bernat  wrote:

> ❦ 16 avril 2019 11:04 +00, Ian i2va...@protonmail.com:
>
> 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?

[adamv0025]

> Raphael Mazelier
> Sent: Tuesday, April 16, 2019 3:51 PM
> 
> On 16/04/2019 15:52, Saku Ytti wrote:
> > On Tue, 16 Apr 2019 at 16:35, Vincent Bernat  wrote:
> >
> >> Can you confirm that rpd is answering ICMP echo requests? I find this
> >> surprising as I would have expected the FreeBSD kernel to do that.
> >
> > You're probably right. So more likely is that LC CPU is busy doing
> > programming RPD asked it to do, instead of giving ICMP towards RE.
> >
> 
> This is interesting discussion. It was always unclear to me what are
handled
> by the freebsd kernel, rpd, or the micro junos kernel.
> 
Hi gents,

For those of you interested in all the details around how the transit as
well as host-inbound and host-outbound traffic is handled on juniper MX3D
Trio architecture I'd recommend reading the following FREE book in its
entirety.
https://www.juniper.net/us/en/training/jnbooks/day-one/networking-technologi
es-series/packet-walkthrough-mx-series/
It's an excellent book that will answer, among others, all your questions
around where the ICMP might be delayed in the system and where and how it is
handled.

I'd say it's a must read for all NetEng/Arch working with Juniper MX.


adam



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

Re: [j-nsp] Mirroring IPv6 neighbor advertisements

[James Stapley]

Somewhat late to the party, but I'm thinking about similar things at the
moment. We've not really had too many issues with this in the (many) years
we've been doing production IPv6, but now we're in the process of
considering rolling PI IPv6 out, and more extensively (into student VLANs
[where the naughty lives]), we're thinking about it fairly seriously.

Of course, if you mandated only EUI64 - and no cheating, in some way - that
solves part of the problem, but is entirely unrealistic, overly simplistic
(and possibly undesirable) in practice.

So, we're left with figuring out what the routers know.

If you're running SNMP on your (Juniper) subnet router/gateway device(s),
you can use SNMP to query a mapping between IP addresses and physical (MAC)
addresses - in essence, you're getting some version of the ND table in a
way that you can query remotely without needing to put another random
interface into each subnet or do some kind of port mirroring; this is, to
some extent, reasonably scalable (i.e. if you have shedloads of routers,
you may have multiple hosts polling and processing SNMP).

This is the most relevant SNMP OID I've found:
https://apps.juniper.net/mib-explorer/navigate.jsp#object=ipNetToPhysicalTable=Junos%20OS=17.3R3

It seems to do things like ignore leading zeroes in MAC addresses, so
you'll probably need to handle that.

Now what one needs to do is create a data structure to contain the parsed
information, together with:
1) Time this was the case (because when IP address X was in use by client Y
is often important; hello, Cease & Desist...)
2) Multiple IP to MAC mappings (because there can be many IPv6 addresses
per MAC over time, and at any point in time)
3) Tie in user identity (probably leveraging 802.1X either on wired ports
or through your wireless network) - you ought to then have both username
and MAC.

You can probably extend this in various ways (like perhaps what
physical/logical interface(s) they're learnt on, if that's not obvious from
the IPv6 subnet), if desired.

The joy of this is you also end up with a single source of truth, because
you can, at the same time, build up the same info for IPv4.

Obviously, you'll need to query ALL of your routers.

That all needs to be regularly slurped into a database of some kind, and
then you need some tools for your support agents / sysadmins to query it...

I've not yet gone much beyond thinking up the above, but it's going to need
to be built at some stage!

https://forums.juniper.net/t5/Security/L2-security-on-IPv6/ta-p/322231  has
some interesting thoughts to tackle at more or less the same time, if
you've not (yet) gotten to thinking about that.



James Stapley
Network Architect: I Division
t: +27 (0) 46 603 8849
Struben Building, Artillery Road, Grahamstown, 6139
PO Box 94, Grahamstown, 6140, South Africa
www.ru.ac.za


On Fri, 22 Mar 2019 at 23:21, Jason Healy  wrote:

> We're starting to play around more with IPv6, and one thing we're missing
> is a log of who has which address.  In IPv4 we have DHCP and can check the
> logs, but we're using SLAAC for v6 so that's not an option.
>
> I set up a quick trunk interface with all our VLANs as members and started
> sniffing.  While I'm seeing plenty of neighbor discoveries, I'm not seeing
> any(?) neighbor advertisements.  I'm guessing that because the sniffing box
> doesn't have an address on each VLAN, it's not participating in ND and
> registering for multicast, so we're getting pruned.  IGMP snooping is on by
> default on all VLANs.
>
> I'd prefer not to have to add an interface on each VLAN just to grab all
> this traffic (more to keep in sync, security concerns, etc).  Is there a
> way to tell the switch to force IPv6 multicast traffic for ff02::1 to go to
> a specific port?  Our core is a QFX5100; the other switches in the network
> are a mix of EX3200/4200/3400.
>
> For the moment I've got it to work by setting up firewall filters on each
> VLAN in our core and port-mirroring just the ICMPv6 (type 136) traffic to a
> monitoring port.  That works, but it's also a lot of configuration
> overhead.  If there's a better way, I'd love suggestions!
>
> Thanks,
>
> Jason
> ___
> 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] What exactly causes inconsistent RTT seen using ping utility in Junos?

[Raphael Mazelier]

On 16/04/2019 15:52, Saku Ytti wrote:

On Tue, 16 Apr 2019 at 16:35, Vincent Bernat  wrote:


Can you confirm that rpd is answering ICMP echo requests? I find this
surprising as I would have expected the FreeBSD kernel to do that.


You're probably right. So more likely is that LC CPU is busy doing
programming RPD asked it to do, instead of giving ICMP towards RE.



This is interesting discussion. It was always unclear to me what are 
handled by the freebsd kernel, rpd, or the micro junos kernel.


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

Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?

[Saku Ytti]

On Tue, 16 Apr 2019 at 16:35, Vincent Bernat  wrote:

> Can you confirm that rpd is answering ICMP echo requests? I find this
> surprising as I would have expected the FreeBSD kernel to do that.

You're probably right. So more likely is that LC CPU is busy doing
programming RPD asked it to do, instead of giving ICMP towards RE.

-- 
  ++ytti
___
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