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] EX2300-C-12P PoE issues

[Chris Lee via juniper-nsp]

--- Begin Message ---
Hi Rich,

Thanks for that, LLDP-MED did come into my mind at one point as one of our
EX2300-C's has 10x Axis cameras that all do have LLDP enabled, and this
switch indeed has LLDP and LLDP-MED enabled on all interfaces, but I was
probably a little haphazard in my approach to troubleshooting it since we
were keen to just get it going. I just looked up in the Axis FAQ they do
indeed use it "AXIS products as of today utilize LLDP-MED to further
negotiate power according to IEEE 802.3at when connected to a 30W PoE+
switch."

Will keep that in mind if this comes up again that we could try disable
LLDP-MED, otherwise I'm just as happy to manually configure the PoE as
static on all ports.

I did try lab this up yesterday on a EX2300-C to simulate it, all I could
gather was 9x Meraki MR18 and 1x Meraki MR42 access points, and found that
the MR18's all join as Class 0 devices, and the MR42 as Class 4 device, and
all 10x WAP's would boot up from PoE (even though there was 9x 15.4W max
power across the MR18 ports and 1x 30W max power on the MR42 port) and
similarly after rebooting the switch I just couldn't re-create what we'd
seen with the Class 3 PoE cameras.

JTAC's explanation to me was that max power consumption of PoE devices with
class 0 and 4 is calculated by their actual power consumption, whereas
class 3 is calculated by their max power per port if using PoE management
by class.

Your LLDP-MED explanation does make more sense to me however as that
appeared to be what I was seeing where we still weren't quite at the max
PoE budget and at least one or two more cameras should have come online by
my calculations but wouldn't which must be that additional ~10% reserve
keeping it offline.

Cheers
Chris

On Sat, Sep 21, 2019 at 3:15 AM Richard McGovern 
wrote:

> Chris what is actually happening here is not so much class setting but
> LLDP/LLDP MED.  By default EX switches support LLDP MED POE-Negotiation,
> and use this method 1st.  So whatever wattage the external device requests
> is taken into the total power budget.  Once the switch calculation for
> these reaches max POE for the switch, no additional POE power will be
> provided.  This is even if the device pulls much less power than it
> negotiated for or asked for.  The switch needs to reserve that power
> calculation as a 'just in case'.  We actually reserve more than the value
> with LLDP MED tlv, to account for potential cable loss; this is
> approximately 10% more.
>
> So if you disable LLDP MED, then class value will take over, and there is
> no need to set static.  Of course setting static is always an option, and
> if set that value is used regardless of other settings.
>
> FYI only, 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
>
>
> On 9/5/19, 8:49 PM, "Chris Lee"  wrote:
>
> For the benefit of the archives have found a solution for this, it
> appears
> to come down to power budgets and defaults of class based PoE
> management.
> Have never noticed this before as on all our 24-port EX2300 and 48-port
> EX3400 and 4300's there's always at least sufficient total power
> budget to
> allocate 15.4 watts across every interface.
>
> So class 3 devices allocated 15.4watts of power theoretically means you
> could effectively only have 9x class 3 ports power up with a total of
> 138.6
> watts, unfortunately I currently don't have enough class 3 PoE devices
> in
> the lab to fully test this theory, and what I saw in the field was the
> switch would only provide power to the first 7x ports even though
> there was
> still sufficient power remaining to allocate 2x more ports, maybe it's
> something to do with internal power bank architecture/design or
> additional
> power reserves per class 3 device.
>
> The workaround was to define PoE management type as static and set max
> power for all interfaces to 12 watts, and then the remaining cameras
> interfaces ge-0/0/7 to 9 that previously wouldn't power up all started
> fine
> and are online. Note there's a bit of lag even after committing the
> configuration, seems to take a minute or two for the config change to
> flow
> onto the PoE controller and reflect the change from class to static
> management with max power of 12 watts defined.
>
> z@z> show configuration poe
> management static;
> interface all {
> maximum-power 12;
> }
>
> Regards,
> Chris
>
> On Thu, Sep 5, 2019 at 8:34 PM Chris Lee 
> wrote:
>
> > Hi,
> >
> > Wondering if anyone is successfully running EX2300-C-12P switches
> with at
> > least 8x PoE devices connected ?
> >
> > We've just encountered an issue in the last week across 2 of these
> > switches at different locations with around 10x PoE CCTV cameras
> connected,
> > and only the first 7 

Re: [j-nsp] EX2300-C-12P PoE issues

[Richard McGovern via juniper-nsp]

