Meraki

jdsilva · ‎Jun 10 2018

I'm in the back corner at the orientation right now.

jdsilva · ‎Jun 10 2018

... And made it!

jdsilva · ‎Jun 8 2018

That would work. It's effectively the same thing.

jdsilva · ‎Jun 8 2018

Hey @Mju. No, you cannot do this currently with that set up. That method will only provide failover. You would need this type of topology to do what you are asking: https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS

jdsilva · ‎Jun 8 2018

@Mr_IT_Guy Yup, I'll be at both of those events.

jdsilva · ‎Jun 8 2018

Yup! I would love to have this too. I recently brought up a link over some really old OM2 fibre running ~700m using LX optics and mode conditioning patch cables and it would be helpful to know these details to see how strong the link actually is. It is working, and operating at 1Gbps without errors... But I can't say how much room to spare we have levels wise.

jdsilva · ‎Jun 7 2018

I don't think you can... 😞

jdsilva · ‎Jun 7 2018

Right. I amended my reply above for a VPLS (or other layer 2 MPLS service). In that case you're right and it's the same layer 2 domain on both sides.

jdsilva · ‎Jun 7 2018

Sorry @ScottWinCO, the .249 addresses are not on the MXes. I think you've interpreted that incorrectly. EDIT: To clarify, that diagram shows L3VPN. If we have a VPLS service then the second part of your statement is correct and they would not exist.

jdsilva · ‎Jun 7 2018

Those routers look to be the PE routers in an L3VPN service.

jdsilva · ‎Jun 6 2018

I seem to be missing pants... 😉 Thanks for the new shirt and buttons @CarolineS !

jdsilva · ‎Jun 4 2018

Stupid sticky clients 😞

jdsilva · ‎May 31 2018

Hi @StuKoalaIT. I would say no, it's not sensible for the PPPoE settings to be available in the dashboard. I say that because in order for that to be viable the MX needs to be connected to the dashboard to receive the config update. To be connected to the dashboard it needs to have an active WAN link. To have an active WAN link PPPoE needs to be configured. So you end up with needing PPPoE configured to configure PPPoE 😞 Just my $0.02.

jdsilva · ‎May 30 2018

The MX does not have any ALG functionality at all. So if your H.323 is relying on that you're not going to be a happy camper 😞

jdsilva · ‎May 30 2018

AFAIK there's no way to filter what messages are sent. You likely will have to filter this out on the Syslog server side.

jdsilva · ‎May 23 2018

No, you can't add them to the Meraki Dashboard. You have to configure them the same way you always have.

jdsilva · ‎May 16 2018

Cool. Just registered. See everyone there!

jdsilva · ‎Mar 19 2018

I know this isn't the easiest way for everyone, but location can be updated via API. That's really your best option to update en masse.

jdsilva · ‎Feb 22 2018

Just a thought: You can't use AutoVPN between organizations... If you do two Orgs then you have to use non-meraki VPN, and you lose your SD-WAN functionality.

jdsilva · ‎Feb 22 2018

Haha! That's kinda funny. Logs full of blocked porn sites from your workstation... I understand why you wouldn't want that history in there. Though it might be fun explaining to the CIO that it was "For Science!" 😉 If this is really a problem then I'd suggest cloning a new network based on your current settings, move the MX over there, do the testing, then move it back and delete the network. Event logs are network specific so if you do your testing in a dummy network that's been deleted there will be no trace of them going forward.

jdsilva · ‎Feb 20 2018

The MX will pass the tags through without modifying them by default, which from the sounds of things is what you want here. MX version 14.6 added a "real-time queue" for EF traffic. It works automatically and there's on configuration required on your part. There's more details in the release notes if you're interested. Although, if you don't have any QoS handling from your MPLS provider than it doesn't matter anyway. Your VoIP provider can ask you to mark traffic, but if your MPLS provider just ignores them then you're no better off.

jdsilva · ‎Feb 20 2018

Generally speaking you want to mark traffic as close to the source as possible. So ideally you have the VoIP device mark it's own traffic, and then you "trust" those markings throughout your network. Failing that, you mark traffic on the ingress switch port the VoIP device is connected to (in your case, your non-Meraki switches). I'm not clear if you can mark LAN to LAN traffic on an MX using a Traffic Shaping rule. Perhaps someone else can chime in on that part? If you can you'll find it under Security appliance --> configure --> Traffic shaping and go right to the bottom of the page for traffic shaping rules. Might be easiest to use a layer 7 classification for voice, and then mark it to EF.

jdsilva · ‎Feb 16 2018

You can block url's on all MX's if you're using templates... I know, not likely the answer you're looking for but it's the only way currently to do that. Org level policies would be really nice for quite a few things with regards to MX's (I'm looking at you SD-WAN). URL filtering is Brightcloud based. You can submit requests through them. Info is here: https://documentation.meraki.com/MX-Z/Content_Filtering_and_Threat_Protection/Content_Filtering/Content_Filtering_Troubleshooting#How_can_one_unblock_a_site_that_is_being_blocked.3F

jdsilva · ‎Feb 5 2018

Hi fjulianom, You can tell if it's forwarding or blocking by the switch port icon shown on the visual depiction of the switch. If it's forwarding it will show nothing. If it's blocking it'll have a circle with a line through it. This page shows all the symbols you may see: https://documentation.meraki.com/MS/Monitoring_and_Reporting/Switch_Port_View Hope that helps!

jdsilva · ‎Jan 12 2018

Hi Gordon, Just as a point of clarification, the MX84 only has SFP ports, not SFP+. They are only 1Gbps capable and not 10Gbps. I'd hate for you to order the wrong SFP modules if you thought they were SFP+. Jason

About jdsilva

jdsilva

Community Record

Badges