Silly Meraki Tricks: LAN Hairpin NAT (Sort of)

Working with Meraki these last two years has led me to discover a few oddities in the way things work. Often, these silly little tricks can be used to solve problems, but they also may lead to unintuitive configs. Either way, I don't understand why I haven't posted them here before. You will likely find anything that I post under this moniker something I've already posted about over at the Meraki Community, and I will link over to the full conversation where there is one.

For my first Silly Meraki Trick I will show you how to get a NAT translation for LAN to LAN traffic on an MX appliance.

Meraki Community All Stars

Over at the Meraki Community a new program has been created to recognize and acknowledge community members who dedicate their time and expertise to participating in the discussion and helping to make the community a great place to learn about Meraki products. Here is the announcement:

https://community.meraki.com/t5/Community-Announcements/Announcing-the-Cisco-Meraki-Community-All-Stars-Program/ba-p/49508

I'm quite honoured to have been included in the first cohort of Meraki Community All Stars, so I thought I'd make a post about it!

Meraki Action Batches in Action

As promised in the previous post, here's a quick sample Action Batches script.

I've actually got two for you. Both scripts create two new networks, and then create five VLANs inside those two networks. The script 'example1.py' creates all of this using individual API calls for each create action. The 'example2.py' script uses action batches instead of individual API calls.

For fun I'm also using timeit to compare how long each script takes to do the same thing.

Action Batches in the Meraki Dashboard API

Just announced at Cisco Live '19 on this past Thursday is a new Meraki Dashboard API feature called Action Batches. This was announced during BRKRST-1733 on Thursday morning with Tony Carmichael and Shiyue (Shay) Cheng, two of Meraki's finest when it comes to their API. There's been some talk that this feature was coming, and I was very interested to see what the initial implementation was going to look like. Well, now that it's here we can take a look!

Setting up a Google Chromecast Without the Home App

Let's be clear on one thing: I am not a developer.

 I am dangerous with bash, PERL, and, increasingly, Python. Given the state of the world, gaining skill in writing code is high on my priority list. But all that self-loathing disclaimer and wishful thinking aside...

 I've been doing a pile of work lately with Chromecasts. Ya know, those cute little dongles you connect to you TV and stream stuff to. Yeah, those. Well, as it turns out there's an undocumented API that you can use to do all kinds of things on them. Most of these undocumented APIs are documented in various places around the Web. I used these, in conjunction with a little of my own packet sniffing to figure out how to setup a default Chromecast without having to use the Google Home app. I took this derivative work, and piled it all into a bash script that seems to do the job (read: there's MASSIVE room for improvement, but hey running code rules the world, right?).

 As this is an undocumented API this is totally use at your own risk. I am not liable for any unexpected consequences, or if the API endpoints happen to change at any moment. This worked today, but I make no promises about tomorrow.

Let's Encrypt for Meraki Webhooks and Scanning API

Yesterday Meraki sent out a notification to their customers that they were updating their Scanning API and webhooks features to only allow HTTPS based receivers. No more unencrypted HTTP. This, naturally, makes sense since there's potentially sensitive customer and configuration data being sent over the Internet with these features, so I applaud Meraki on taking this step.

But, I've done a bunch of testing and PoC work with those APIs using HTTP. Shame on me for doing it unencrypted, but, well, things are hard. OK, not really. So I'm glad Meraki has pushed me to tighten up my own testing environment. Since before today I didn't have a certificate I could use to do this, and I spent the morning hammering this all out, I thought I'd put this here in case you find it useful.

Renewal, Rebirth, Reflection and other words that start with Re-

I just signed into Blogger for the first time in a hell of a long time. I see in my published posts list that my ultra-cynical assessment of the CCIE V5 update was posted in 2013... 5 years ago!

I'd state the rhetorical 'What happened?!?" question here, except I know what happened. After my fifth failure on the CCIE R&S lab exam I withdrew from blogging, Twitter, and the wider networking community in general.

I just hit a wall.

I've thought often about resurrecting this blog, but never followed through. I enjoyed publishing little bits of knowledge while I was chasing the CCIE, and I enjoyed the community that came along with being being a blogger. But yet I just never was able to find the motivation to actually start publishing again.

So, here am I now, sitting in MCO after my first time attending #CLUS feeling re-energized and re-engaged with networking technology and back to again thinking about actually putting some effort into this dilapidated corner of the Internet. 

Let's see if I actually follow through.

BGP Conditionally Injected Loops

While writing up the previous post on BGP Conditional Route Injection I got an idea while I was verifying the information in the post. I thought I saw a way for a loop to form in that the injected route would be learned by a router making it send traffic in the wrong direction.

It turns out I was right.

BGP Conditional Route Injection

This is one of those “complicated” configs. There’s a bunch of typing involved, and the syntax need to be just so.  I labbed this up tonight and it didn’t work. I proceeded to stare at my config for the next 30 minutes before I saw my error. This, my friend, is how you fail the TS section. So in the hopes that I don’t pull the same stunt with this feature come Lab day you folks are now treated to another blog post!

RIP Distribute-lists and the Extended ACL

Here’s a neat trick that’s an easy one to screw up or forget the syntax on.  In RIP (and EIGRP as well I believe) you can use an extended access-list to filter out specific routes advertised by specific neighbours.  This is done using the source and destination fields of the extended ACL to specify source of the routing update, and the route(s) you want to filter respectively.

Example after the jump.