Meraki

Raj66 · ‎Jul 22 2019

Yes, that traffic that is heading to WAN2 IP of the other side is the keepalive traffic to make sure the tunnel is up and again yes, in case of a failover(when WAN1 goes down), the traffic will seamlessly switch to WAN2

Raj66 · ‎Jul 19 2019

Hi @GIdenJoe, That is a good question and a good representation of your thoughts. So, even though there are two tunnels establishes on both uplinks and even while doing active-active VPN, We can only control outbound traffic, the inbound traffic will always come to the primary WAN interface. Let us consider your analogy and assume WAN 1 is the primary WAN interface on both the hub and the spoke (This is configuration under "security & SD-WAN > SD-WAN and traffic shaping") then the traffic will flow in a below-specified way. No SD-WAN policies configured: Traffic will flow from WAN1 of one site to WAN1 of the second site SD-WAN policy configured to send traffic over WAN2: Traffic will from WAN2 of one site to WAN1 of the second site When WAN1 is down, traffic will flow to the WAN2 interface to the spoke site I hope this answers your question, let me know if you have any questions. Cheers! Raj

Raj66 · ‎Jul 15 2019

Hello All, Our internal teams were actively looking into this issue and this seems to have resolved now. There were no incidents fo this happening today. Please continue to use the support hotline number (Found under "help > Get help") or dashboard case creation tool (Help > cases) to open a case with Meraki support. Have a good day! Raj

Raj66 · ‎Jul 12 2019

Sorry for the inconvenience guys. I tried to open a ticket from my organization and it went through fine and also the phone system is working fine. Maybe it is a carrier specific issue? Mine is AT&T and can reach support hotline fine. If you are still seeing issues reaching out to Meraki support hotline, please try to open a ticket from the dashboard. If dashboard case system is also not working, please comment your carrier and also the specific issue you are seeing. We can keep a record of it and see what is happening

Raj66 · ‎Jul 12 2019

Hi @TJG 1:1 and 1: Many NATs will allow you to map a single or multiple clients (you cannot map more than 1 per a single port) to a public IP address but not an entire vlan. However, one way you can achieve this is to configure the public IP as your second Internet connection and then do flow preference so that all the traffic from those VLANs will use the secondary Internet IP and not the default primary https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Troubleshooting_Port_Forwarding_and_NAT_Rules https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Load_Balancing_and_Flow_Preferences#Flow_Preferences Cheers! Raj

Raj66 · ‎Jul 12 2019

The MX will act as the router and will segregate the broadcast domain when you connect the switch to the MX LAN and hence it will not be able to get an IP from the cable modem. You can enable DHCP on the MX itself under "security & SD-WAN > DHCP". The default port configuration for the switches is Trunk with native vlan 1 (Unless you change it). I would suggest to configure port 10 on the MX to the same and enable DHCP in vlan 1 and you should be all set. Let us know how it goes. Cheers! Raj

Raj66 · ‎Jul 11 2019

The MX100 comes with an Internet port and a dual purpose port (port 2 can be used as an Internet port or a LAN port; This setting needs to be changed from the local status page under the configure tab). So, one way I can see you achieve this is by applying those two IPs to two uplinks respectively and then configure flow preference so that VLAN 2 will use WAN IP 2 while VLAN 1 will follow the default WAN IP 1 https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Load_Balancing_and_Flow_Preferences#Flow_Preferences

Raj66 · ‎Jul 11 2019

Hi All, I am confirming that this appears to be a bug and our developers' team are looking into this. @GergelyK Thanks for bringing attention to this 🙂 Cheers! Raj

Raj66 · ‎Jul 11 2019