--- Begin Message ---
Chris what is actually happening here is not so much class setting but 
LLDP/LLDP MED.  By default EX switches support LLDP MED POE-Negotiation, and 
use this method 1st.  So whatever wattage the external device requests is taken 
into the total power budget.  Once the switch calculation for these reaches max 
POE for the switch, no additional POE power will be provided.  This is even if 
the device pulls much less power than it negotiated for or asked for.  The 
switch needs to reserve that power calculation as a 'just in case'.  We 
actually reserve more than the value with LLDP MED tlv, to account for 
potential cable loss; this is approximately 10% more.

So if you disable LLDP MED, then class value will take over, and there is no 
need to set static.  Of course setting static is always an option, and if set 
that value is used regardless of other settings.

FYI only, 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
 

On 9/5/19, 8:49 PM, "Chris Lee"  wrote:

For the benefit of the archives have found a solution for this, it appears
to come down to power budgets and defaults of class based PoE management.
Have never noticed this before as on all our 24-port EX2300 and 48-port
EX3400 and 4300's there's always at least sufficient total power budget to
allocate 15.4 watts across every interface.

So class 3 devices allocated 15.4watts of power theoretically means you
could effectively only have 9x class 3 ports power up with a total of 138.6
watts, unfortunately I currently don't have enough class 3 PoE devices in
the lab to fully test this theory, and what I saw in the field was the
switch would only provide power to the first 7x ports even though there was
still sufficient power remaining to allocate 2x more ports, maybe it's
something to do with internal power bank architecture/design or additional
power reserves per class 3 device.

The workaround was to define PoE management type as static and set max
power for all interfaces to 12 watts, and then the remaining cameras
interfaces ge-0/0/7 to 9 that previously wouldn't power up all started fine
and are online. Note there's a bit of lag even after committing the
configuration, seems to take a minute or two for the config change to flow
onto the PoE controller and reflect the change from class to static
management with max power of 12 watts defined.

z@z> show configuration poe
management static;
interface all {
maximum-power 12;
}

Regards,
Chris

On Thu, Sep 5, 2019 at 8:34 PM Chris Lee  wrote:

> Hi,
>
> Wondering if anyone is successfully running EX2300-C-12P switches with at
> least 8x PoE devices connected ?
>
> We've just encountered an issue in the last week across 2 of these
> switches at different locations with around 10x PoE CCTV cameras 
connected,
> and only the first 7 ports (ge-0/0/0 to ge-0/0/6) providing PoE power.
>
> One switch is running JUNOS 15.1X53-D591.1 and the other is JUNOS
> 18.1R3-S7.1.
>
> Both have had the PoE firmware controller update done on them that comes
> with releases beyond 15.1X53-D58 I think it was, which when you look at
> firmware detail the PoE version on chassis is  2.1.1.19.3
>
> I have an active JTAC case open for it, I've done PR Search and can't see
> anything against POE or Power for either of those two releases that relate
> to the EX2300/3400 series.
>
> In both cases the PoE cameras on the end of the line are very low power
> bullet / fixed style cameras only drawing around 3 watts each, and the 
most
> I've seen reported on show poe controller is around 25 watts power draw
> which is no where near the EX2300-C-12Ps max power budget of 146watts.
>
> If I deliberately disable PoE on an interface like ge-0/0/0, then after a
> minute or so interface ge-0/0/7 will then magically start providing power,
> and as soon as I rollback the config and commit it will revert right back
> to port ge-0/0/7 providing no power, and ge-0/0/0 powering up.
>
> Thanks,
> Chris
>



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

Re: [j-nsp] Suggestions for Edge/Peering Router..

[Eric Van Tol]

On 9/19/19, 1:05 AM, "juniper-nsp on behalf of Phil Reilly" 
 wrote:

MX104's are the dual brain unit of the 204. Though a 204 has 40/100G 
capabilities. If I read your original request correctly about ip 
routing. Not sure the 104/204 is grunty enough to deal with multiple 
internet tables. Thats a demanding task these days best left to the 
larger chassis.

The MX204 should work fine with multiple full table peers. The MX104 is the 
dual-RE version of the MX80 PPC-powered router. The MX204 is essentially an 
MPC7E, has a 64-bit Junos that runs the OS in a VM and has 16GB of RAM. MX204 
is pretty powerful for what it is, which is a 1U router with 100G/40G/10G/1G 
capabilities, but you cannot use all ports simultaneously if you enable 100G or 
40G. It's a bit convoluted, but it's explained here:

https://www.juniper.net/documentation/en_US/junos/topics/concept/port-speed-capability-mx204router.html

They offer a port-checker tool to verify configurations here:

https://apps.juniper.net/home/port-checker/index.html

-evt

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

Re: [j-nsp] EVPN on QFX5200

[Andrey Kostin]

Hi Vincent,

Thank you for elaborating on this, I had the same question when read 
your reply.
It may be not an issue for a small deployment but definitely should be 
considered in terms of BCP.


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?


Kins regards,
Andrey


Vincent Bernat писал 2019-09-20 02:25:

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

___
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