- About kevinl
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
kevinl
Getting noticed
Member since May 23, 2018
Kudos given to
Community Record
28
Posts
16
Kudos
2
Solutions
Badges
08-23-2018
06:03 PM
Just curious, do you happen to have an MX upstream of the MRs? If you set a rate limit on the MX, that will apply to the MR clients as well, when accessing the Internet (not for local traffic).
... View more
07-12-2018
11:48 PM
Blake, that's true. I live in a city which is overwhemingly ultra-high-density apartments due to space constraints in Asia, and all the residents have started buying "high power APs" thinking that they'll get better signals. Then there comes the parade of manufacturers advertising 160Mhz channels to make their APs sound faster. What a radio nightmare!
... View more
07-12-2018
11:39 PM
Totally agree with Erik. I wish there was a screen where you could see all the uplinks and realtime traffic graphs simultaneously, like the 16-camera MV view. I am showing my age here but if anybody remembers old-school MRTG that showed all your links and all your traffic on one page - yes, I miss that.
... View more
07-04-2018
03:10 AM
1 Kudo
Ahh, that's the beauty of SD-WAN and the simple load balancing that Meraki provides :) I do insist on carrier diversity - separate ISPs for primary and secondary WAN, because being ex-telco myself I have seen rather..... large....outages impact service. Carrier diversity has saved the places I'm at so, so many times. We use cheap and fast GPON/FTTH links, and with our own diversity setup we can save a lot of money by going with the more affordable links without as much SLA protection, which is expensive, and often does not provide much assurance anyway - the link still goes down, the harm is done, and people have a field day arguing anyway, while the Internet is still down. Interestingly, telcos also have a legal right to do maintenance outside of 'regular' business hours and take your circuit down in my part of the world, for up to 4 hours, as long as they provide adequate notice in advance. Carrier diversity also addresses this issue for 24x7 shops. And for Philip - I have seen one truly interesting scenario where instead of getting static IPs for the MX warm spares, they [names deliberately omitted] got four cheap links with 1 IP address each, going to the same site. We cabled as follows: Primary MX Internet 1 - ISP 1 Primary MX Internet 2 - ISP 2 Secondary MX Internet 1 - ISP 3 Secondary MX Internet 2 - ISP 4 (there is a thrilling backstory to why there were so many lines installed before I came into the picture and they couldn't get rid of them so we used them as best as we could) Interestingly, this configuration actually works. If a primary MX in a warm spare group loses BOTH Internet uplinks, it will also automatically surrender the master role to the spare, provided the spare can still reach the Internet. We found this out the day a backhoe cut three out of four links in the street outside. The probabilities are insane, and it happened anyway. My MX setup stayed up on the warm spare, and I could not believe my luck both ways (with the backhoe and the probability of having 4 links at one site). Now you know how to use up to 4 ISP connections with an MX, although the warm spare's uplinks will be completely idle and cannot be load balanced.
... View more
07-04-2018
02:53 AM
Oh wow, I did not expect that! Sometimes things don't work out the way we expect, but I am super glad it worked out :) 0.0.0.0/0 will send all the traffic (including non VoIP) to the UK, so all traffic coming out of Dubai will be routed through the VPN. A quick "what is my IP" on Google will help you check this. But at least we now know that it works, so that is fantastic, and if you need to fine tune it to transport just voice traffic, you'd be able to adjust the route to be as specific or as broad as necessary.
... View more
06-24-2018
10:52 PM
1 Kudo
Ooh wow, not cool. The only thing I can think of at the moment is to try and send all traffic over the VPN to see if it works. Documentation says that if you add a 0.0.0.0/0 route to the 'private subnets' it will accomplish this feat. Perhaps you can try that to see whether the phone can reach the outside world, and then undo it after you've finished testing? Also yes, you can try adding the PBX to the Fortigate's routing as you mentioned - the Fortigate must be able to reach both the PBX and your Dubai subnet (which you've mentioned it can).
... View more
06-24-2018
10:47 PM
What I want to know, is the cat CMNO certified? Cat Meraki Network Operator, that is.
... View more
06-24-2018
10:44 PM
2 Kudos
What Philip said. My workaround if it's just for testing, is to drop the 5Ghz power to the absolute minimum.
... View more
06-22-2018
03:58 AM
That looks reasonable, although I think you might be able to leave the PBX network out of the Private Subnets since 88.2 IP addresses would be public ones. You mention "I am able to to trace root to UK from Dubai but only to Private network not public, any public traffic goes over local ISP, so it is split tunnel VPN. " This might be the source of the issue - the phone is attempting to reach a public IP address SIP server, but the local MX in Dubai thinks it is on the Internet and thus routes it out of the WAN directly instead of over the IPSec tunnel. Dubai then blocks the SIP server, so you run into this issue. I believe you might need to add a static route to the the Dubai Meraki to say "All traffic destined for the PBX should go through the Fortigate" - I assume 88.2.0.0/16 is your PBX. The Fortigate already seems to know how to reach the world, and can reach the MX (as shown by your traceroute) so I doubt it needs any additional config. For the Meraki it would be in Security Appliance > Addressing and VLANs, there is an option to add a static route. Remove 88.2 from the private subnets before you try this. Try it and let us know how you go :)
... View more
06-22-2018
01:13 AM
1 Kudo
It appears to be a sidechannel attack, via targeted delivery to your endpoint. Content not routed through the MX will, naturally, not be inspected, nor match any available content filtering rules. Perhaps a [Cisco] Umbrella might help? :D
... View more
06-22-2018
12:38 AM
1 Kudo
What you've proposed definitely sounds possible, but us IT folk know that little details sometimes trip us up :) Do you mind if we start with the essentials? I suspect a routing issue. From the IP phone's port - are you able to ping/traceroute the Fortigate in the UK? - are you able to ping/traceroute the PBX? The Fortigate needs to have routes back to your IP phone. The other community members have emphasized the importance of ensuring the phone's VLAN subnet is incorporated into the routing on the Meraki side as well. The traceroute should show your traffic being routed over the site to site VPN, instead of going out through the direct Internet egress (I assume you have split tunnel where local Internet access goes out through Dubai). Lastly, a packet capture from the Dashboard, capturing SIP traffic on the MX, may help aid in troubleshooting. Apply a wireshark filter to capture just the phone's traffic and you'll be able to see where the SIP session is failing to establish. PS: Final solution: lobby Meraki really hard to quickly release a new-generation MC phone that works worldwide. :D :D :D
... View more
06-19-2018
01:22 AM
I mention this issue here as well about band steering being an inexact science: https://community.meraki.com/t5/Wireless-LAN/Our-ap-configuration-Band-selection-5G-priority-but-some/m-p/21856/highlight/true#M3628 I agree with Philip that completely removing it (if you have all 5Ghz devices) is the best way to go. I did that for a corporate network that was all 802.11ac and thus 5Ghz capable. Otherwise, adjusting the power of the 2.4Ghz to reduce it, bearing in mind the effect it will have on your coverage, may help.
... View more
06-19-2018
01:16 AM
Word on the street is that they have enough MX400s stashed away in cold storage to last quite a while ;) They did say 7 year commitment to support after EOL, so I find it quite believable that they'll keep a few extras for folks who need them. But the others are right, you need an identical pair for warm spare. (had a client run into this exact same limitation: they bought one MX400 and now want a spare, but cannot buy any new 400s now)
... View more
06-19-2018
01:13 AM
Unfortunately, band steering is an inexact science. The AP can try and detect whether the client is dualband and offer the 5Ghz band, however it is ultimately up to the client to decide which it wants to connect to. The exact software implementation varies so much by vendor, that it really depends on the client device, what it's running, who it's made by. The key issue is that the 802.11 family of standards specifies that AP selection and roaming is driven by the client, unlike in cellular networks where it is controlled by the network itself. Sometimes clients also insist on locking on to the 2.4Ghz band because they detect a stronger signal and thus prefer it - 2.4Ghz propagates better than 5Ghz. You may want to carefully lower the 2.4Ghz power, bearing in mind the other effects on your wireless coverage area.
... View more
06-19-2018
01:08 AM
Thanks @MRCUR and @Adam! That was very insightful :) I just wanted to mention something that might be worth checking out. Adam mentioned in 4. Security Appliance>Traffic Shaping, shape the subnet and set the bandwidth there. In my experience, I have found that the UI is slightly misleading: it is actually per-CLIENT bandwidth, in the section with Rule #1, Rule #2 etc. where you specify the subnet. I made this mistake before, I thought it was x Mbps for the entire category of clients matched under the rule, so if I set 5Mbps, and had five clients, each would get 1Mbps. What actually happened was that the clients happily went along eating up all the bandwidth leaving me scratching my head as to why the traffic shaper wasn't working, until I found it was actually per-CLIENT: so if I set 5Mbps in that section, every client matched under the rule would get 5Mbps all to itself, and with a hundred clients competing for 100Mbps you can imagine how well that ended on my watch ;) Once I set it to 512Kbps, all the clients actually started to behave and the Internet utilization dropped tons.. The group policies appear to imply one bandwidth limit for all the clients, instead of per-client, however I haven't tested that. It would be great if Meraki could make this explicit and say per-client or per-policy: no substantial change needed, just a couple of words in the UI to reflect that. Let me know if you guys have tested this and what your experiences were!
... View more
06-18-2018
01:10 AM
@Adam, curious about the exact mechanism that you use for the per-VLAN traffic shaping. Is that done by Group Policies, and Bandwidth -> Custom Bandwidth Limit? Then you use the Addressing & VLANs page on the MX to tie each VLAN to the relevant Group Policy? (I was thinking this might be a good answer to clients who complain that unlike classic Cisco Cats, the MS series switches do not have built-in bandwidth limiters so they can't shape bandwidth to what the tenant has paid for) Thanks, Kevin
... View more
06-18-2018
12:59 AM
1 Kudo
Yup, you'd need to build a whole separate Internet uplink. Create the SSID (eg. ITDev), use VLAN trunking to put it on its own VLAN, with its own default gateway and DHCP server - could be a separate MX unit, or just a regular router. Your SSID would need to be in bridged mode so the router/MX can assign a different subnet and different default gateway to devices on the ITDev SSID.
... View more
06-18-2018
12:54 AM
1 Kudo
You could try launching multiple instances of vMX in AWS. Sites 1 to 200 would go to vMX1, sites 201 to 400 would go to vMX2, etc.
... View more
Well said - the only way to test at this point is to break the link and stick a fiber power meter on it, but of course, that's easier said than done, taking down a production link! Inline power monitoring using SFP diagnostics would give us the ability to keep tabs on a link in a non-service-impacting manner.
... View more
06-11-2018
11:07 PM
Thanks! Something we can look at doing in future to eliminate the need for ISP routers :)
... View more
06-08-2018
02:08 AM
I've been pondering an idea and wondering whether anybody has tried this before. ISPs in my part of the world will give you an Ethernet handoff, and it will go to a classical router (name your brand here), which is an additional hassle to manage, since it is not cloud-enabled. The ISP also provides a /30 WAN block of IPs, say 99.99.99.0/30, .1 will be their ISP provider edge (PE) router, and .2 will be your customer edge (CE) router. You will also then receive your /29 "LAN" block of IPs, say 100.100.100.0/29, to use for your devices. Our situation is that a warm spare group of Meraki MX require unique public static IP addresses, so I need that router, and the /30 and /29 blocks of IP addresses, vs using one single IP for both. I want to eliminate the classic router and replace it with say, a MS225-24 since it is basically only ever doing static routing from Gig0 to Gig1, no NAT, no DHCP, no nothing - that intelligence is handled by the MX. The MS225-24 offers baseline Layer 3 routing with 16 static routes - when all I really need is one route (default) and two directly connected interfaces. As a plus, I would kill two birds with one stone - I would eliminate an unmanaged Layer 2 switch and the ISP router and consolidate both into one device. Has anybody ever done this?
... View more
Hey Meraki friends, May I humbly suggest (also done via make-a-wish) support for SFP optical diagnostics? I know the MS have amazing copper cable diagnostics that is immensely helpful, and if you were able to add optical diagnostics, it would complement those perfectly. For a long time, classic Cisco IOS operators have had the command 'show interface transceiver' to retrieve data from SFPs with DOM monitoring - not all SFPs do, in which case the command returns a blank output. But if the SFP is capable of diagnostic optical monitoring, you get a result like this: #sh int trans If device is externally calibrated, only calibrated values are printed. ++ : high alarm, + : high warning, - : low warning, -- : low alarm. NA or N/A: not applicable, Tx: transmit, Rx: receive. mA: milliamperes, dBm: decibels (milliwatts). Optical Optical Temperature Voltage Tx Power Rx Power Port (Celsius) (Volts) (dBm) (dBm) --------- ----------- ------- -------- -------- Te1/1 30.2 3.32 -0.4 -2.8 Te1/2 33.3 3.28 -1.6 -7.6 Te1/3 25.3 3.16 -3.1 -3.6 Te1/4 33.9 3.26 -1.8 -2.7 Te1/7 30.0 3.23 -2.0 -5.2 Te1/8 26.7 3.30 -0.6 -2.7 Of particular use to me is TX and RX power, because one can then check for high optical loss which is frequently a precursor to the problem. As we know, Meraki always makes things easier for the user - so I would recommend a more friendly output, with "SFP does not support diagnostics" if they are not DOM-capable, and a nice table to go with the above output, and the values to be colored green for a good range, yellow for a marginal link (within 3dB of the receive power floor) and red if it is even lower than that (or higher - in case of a mismatched over-powered SFP). Currently, I do this by eye, cross-referencing the SFP datasheets to determine their minimum RX power levels to see if my results fall into an acceptable range. PS: I've been doing a little bit of reading and apparently the DOM/DDM capabilities are standardized according to the SFP MSAs - so it's a well known mechanism. That should make it easier to figure out how to extract the data :)
... View more
06-05-2018
03:02 AM
1 Kudo
+1 on the Cradlepoint, my favorite way to get 4G onto a Meraki. The Cradlepoint has much stronger radios that will pick up and maintain connectivity in situations where lesser devices such as hotspots and USB sticks fail. My own temporary solution is the Huawei E5770 pocket 4G router with an Ethernet LAN port - we are really not sure how this would hold up to long term use though. I use it only for troubleshooting so have no idea what happens if you leave it on 24x7! Teltonika has also got an affordable 4G router that's designed for M2M/IoT but I figure it should work fine with the MX. https://teltonika.lt/product/rut240/#tab-features <5W power consumption, and it is a Linux box at heart with an OpenWRT derivative. I'd use this setup if I was building Meraki MX kits to be taken 'into the field', running off 4G and connecting back to HQ over SD-WAN.
... View more
I think Philip is saying that the ports need to be identical types and configuration. So unfortunately you wouldn't be able to aggregate an SFP port together with a copper port. Even with copper ports, they also need to be configured identically (trunk or access), Dashboard is smart enough that it won't let you accidentally aggregate a trunk and access port, the Aggregate button will be grayed out. Hope this helps :)
... View more
Kudos given to
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 1507 | 06-24-2018 10:52 PM | |
| 956 | 06-05-2018 03:02 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 1225 | |
| 2 | 520 | |
| 1 | 698 | |
| 1 | 1507 | |
| 1 | 686 |
