Meraki

jdsilva · ‎Jul 6 2020

@nickydd9 wrote: I think @jdsilva understands this entirely, he's just trying to get @LuigiJuve to arrive at that answer on his own.... 😃 Shhh! 😉

jdsilva · ‎Jul 6 2020

Hi @LuigiJuve , No where in there did you designate that VLAN as heartbeat. You simply created a VLAN, assigned it a subnet. Can you please clarify what makes this VLAN a heartbeat VLAN different from all the other VLANs? How do you control which VLAN is used for hearbeats?

jdsilva · ‎Jul 3 2020

@RichardChen1 wrote: Check this out: https://www.willette.works/mx-warm-spare/ Yeh... There's falsities in that and I would not recommend you follow that guide. There are some good things in there, but the whole heartbeat thing is not truly possible and very misleading.

jdsilva · ‎Jul 3 2020

@LuigiJuve wrote: I tested many scenarios but the best to get this to work is to have a designated vlan set on the MX for the heartbeat for example vlan 1111 ip 1.1.1.1/30. Can you please show me exactly how you designate a VLAN as heartbeat?

jdsilva · ‎Jul 1 2020

Woohoo nice work @Shadius @Maclanta @MrBear ! Keep it up! @Network-dad very well deserved. You were a power house this month. Well done! Yeh yeh you guys too @PhilipDAth @BrechtSchamp 😛

jdsilva · ‎Jun 30 2020

I obtained my CCNA in 2003. I followed it up with a CCNP in 2006, and have been actively certified ever since. IMO I'm not sure you can compare CMSS and CCNA directly. All the Meraki certs assume you have a CCNA level of knowledge and focus purely on Meraki devices. The CCNA covers vendor agnostic networking fundamentals such as subnetting and routing in addition to the Cisco IOS specifics. A lot of it really comes down to you and your own career aspirations. Generalists and SOHO/SMB IT shops can likely get by with Meraki based training alone, but for anyone who has a desire to get into Enterprise or SP networking then CCNA is a far more appropriate place to start.

jdsilva · ‎Jun 25 2020

I don't know either, and I have never seen it documented in any of the KB pages for this feature. If you need this you're probably best to give support a call and ask them.

jdsilva · ‎Jun 23 2020

Yeh that's odd. Maybe things don't work the way I think they do? Are you doing full tunnel or split tunnel?

jdsilva · ‎Jun 23 2020

@swifty wrote: In fact I was successfully using the SD-WAN, VPN traffic, Uplink selection policy to send particular traffic down WAN2. (otherwise with WAN1 as the primary uplink, WAN2 would never get a look in) So are you saying you're using the VPN Traffic section for Internet breakout traffic?

jdsilva · ‎Jun 23 2020

Netflow is only avaialble on MX/Z devices, do if you're looking at a network that doesn't contain those types then it probably won't be there.

jdsilva · ‎Jun 23 2020

You're looking on the right page, you just didn't scroll down far enough. Under Network-wide > General, there's a Netflow section towards the bottom of the page.

jdsilva · ‎Jun 23 2020

Haha we're going around in circles a bit here. Let's level set here since I see that page has changed a bit since I last looked, so I might not be saying this correctly. The Internet traffic section under Flow Preferences is used to control which WAN interface Internet destined traffic egresses. This section does not impact traffic that is sent over the SD-WAN overlay (AutoVPN tunnels). Here you can override the system defaults for forwarding Internet traffic by selecting a specific interface, or load balance over both. This section has no effect on traffic being sent through an AutoVPN tunnel. The VPN Traffic section under SD-WAN policies is used to control traffic that is forwarded over the SD-WAN Overlay (AutoVPN Tunnels). This section allows you to specify an SLA to attach to the traffic type and make dynamic forwarding decisions based on the conditions of the network. This section aligns with what people think of as SD-WAN. Traffic that matches rules in this section can be monitored on the VPN status page as I mentioned previously. This section has no effect on traffic being sent directly to the Internet (local breakout). The decision on whether to route traffic into the overlay or direct to Internet is based on the routing table of the MX, not by policies in either of these sections. If the AutoVPN configuration is such that the destination network is routed via an AutoVPN partner then traffic is routed into AutoVPN, and then the SD-WAN policies are applied as applicable. However, if no matching route is found traffic will be sent outside of AutoVPN direct to the Internet, using the Internet Traffic Flow Preferences if applicable. What I'm getting from your posts is that you are trying to use the SD-WAN policies VPN traffic section to apply policy to Internet traffic, which won't work. Each section has its specific purpose and configuring a rule in one section for the other traffic type will have no effect.

