SR2148P rack mount or SKU

  • 1
  • Question
  • Updated 2 years ago
  • Answered
1. Does the SR2148P come with ears (or rack mount included) or is it an extra SKU?
2. Any hints or tips for our first SR2148P deploy with a customer whereby we have multiple AP330s and AP370s with them already?
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
  • confused

Posted 4 years ago

  • 1
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
All Aerohive SR series switches (SR2024P, SR2124P and SR2148P) ship with ears for mounting in a standard rack.

Regarding your question, that is a pretty open ended topic, so I'm not really sure how to proceed. If you have any more specific details I could provide you with some suggestions, but as far as connecting Aerohive APs, they will function pretty much the same as any other vendor's switch. Configure the SR2148P uplinks to the APs as trunk ports with the desired VLANs, PoE is enabled by default, so if that is not needed, disable it. I could go on, but without any details most of my suggestions will be easy ones :)

Hope this helps
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
Thanks @Brian, yeah it was an intentionally open ended question ;) It's more about gotchas' than anything else i.e. certain ports are default factory DHCP enabled for configuration, any weirdness with enabling Spanning Tree or limitations learned from practice v doco. We will indeed use trunks as we do with most APs and tag for user/access VLANs. So the management/native/untagged VLAN on a trunk is the same concept as on the APs and most other vendors then right?
Photo of Jackywong

Jackywong

  • 13 Posts
  • 0 Reply Likes
support
Photo of BJ

BJ, Champ

  • 374 Posts
  • 45 Reply Likes
I'll take a stab at your second question. You probably want to setup a new network policy so you can create new device templates. Additionally, assuming you want this to only perform L2 functionality, set the policy for only switching. That way when you go to configure vlans and trunking, you won't need to associate any addressing, other than your mgt interface. I hope I went in the direction you were headed with your question.

Best,
BJ 
Photo of irldexter

irldexter

  • 37 Posts
  • 1 Reply Like
Thanks @BJ, tips and tricks indeed, the new network policy makes sense ;) Yes we'll be only doing layer2 and app vis with trunking and LACP to firewalls. 

It was more about gotchas' than anything else i.e. certain ports are default factory DHCP enabled for initial configuration, any weirdness with enabling Rapid Spanning Tree Protocol or limitations learned from real world v vendor doco.

So the management/native/untagged VLAN on a trunk is the same concept as on the APs and most other vendors then right? (Without bringing VLAN1 v VLAN0 v untagged in to it :)...  any limitations on ASICs or full line rate non-blocking to the back plane, or should 802.11ac APs be striped across port groups... any tips on flow control, queuing, per-port rate-limiting (any different than APs?)... I guess am looking also for what *not* to do that's _vendor specific_ which might save pain and egg on ones face in front of the client.

Have you found holes in the marketecture yet?