About PhilipDAth

PhilipDAth

You also need to balance your outage expectations with the probability of it happening. For example, the MX84 has an MTBF of 925,000 hours. So you could, on average, expect a failure every 105 years. And that is for a single MX84. So an outage of 30s due to hardware failure once during the entire lifetime of the salesperson wouldn't be acceptable?

PhilipDAth

Have you considered going the other way, and using something like wired 802.1x to only allow authorised devices to connect? https://documentation.meraki.com/MX/Access_Control_and_Splash_Page/MX_Access_Policies_(802.1X) If you have a Meraki MS switch - it's better to do it there. https://documentation.meraki.com/MS/Access_Control/MS_Switch_Access_Policies_(802.1X) 802.1x can be complicated to setup. If you are a smaller organisation and want something simpler, create a firewall that does a "deny any any" - blocking everything. Then create a group policy called "authorised" which overrides this rule granting access. Then apply the "authorised" group policy to those clients allowed to connect. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies

PhilipDAth

You would normally use Meraki's cloud archive system. This doesn't use your cloud. So it would not go into your Azure tenancy. By using the Meraki system you get deep integration with the Meraki dashboard. If they really want to store it in their own tenancy they would have to use RTSP. They would have to deploy their own RTSP receiver, figure out how to get that plumbed into Azure, and then figure out what they are going to use to process the video, watch it with, search with, etc. Really painfull.

PhilipDAth

You have a dedicated fibre run between the locations - so you can run as many VLANs over it as you like. You absolutely can run in warm spare mode. Just put the Internets circuits at each site into a VLAN, and trunk that to both sites. Ditto with the MX LAN connection. Meraki simple.

PhilipDAth

You need to be very careful with this. By "cloud" provider I'm going to assume that your calls are running over the Internet, rather than inside a VPN or something else. Personally, I would only consider providers that use SIP over TLS for their signalling protocol. It is the most bulletproof. The second option would be SIP over TCP. I would avoid any provider that uses SIP over UDP. This is because SIP over TLS and SIP over TCP using connection tracking (thanks to TCP) - so it's possible for the endpoints to detect a failure on their own and rebuild their connection. UDP is meant to be able to handle this - but often does not work well. Back to your question. The simplest case is if you have a single WAN link (and no failover option). You have both MX attached to the same circuit in a warm spare configuration. When failover happens in progress calls are likely to drop. However, within 30s (depending on the failure case, it can be much quicker), the phones will be able to re-register and start accepting calls again. SIP over UDP works fine in this case. SIP over TLS and SIP over TCP will perform as well - but probably better. A more complex example. Leys say you have dual WAN links (for failover, perhaps even using a 4G router or something else) with dual MX. Failing over between the WAN circuits could potentially take 5 minutes. It could also be much quicker. It depends on the type of failure. However SIP over UDP often does not handle redundant WAN circuits, and although your backup circuit will be online the phones won't be able to make or receive calls for ages. Often reboots are required. SIP over TLS and SIP over TCP will usually self recover. Some systems, like Microsoft Teams, do active circuit monitoring and handle either MX or WAN circuit failover beautifully. You get a period when comms stop, and then they resume. The call remains up the whole time. It recovers beautifully. Most (90% IMHO) of cloud-based phone systems aren't as good in this area.

PhilipDAth

If they were not accessible from the same VLAN, attached to the same stack, that suggests the switch L2 forwarding tables were not correct. Usually, that is a rare event. When it happens the entire stack has to be powered down at the same time and brought back up again. Where the servers dual connected as a matter of interest? Have you made the core switch stack the spanning-tree root? https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)

PhilipDAth

Is there a host-based firewall running on the server?

PhilipDAth

Oops, @BrandonS is correct. It should be 514.

PhilipDAth

> port(15146)) It should be using port 500.

PhilipDAth

Were the servers accessible from within the same VLAN that they reside in? Are these physical or virtual servers? You mention switches, are they in a stack?

PhilipDAth

How about using WiFi instead?

PhilipDAth

There is no way an API can exist to enable API access. No such endpoint exists, or will ever exist.

PhilipDAth

Well done everyone!

PhilipDAth

For a subnet you are trying to reach from a spoke, can you show a screenshot of the route it is matching on each of the two hubs (Security & SD-WAN/Monitor/Route Table) as well as for the spoke concerned, please.

PhilipDAth · Azure will need a return route for 172.16.0.0/24. ... View more

Azure will need a return route for 172.16.0.0/24.

PhilipDAth

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/SD-WAN_and_Traffic_Shaping#Uplink_Statistics

PhilipDAth

I would raise a support ticket. I'm thinking support might be able to do this for you. Otherwise, the issue is you need to get a list of the serial numbers, and these don't appear on any of the shipping documentation. You would need to get a bar code scanner and manually scan the whole lot into notepad or something like that, and then bulk claim it.

PhilipDAth

You know the MX67 has 450Mb/s of throughput when there is less than 50 users?

PhilipDAth

If the hubs both advertise the same routes, then the route via the highest priority hub is chosen. If your backup hub advertises more specific routes then it will always be chosen.

PhilipDAth

Even if you didn't win something - well done. Everyone's effort is appreciated.

PhilipDAth

https://documentation.meraki.com/SM/Device_Enrollment/SM_Enrollment_Authentication#Sign_in_with_Google

PhilipDAth

Try something like this in the setup (untested): dashboard = meraki.DashboardAPI( api_key=MERAKI_API_KEY, output_log=False, print_console=False, single_request_timeout=300 ) This appears to be the list of everything you can specify (from reset_session.py): class RestSession(object): def __init__( self, logger, api_key, base_url=DEFAULT_BASE_URL, single_request_timeout=SINGLE_REQUEST_TIMEOUT, certificate_path=CERTIFICATE_PATH, requests_proxy=REQUESTS_PROXY, wait_on_rate_limit=WAIT_ON_RATE_LIMIT, nginx_429_retry_wait_time=NGINX_429_RETRY_WAIT_TIME, action_batch_retry_wait_time=ACTION_BATCH_RETRY_WAIT_TIME, retry_4xx_error=RETRY_4XX_ERROR, retry_4xx_error_wait_time=RETRY_4XX_ERROR_WAIT_TIME, maximum_retries=MAXIMUM_RETRIES, simulate=SIMULATE_API_CALLS, be_geo_id=BE_GEO_ID, caller=MERAKI_PYTHON_SDK_CALLER, use_iterator_for_get_pages=False, 😞

PhilipDAth

You could create a tag with that name, and assign the tag to that device. You could create a second Systems Manager network called "Vacant", and move the unused devices into that.

PhilipDAth

> One thing I am still not clear is: when should I be using v0, and v1? It is very confusing to me. You should exclusively use V1 in anything new. V0 will eventually be turned off.

PhilipDAth

Tips: * Use a single connection to the MX84 to prevent spanning-tree loops. * Configure the HP switch to use MSTP instead of its variant of RSTP. * Upgrade the firmware on the small business switch. * If the small business switch supports it, change it to run MSTP. I don't know about your specific models, but Cisco and HP don't always use the same weights for ports when they run RSTP. This can cause spanning-tree inconsistencies. It can be triggered by simply bring ports up and down in a specific order. For MSTP they do. I have had this exact issue in the past in mixed Cisco and HP switch environments - and changing everything to use MSTP has solved it every time.

PhilipDAth

Community Record

Badges