Total Noob needs help getting started

[Jujubee]

I just started a new job and 5 Meraki MS130's showed up (ordered by the previous guy).  I have experience with Catalyst switches using CLI.

How do I make a physical connection to these devices using a console cable?  There is a port on back with a wrench next to it but when I connect the console cable and fire up teraterm nothing displays.

I have googled and found nothing that helps.  Seems this is a closely guarded secret...

J

[RWelch]

Getting Started with Meraki 

[Jujubee]

Thanks for the link.

[double_virgule]

Most configuration is intended to be done from the Meraki Dashboard. 

https://documentation.meraki.com/MS/MS_Overview_and_Specifications/MS130_Datasheet

1. Claim the device to an Organization on the Meraki Dashboard
   1. If a Dashboard Organization does not yet exist, Create one
2. Add the device to a Dashboard Network 
   1. If a Network does not yet exist, Create one first
3. Physically connect the device to the local network
   1. Connect one of the RJ45 or SFP/SFP+ ports to existing infrastructure to provide a temporary uplink
   2. Power on the device and let it check in to the Dashboard
   3. If necessary, configure a Static IP through the Local Status Page to allow it to communicate with the Meraki Dashboard.
4. Allow the device to complete check-in and perform any initial firmware upgrades
5. Finish configuring the device from the Meraki Dashboard 
   1. Manage local VLANs / Port configuration

[Jujubee]

Thanks for the details.  It took me over 1 hr to figure out how to create a simple VLAN.  Would have been 15 seconds at CLI.  I am not a fan of GUI, give me terminal any day.

[double_virgule]

Oh, I was appalled when I realized how little configuration you can do on the local level if not connected to the portal, especially coming from another vendor where I had full CLI on the device. 

Just means we call Cisco Meraki Support for more stuff. 😅 

[cmr]

@Jujubee with Meraki switches, all VLANs are already there, just assign one to an access port or more to a trunk port.  It is actually very simple once you get used to it.

[JustinH]

It's definitely a transition from CLI to GUI.  Give GUI a good chance; you'll get faster/better at it.  And if you need a CLI "fix," you can do a lot of stuff through the Meraki APIs as well.

[IvanJukic]

"Would have been 15 seconds at CLI.  I am not a fan of GUI, give me terminal any day."

That's what I said when I started at Meraki... Now?... I won't go back to CLI ever. The Meraki Dashboard wins hands down.

'Want to enable a new VLAN across multiple sites?'. Can be done in less than 15 seconds. 
'Want to see why all of a sudden end users are complaining about slow speeds?. The Meraki Dashboard gives you a nice live toplogy view of the network and you can see if a device is misbehaving or it's just a subset of clients only'
"Firmware upgrades for remote sites with only a Satelite link?' Dashboard does all the work.

Honestly. Go through our Documentation site. Very easy to read, images of configs examaples. We even have videos showing you how to set things up.

https://documentation.meraki.com/Getting_Started_with_Meraki

Anyway, hope you enjoy the journey. 

[GIdenJoe]

Well I personally would not put it that way.
After years of working with Meraki, still having access to the CLI is very pleasurable.

I believe the full satisfaction for both kinds of people will come when the native IOS-XE with conf t based Meraki management will be available on a stable level.

I also come from a netacad background sinds 2015 and CLI was the main thing and you really could get stuff done quickly and more easily troubleshoot using debugs.

The thing is, yes Meraki is very easy to work with and once you know your way around you can very quickly get entire networks running.  However these are the detractors:
- Configs are done out of band and you can't really control when the config is actually applied on the device.
- You can never be 100% sure if a config actually took on the device. (we had instances of ports not behaving like the config we pushed, needing to revert and push again).
- Having strange disconnects between management IP's and actual routing SVI's and why you need both and they have to be separate.
- When doing actions that by accident cuts off the switch from the dashboard you are not 100% sure what happened and where the switch was stuck.  In CLI you immediately now at what command you just fumbled 😉
- Switches only be configurable from the dashboard sometimes get stuck on TCP/443 while they have full access to the internet and not being able to push the switch doing the connection instantly.  So the switches sometimes just do nothing but ARP to the gateway and get responses back.

[IvanJukic]

