EX2300-C-12P PoE issues
Chris Lee
chris at datachaos.com.au
Fri Sep 20 18:53:56 EDT 2019
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 <rmcgovern at juniper.net>
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" <chris at datachaos.com.au> 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 at z> show configuration poe
> management static;
> interface all {
> maximum-power 12;
> }
>
> Regards,
> Chris
>
> On Thu, Sep 5, 2019 at 8:34 PM Chris Lee <chris at datachaos.com.au>
> 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
> >
>
>
>
>
More information about the juniper-nsp
mailing list