jdsilva · ‎Jun 19 2020

I'm not even sure I can name 11 types of eggs... But here goes! Fried eggs Poached eggs Basted eggs Scrambled eggs Omelette Quiche Hard/Soft boiled eggs Deviled eggs Pickled eggs Egg salad ... ... ... Um... Easter eggs? Do they count? Welcome!

jdsilva · ‎Jun 19 2020

Yeh if I was to guess, and keep in mind I'm not an electrical engineer, it sounds like something in the ASIC microcode has gone screwy. Updating the switch firmware would only help if that particular upgrade had an ASIC microcode update inside it. You can probably up- and down-grade all over the place and it won't make a bit of difference unless you just happen to hit the right combo to force that microcode update. Again, total wild guess. I have no way to verify my theory, nor does it help you in any way 😞

jdsilva · ‎Jun 19 2020

Hi @Gordon. The MX DDNS feature will use the public IP associated with the given WAN interface. If you have an MX WAN port behind a NAT the DDNS will resolve to the NAT, not to the actual IP of the MX. I've done what you're proposing many, many times. It works quite well in my experience.

jdsilva · ‎Jun 19 2020

Ahh, gotcha. Yeh I assumed you meant AutoVPN traffic. Unfortunately, there is no way to monitor traffic forwarding that's being done through the Internet Flow Preferences section that I'm aware of, at least not in a meaningful way. You can see how much traffic each uplink is passing on the Uplink tab of the Appliance Status page, but that's about it. If you just want to test it to confirm it's working you can create a rule for a device and visit What is My IP to verify that you have egressed the correct WAN interface, but I know that's really not what you're asking. 😞

jdsilva · ‎Jun 19 2020

Yeh @nealgs is correct, you cannot forward one port to multiple hosts. TCP/IP doesn't work that way. No vendor is able to do this. Whatever you did with yoru 1:Many rule it won't do what you think it will do. If you must forward port 80 then you will need additional IP addresses on your WAN. If you have five servers then you need five external IP addresses to forward port 80 five times.

jdsilva · ‎Jun 19 2020

Wow that's bizarre. It's as if the switch stack is unable to populate it's MAC address table and is perpetually doing unknown unicast flooding. Does the MAC address table show anything? I wish I could help, but this one is mostly likely going to have to be dealt with by support unless someone here has encountered it before 😞

jdsilva · ‎Jun 19 2020

Hey @swifty, You can monitor the policy under Security & SD-WAN > VPN Status. The lower section of that page contains "Uplink Decisions" where you can see which flows have been mapped to which uplink, and the reason why they were mapped there.

jdsilva · ‎Jun 18 2020

Totally agree with @BlakeRichardson on this one. Packet capture is the way to go. I would also capture on the MS to compare to the capture from the Mac. https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Packet_Capture_Overview

jdsilva · ‎Jun 17 2020

Hey @Jwiley78, You need a minimum of 3, max of 4. One for the upstream gateway (likely your ISP, but not necessarily) One for the physical WAN port of each MX (two total) Optionally, one IP for the VIP These don't need to be public, but they do need reachability to the Internet, and should all be in the same subnet. The physical WAN IP's are so each MX can maintain a connection to the Meraki Cloud. The optional VIP is used to provide stateful NAT failover. If you do not require statful NAT failover then you can omit this IP and just go with the IP for each physical WAN port.

jdsilva · ‎Jun 16 2020

Uh oh... There goes the neighbourhood. I mean, welcome @noblinkyblinky ! 🙂

jdsilva · ‎Jun 16 2020

Welcome!

jdsilva · ‎Jun 15 2020

6to4 is a tunnel as opposed to translation. The MX doesn't have any way to forward based on IP protocol number so I don't think you're going to be able to do this in the way that's being asked.

jdsilva · ‎Jun 12 2020

Yeh that's odd. I seem to remember leaving it blank in the past too. Maybe try making the VLAN 0, which implies the native untagged VLAN?

About jdsilva

jdsilva

Community Record

Badges