Hi @GJ1 If you are trying to assign a static Ip (whether public or private) to the AP, you can do that from the local status page of the AP. Once you power up the AP, it will broadcast a default SSID that starts with the name Meraki like Meraki-scanning or Meraki-bad-gateway (If the AP don't get a DHCP IP from the upstream DHCP server). If the AP gets a DHCP IP, it will come online instantly and you can assign the static IP on the dashboard itself. More information in the below-mentioned document. https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page#MR_Series Cheers! Raj

Raj66 · ‎Jul 10 2019

If they are on different subnet range, you need to enable/configure multicast routing and establish a rendezvous point for the multicast traffic to flow in between the broadcast domains. You can see the steps to configure multicast routing in the document that I mentioned above. Cheers! Raj

Raj66 · ‎Jul 10 2019

That seems like the port is flapping. Can you try a different cable or different port on both sides and see if the problem still exists?

Raj66 · ‎Jul 10 2019

Do they still have IP from the same range? Also, if the multicast client and the source are connected to different switches, you need to enable IGMP querier as mentioned in the above document.

Raj66 · ‎Jul 10 2019

Hello, @NJacobe If you have both the multicast source and the clients in the same VLAN, you do not need multicast routing. Just make sure that either "IGMP snooping" or "Flood unknown multicast" is enabled under "switch > switch settings" on the dashboard (Ideally, I would go with IGMP snooping). But if you have clients and the multicast source on different vlans, it is important to configure multicast routing. Check the below-mentioned document for more information on multicast routing. https://documentation.meraki.com/MS/Layer_3_Switching/MS_Multicast_Routing_Overview Cheers! Raj

Raj66 · ‎Jul 10 2019

Hi @MerakiCrazy31 You can leverage syslog to get this information. More information in the below documents https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/Syslog_Server_Overview_and_Configuration Cheers! Raj

Raj66 · ‎Jul 10 2019

Hi @JordanNolan Do you BPDU guard enabled on that port by any chance?

Raj66 · ‎Jul 10 2019

Well done and well deserved. Congratulations!!

Raj66 · ‎Jul 10 2019

Hi @GaryJ You should be able to revoke the client authentication from the client's page on the dashboard as shown in the below-mentioned document. Once you revoke the authentication, the client will be forced to go through the captive portal again. https://documentation.meraki.com/MR/Splash_Page/Revoking_Splash_Page_Authorization Cheers! Raj

Raj66 · ‎Jul 10 2019

@MarcP You should be able to disable that interface. Can you please open a support ticket so that we can investigate further and see what is happening? Cheers! Raj

Raj66 · ‎Jul 9 2019

@AndrewBe The vlans will be spanned to all the switches in that particular network and the broadcast traffic will be passed over. The reason for that is to allow the clients connected to other access switches to be able to pass traffic across. For example, let's take your analogy, if S1 is doing L3 and acting as the default gateway and if you have access ports on S3 configured for VLAN 10 but not on S2, the clients connected in VLAN 10 on S3 will still get an IP address from the DHCP server on S1 (Possible because broadcasts are allowed) and they will be able to go out to the Internet. Cheers! Raj

Raj66 · ‎Jul 9 2019

@SLR The APs are not dependent on the other Meraki products. As long as they are powered and have a proper Internet connection, they will work just fine. Cheers! Raj

Raj66 · ‎Jul 1 2019

Top notch! keep it up, guys.

Raj66 · ‎Jul 1 2019

@ewolf You configured port 3 on the MX68 as trunk port with native vlan 100. Does the native vlan match on the HP switch? In HP terminology, vlan 100 should be untagged on the port where the MX68 is connected. Also, Are you running DHCP server on the MX68? If not, you might want to configure an IP-Helper for the DHCP server, Make sure you have that config in place. Cheers! Raj

Raj66 · ‎Jul 1 2019

Agree with @SoCalRacer that this is not the best of the security methods out there but want to make one correction. While configuring port forwarding we can restrict the allowed remote IPs to the IPs that we trust. Again, not the best of the security options will just get the job done if you are using it once in a while

Raj66 · ‎Jul 1 2019

@tantony Yes, configuring port forwarding on port 3389 to direct traffic towards the private IP should allow the traffic from outside to your computer in the LAN. Yes, you can use DDNS, As long as the traffic is coming to the MX wan IP and a port forwarding rule is configured to allow that traffic inbound, the traffic will be directed to the computer in the LAN. More information about how port forwarding works in MX can be found in this doc https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX Cheers! Raj

Raj66 · ‎Jun 26 2019

Thanks to @AjitKumar for the Analogy. using the same, can you ping the servers at site A from a desktop in a different VLAN in the same site? Did you verify if the servers have a correct default gateway configured with correct subnet information? Also, Can you ping the desktops at site B from the servers at site A? If you do a traceroute, where is it getting dropped?

About Raj66

Raj66

Raj Yarlagadda

Community Record

Badges