Re: [j-nsp] MACsec over a service provider

2017-10-27 Thread Chuck Anderson 
Destination MAC 01:80:c2:00:00:03, EtherType 0x888e (ieee8021x) is
eaten by the PE router (MX480).  I'm not sure about the ASR9k at the
other end of the production scenario--it may have the same trouble.

My lab is like this, with the EX2200 substituting for the ASR9k.  The
idea is to have MACsec between the EX4300s, with the middle being
transparent to it.

I got this working:

EX4300---EX2200---EX4300

For the EX2200, I had to configure layer2-protocol-tunneling to allow
the EAPOL 802.1x through:

vlans {
MACSEC-TRANSPORT {
vlan-id 10;
##
## Warning: requires 'dot1q-tunneling' license
##
dot1q-tunneling {
layer2-protocol-tunneling {
all;
}
}
}
}

MACsec comes up fine on both EX4300s and I can ping between them.


But this fails:

EX4300---EX2200---MX480---EX4300

I'm doing simple bridging through the MX, but the MX doesn't support
the mac-rewrite needed (ieee8021x).  Anyone have any clever ideas to
work around that limitation?

On Fri, Oct 27, 2017 at 05:40:57PM +0300, Elijah Zhuravlev wrote:
> Hello
> 
> Ethertypes 0x888e and 0x88e5 should be supported by the switching hw,
> no any other special requirements. 
> Btw keep in the mind macsec overhead, +32.
> 
> regards, Eli
> 
> On Fri, 27 Oct 2017 10:23:01 -0400
> Chuck Anderson  wrote:
> 
> > Has anyone been able to run MACsec over a service provider's Ethernet
> > Private Line (or even just a 802.1q vlan)?  I'm looking at using 10gig
> > ports on the EX4300 or the EX4600/QFX5100-24Q with the MACsec uplink
> > module.
___
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?

2017-10-27 Thread Tim Jackson 
MPLS is now supported on IRB on QFX5100:

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html#jd0e57



On Fri, Oct 27, 2017 at 3:50 PM, Andrey Kostin  wrote:

> Chris Wopat писал 25.10.2017 13:00:
>
>> On 10/24/2017 05:30 PM, Vincent Bernat wrote:
>>
>>>   ❦ 24 octobre 2017 14:29 -0400, Andrey Kostin  :
>>>
>>>
> Straight up saying "don't put public IPs on them" doesn't seem like
>> the best advice to me. You can certainly do this, we do and it's fine.
>> When you craft your RE protection filter you just have to squeeze a
>> bit more space here or there compared to say, an MX filter. You should
>> have this enabled weather you're using public IPs or not.
>>
>> Regarding TCAM programming, it's loud and clear when this happens via
>> a console message and a sev0 syslog message.
>>
>
> Yes, that's true, and we spend a decent amount of time packing lo0 filters
> in a tiny TCAM after discovered that filter input-list silently allows
> everything except the first filter and doesn't generate any complaint.
> So, no objection for public IPs but only careful filter planning required.
>
> --
> Kind regards,
> Andrey
>
> ___
> 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] Using a QFX5100 without QFabric?

2017-10-27 Thread Andrey Kostin 

Chris Wopat писал 25.10.2017 13:00:

On 10/24/2017 05:30 PM, Vincent Bernat wrote:

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




Straight up saying "don't put public IPs on them" doesn't seem like
the best advice to me. You can certainly do this, we do and it's 
fine.

When you craft your RE protection filter you just have to squeeze a
bit more space here or there compared to say, an MX filter. You 
should

have this enabled weather you're using public IPs or not.

Regarding TCAM programming, it's loud and clear when this happens via
a console message and a sev0 syslog message.


Yes, that's true, and we spend a decent amount of time packing lo0 
filters in a tiny TCAM after discovered that filter input-list silently 
allows everything except the first filter and doesn't generate any 
complaint.
So, no objection for public IPs but only careful filter planning 
required.


--
Kind regards,
Andrey
___
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?

2017-10-27 Thread Andrey Kostin 

Vincent Bernat писал 24.10.2017 18:30:

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


At that moment (Feb 2016) it was 13.2X51-D35.3.
Is I can see from the link posted in the thread, MPLS on IRB is not 
supported yet, probably hardware limitation.


Here is the conclusion from JTAC case:
Problem Description :

We use common set of filters on all our juniper devices to protect
control plane and it turnes out there is a strange problem with filter
on QFX switches.

When that input filter list is applied then at least ports tcp/22 and
tcp/179 are world-wide open.

Issue: Filter was not getting programmed in TCAM:

Action taken:

As per our latest communication, we have identified two reasons behind
the filters not getting programmed  First, the filter entries exceeded
the maximum TCAM entries. Second, we observed the the QFX platforms do
not support input-list. Although the config gets committed without any
error, only the first filter gets programmed in TCAM. We also provided 
a

sample configuration to demonstrate the ssh filter.