Hi @GIdenJoe ,

Those are some valid points you make. And there are certain business and use cases where an Airgap soultion is better suited than Cloud based. However, I would argue that;

- "CLI you immediately now at what command you just fumbled". This is not always the case. In the Configuration Shell the problem might not error or be seen in Syslog at all. E.g. if there is a certain traffic flow conditions being hit and the configuration is 'correct' you won't be able to see it from that Shell. i.e. Logs will need to be pulled from the controllers on the Line Card or Module directly. This can be very tedious & time consuming to discover this condition at all. 

- Regarding the disconnects to Magagement and or the devices. I have certaily worked on cases where, sites are out in the sticks, only have Sateliete (RTT of 300ms) and perfrom very well all things condisered. That customer had the the proper design considerations in place to achieve this. i.e. VLAN Pruning, STP following best practice, traffic shaping policy in place. etc.

Yes, things can go wrong sometimes. Which is why i love the Dashabord, because you can very quickly discover these then spend the time drilling into root cause.

Just my Two Cents.

[GIdenJoe]

To clarify, I work both solutions and love both.

- What I exactly mean with the fumble is that when you accidentally lockout your access to a switch on CLI you are immediately aware since the terminal no longer responds.  On dashboard it would take a few page refreshes to see the status of your switch change.

- About the devices taking long to enroll into dashboard:  I work in the Flanders region of Belgium.  This region is densely populated and there aren't many sites that are 'in the sticks' 😉  We do have decent internet practically everywhere.  Sometimes the behavior of a Meraki device or even a Catalyst device set in Meraki management mode take a really long long time before fully connecting to dashboard.  On an MS or MR this can be resolved by a quick factory default.  However on a catalyst device you're in for a long long while.  The LSP usually says the device still has to reach dashboard op TCP/443 while there is no firewall blocking anywhere.  And when you capture the traffic you don't see the device actively trying to establish the connection but only some pings to 8.8.8.8 and ARP's between gateway and the device.  It would be awesome if we could get a live debug on the LSP that actually tells what the device is doing and where some errors are occuring.

The main gripe I have with Meraki gear is that alot of the 'magic' is hidden from us so we cannot learn what the device is actually doing.  A catalyst style debug would be greatly appreciated, so magic becomes science once again :).

[GIdenJoe]

Few beginner tips:
- All Meraki switchports start with switchport mode trunk, switchport trunk native VLAN 1, switchport trunk allowed all or 1-996 and all VLANs are already made.
- If possible configure your switch before connecting to the cloud
- Have a small DHCP pool in your desired switch management VLAN so a new switch or factory defaulted VLAN can automatically grab an IP to fetch it's config.
- Have the downstream port where you bootstrap your switch trunk native VLAN, your switch mgmt vlan so the switch can get it's config natively.  It will then move it's mgmt VLAN to the configured VLAN while having it's uplink port on the desired trunk configuration too.
- On the switch -> switchports page, always have the column tags visible.  And apply several tags to your ports for easy bulk selection.  I personally tag all my access ports with "ACCESS" and then another tag with the VLAN name.  My trunk ports towards AP's usually have the tags "TRUNK" and "AP".  This makes configuring ports over multiple switches a breeze since you can select all ports based on your tags over all switches inside a single network at once and apply changes at once.

[cmr]

@GIdenJoe great set of tips there 👍👍👍. Unfortunately I can only give you 2 Kudos.

[CarolineS]

I added my kudo for ya 🙂

[cmr]

@AmyReyes can we perhaps get @GIdenJoe's post starred up the top of the switch section?

[AmyReyes]

@cmr I like that idea! These are great tips that would be helpful to feature for others. @GIdenJoe could you please copy+paste your reply as a new post on the "New to MS" thread here?

so that way all our helpful newbie resources can live in one place!

Thanks again for being such helpful members and sharing your knowledge 😄 and @Jujubee for getting this conversation started by asking questions!

[GIdenJoe]

I'll try to add some screenshots while I create the reply.  But you are welcome to create some professional looking mini-course if you want 😉

[JustinH]

For beginners, there is a Getting Started with Cisco Meraki webinar scheduled for Thursday 12/12 at 9:00am PST.