JTAC engineer's examples provided:


I have tried the following configs in the lab under 13.2X51-D35 and 
14.1X53-D30 and have observed the following:


   Config independent of the group:

set interfaces lo0 unit 0 family inet filter input-list [ accept-ftp 
accept-ssh ]


  Config within group:

set groups common:lo-filter interfaces lo0 unit 0 family inet filter 
input-list accept-ftp
set groups common:lo-filter interfaces lo0 unit 0 family inet filter 
input-list accept-ssh
In both cases, the configuration goes through without any error but 
only the first filter (accept-ftp) actually gets programmed in

the PFE programs as can observed  below:



TFXPC0(vty)# show filter
Program Filters:
---
   Index Dir CntText Bss  Name
  --  --  --  --  


Term Filters:

   IndexSemantic   Name
  -- --
   1  Classicaccept-ftp
   2  Classicaccept-ssh
   3  Classiclo0.0-i
   17000  Classic__default_arp_policer__
16777216  Classicfnp-filter-level-all





TFXPC0(vty)# show filter hw 3 show_term_info
==
Filter index   : 3
==


- Filter name  : lo0.0-i
 + Programmed: YES
  + BD ID : 184
  + Total TCAM entries available: 1528
  + Total TCAM entries needed   : 8
  + Term Expansion:
- Term1: will expand to 1 term : Name "accept-ftp-0"
- Term2: will expand to 1 term : Name "accept-ftp-1"
  + Term TCAM entry requirements:
- Term1: needs 4 TCAM entries: Name "accept-ftp-0"
- Term2: needs 4 TCAM entries: Name "accept-ftp-1"
  + Total TCAM entries available: 1528
  + Total TCAM entries needed   : 8


Even the counters only show the counters for the first filter 
(accept-filter)  and not those for the following filters (accept-ssh)
in the input-list. The following is missing count-accept-ssh-lo0.0-i
.






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.




--
Kind regards,

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

Re: [j-nsp] NXTWORK 2017

2017-10-27 Thread Mike Gonnason 
I enjoyed last year, lots of good talks and good people to talk with; both
other customers and juniper.

-Mike Gonnason
On Thu, Oct 26, 2017 at 6:28 AM Jeffrey Fry  wrote:

> Aaron -
>
> I attended Nxtwork 2016 last year and really enjoyed it.  It is a smaller
> conference, smaller than a NANOG event, but very similar in setup.  There
> are breakout sessions for speakers to talk and take questions, there is the
> main event area where the keynotes are given, and there is a customer
> reception one night as well.  There is also a free testing center there if
> you want to take a test, usually pretty easy to get a seat as well. Food
> was pretty decent as they had hot food unlike Cisco Live where you just get
> boxed food.  Since it is a smaller event, it is way more intimate.
>
> I will be there this year as well as tt is really nice to just see and meet
> my peers.  In our introverted world, it seems as though conferences are the
> one place where many of us can come out of our shell :)
>
>
> Jeff
>
>
> On Thu, Oct 26, 2017 at 8:23 AM, Aaron Gould  wrote:
>
> > https://www.juniper.net/us/en/dm/nxtwork/agenda-and-sessions/
> >
> >
> >
> > Has anyone ever gone to one of these Juniper customer meetings ?  Are
> they
> > good ?  Is this something new Juniper started doing recently?  Is it like
> > Cisco Live ?
> >
> >
> >
> > -Aaron
> >
> > ___
> > 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] STP in spine leaf architecture

2017-10-27 Thread Hugo Slabbert 


On Fri 2017-Oct-27 18:04:36 +0200, Thomas Bellman  wrote:


On 2017-10-26 18:11 (CEST), Hugo Slabbert wrote:


[...] in a general a spine & leaf setup should be L3 for interswitch
links, so any STP should be local to a given switch.  [...]
Here I'm just talking about a vanilla spine & leaf setup, not anything
Juniper-specific e.g. QFabric or VCF or whatnot.


You can also build a spine & leaf setup using TRILL och Shortest Path
Bridging (SPB), in which case you have a single large layer 2-domain.
Not using Juniper equipment, though, since Juniper supports neither
TRILL nor SPB...


A fair point; TRILL was only somewhat in the mix when we were evaluating 
options, but vendor support was hit and miss.  VXLAN ended up being a more 
common and "vetted" solution for L2 across a spine & leaf setup.



I'd be curious about more specific details from folks running QFX in
prod in this type of setup.


You are generally correct though.  Configure your swithc-to-switch
links as L3 ports (i.e. 'interface ... unit ... family inet/inet6',
not 'family ethernet-switching'), and some routing protocol like
OSPF, IS-IS or BGP.  BGP is fairly popular in datacenter settings,
but OSPF works fine as well, as should IS-IS.

Layer 2 domains should be kept to a single leaf switch, and thus you
don't need to run Spanning Tree at all.  And definitely not on your
links between spines and leafs, since that would block all but one of
the uplinks, and give you all the pains of Spanning Tree without any
of the benefits.  (You *might* want to run STP on your client ports and
configure them as edge ports with bpdu-block-on-edge, to protect against
someone misadvertently connecting two L2 client ports togethere.)


Yep; that's our CYA config.


(I don't run a pure spine-and-leaf network myself.  I am trying to
migrate towards one, but we still have several "impurities", and
have STP running in several places.)


We all still have lots of "dirty corners" in our networks ;)

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


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

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

2017-10-27 Thread Thomas Bellman 
On 2017-10-26 18:11 (CEST), Hugo Slabbert wrote:

> [...] in a general a spine & leaf setup should be L3 for interswitch
> links, so any STP should be local to a given switch.  [...]
> Here I'm just talking about a vanilla spine & leaf setup, not anything
> Juniper-specific e.g. QFabric or VCF or whatnot.

You can also build a spine & leaf setup using TRILL och Shortest Path
Bridging (SPB), in which case you have a single large layer 2-domain.
Not using Juniper equipment, though, since Juniper supports neither
TRILL nor SPB...

> I'd be curious about more specific details from folks running QFX in
> prod in this type of setup.

You are generally correct though.  Configure your swithc-to-switch
links as L3 ports (i.e. 'interface ... unit ... family inet/inet6',
not 'family ethernet-switching'), and some routing protocol like
OSPF, IS-IS or BGP.  BGP is fairly popular in datacenter settings,
but OSPF works fine as well, as should IS-IS.

Layer 2 domains should be kept to a single leaf switch, and thus you
don't need to run Spanning Tree at all.  And definitely not on your
links between spines and leafs, since that would block all but one of
the uplinks, and give you all the pains of Spanning Tree without any
of the benefits.  (You *might* want to run STP on your client ports and
configure them as edge ports with bpdu-block-on-edge, to protect against
someone misadvertently connecting two L2 client ports togethere.)

(I don't run a pure spine-and-leaf network myself.  I am trying to
migrate towards one, but we still have several "impurities", and
have STP running in several places.)


-- 
Thomas Bellman 
National Supercomputer Centre, Linköping University, Sweden



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

Re: [j-nsp] Standard practice for customer eBGP peering traffic engineer

2017-10-27 Thread Hugo Slabbert 

Could be they got the idea from a recent NANOG thread on this very topic:

https://mailman.nanog.org/pipermail/nanog/2017-October/092887.html

Won't that cause a loop inside of the provider once the other IBGP 
routers see their own AS number?


The actual prepend would be applied on export, so on the provider's edge 
facing peers, rather than having the prepend applied on initial import and 
floating around the provider's internal routing.


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

On Thu 2017-Oct-26 10:16:42 +0700, Mark Tees  wrote:


Hi Craig,

They are probably referring to prepending the provider AS to certain
other eBGP neighbours not within the AS.

EG: Customer sends prefix X with community Y. Where provider chooses
to advertise prefix X to other eBGP neighbours if they match community
Y then prepend own AS.

https://us.ntt.net/support/policy/routing.cfm
http://tools.vocus.com.au/additionals/communities.htm
https://onestep.net/communities/as3356/

These are convenience methods to assist IP transit customers on
guiding traffic towards their prefixes.

--Mark


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

Re: [j-nsp] MACsec over a service provider

2017-10-27 Thread Elijah Zhuravlev 
Sorry, 32b overhead is for my installation, it may vary.

regards, Eli

On Fri, 27 Oct 2017 10:23:01 -0400
Chuck Anderson  wrote:

> Has anyone been able to run MACsec over a service provider's Ethernet
> Private Line (or even just a 802.1q vlan)?  I'm looking at using 10gig
> ports on the EX4300 or the EX4600/QFX5100-24Q with the MACsec uplink
> module.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> !DSPAM:59f3416c247072063812221!
> 
> 



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

Re: [j-nsp] MACsec over a service provider

2017-10-27 Thread Elijah Zhuravlev 
Hello

Ethertypes 0x888e and 0x88e5 should be supported by the switching hw,
no any other special requirements. 
Btw keep in the mind macsec overhead, +32.

regards, Eli

On Fri, 27 Oct 2017 10:23:01 -0400
Chuck Anderson  wrote:

> Has anyone been able to run MACsec over a service provider's Ethernet
> Private Line (or even just a 802.1q vlan)?  I'm looking at using 10gig
> ports on the EX4300 or the EX4600/QFX5100-24Q with the MACsec uplink
> module.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> !DSPAM:59f3416c247072063812221!
> 
> 

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

[j-nsp] MACsec over a service provider

2017-10-27 Thread Chuck Anderson 
Has anyone been able to run MACsec over a service provider's Ethernet
Private Line (or even just a 802.1q vlan)?  I'm looking at using 10gig
ports on the EX4300 or the EX4600/QFX5100-24Q with the MACsec uplink
module.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp