Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Jimbo1
Jimbo1
Here to help
Member since Jan 2, 2018
Sep 27 2021
Community Record
16
Posts
0
Kudos
0
Solutions
Badges
Aug 30 2021
1:41 AM
@Bruceis the reason for your suggestion of a single link (configured as a trunk) rather than a dual link (one link as transit VLAN, the other as L2 Management) purely down to port economy, or something else?
... View more
Aug 23 2021
7:57 AM
@DarrenOC @Bruce Thanks for the information on the use of separate physical connections for VLAN 1 and the transit VLAN. I've focussed on doing it that way, and though it costs me a little address space, it makes migration simpler and I really don't want to encounter issues ("We’ve tried it the other way round and it has caused issues during deployment."), this is a running network and I want to minimise any outage. More when I have it! J
... View more
Aug 23 2021
4:49 AM
Hi Bruce, The upstream security is provided by a Firepower firewall, perimeter security is a combination of .1x, PSK and splash on the wireless, .1x, MAC and physical security on the wired.
... View more
Aug 23 2021
2:25 AM
Hi Bruce, You wrote " a /30 point-to-point link as a transit VLAN on the link, and then another VLAN (normally the native VLAN) which is the management VLAN. The management VLAN then has its Layer 3 interface on the upstream network, whether that’s an MX or something else (e.g. a Cisco router)." Can you clarify for me: are you saying run two physical links with 1) one physical link carrying a L2 link to the upstream firewall (a Firepower) for the management VLAN; 2) another physical L3 link for the other VLANs? That would be a good solution, if I could, for instance, use addresses in the 192.168.0.0/24 space for the L3 link and 10.0.0.0/8 for the VLANs. However, I'm constrained by the uplink supplier, which does not allow that, which is why I wanted to use management addresses for the L3 transit as well
... View more
Aug 23 2021
12:44 AM
I hope this is a simple question, just a matter of (hopefully) confirming what I have gathered from documentation: If I'm migrating a L2 network to L3, I will need to put L3 interfaces on my core switch, and I'm going to need a transit L3 link between the upstream network and the L3 core switch. Ignoring routing for the moment (I can use static/default or OSPF if needed) , can the transit link addressing be part of the management VLAN. Asking the same question another way, can I take two unused addresses from the management VLAN scope and use them for the uplink? So for instance, if the management scope is 10.1.1.0/24, and my core switch management address is 10.1.1.1/24, can I use 10.1.1.100 and 10.1.1.101 for the uplink? Thanks Jim
... View more
Labels:
- Labels:
-
Layer 3
Aug 18 2021
12:26 AM
I hear what you are saying, and it makes sense....except if I NAT between a 10 address and a 172 address, I'll end up double NAT-ing, which I would like to avoid. I'll advise further after I've spoken with the supplier, but imposing another router/NAT in the path may be the only wy forward if they are unwilling/unable to give addresses 😞
... View more
Aug 17 2021
11:30 PM
Sorry, I should have mentioned, this is the situation: the network is in an academic environment, and the "ISP" is a "specialist" academic services provider. They have provided an Internet link with a public outside address, and a very restricted inside subnet in the 10.0.0.0/8 range (its actually only a /21). As far as the network manager can tell me, they have shared the whole of the 10 network out across this and other academic sites, so they are limiting what they can/will provide to keep control of the address space. I'm still digging into the way this provider works, and have been trying to speak to them direct (rather than through my customer's representative) so I can find out wht is actually possible, but getting them to discuss things may be "interesting".
... View more
Aug 17 2021
1:13 PM
I have to re-engineer a Meraki network that is running as a flat VLAN on VLAN 1. I want to introduce a number of VLANs so that I can allocate different users/devices to different VLANs to allow me to better secure the devices environment. Straight-forward so far. Now here's the catch: the available IP address space is very restricted, and my customer's ISP has said he can only give us a bunch of discontiguous /24 ranges. If this was a standard Cisco switch, I would configure VLANs with SVIs that had secondary addresses....messy, but at least no server renumbering required, and I could use additional discontiguous subnets. The Meraki switches (210/225s) don't allow the use of secondary addressing (do they?) so I can't use that solution even if I wanted to :). I could, of course, use several different VLANs each with its own subnet, which would work, but would be excessively messy and unmanageable. I also have to consider that Meraki wireless APs are running on the LAN, so if I had a VLAN for upstairs and a VLAN for downstarirs, I would have to advertise different SSIDs connecting to different VLANs, thus destroying mobility Has anyone successfully dealt with this kind of situation before? Or is it just me being blind to the obvious solution (that's quite likely!) Thanks JB
... View more
Feb 1 2021
1:14 PM
I have an MX67 which has a VPN tunnel to an MX84. I want to authenticate devices onto the MX67 ports based upon their MAC address. I already have devices authenticated by dot1x supported by an ISE over the tunnel. I cannot use MAB to authenticate the non-dot1x devices because MAB on an MX67 does not work with the ISE, which requres the "call-check" attribute and which the MX does not supply. It has been suggested that I could set up a "deny-any-any" firewall rule on the MX67, then whitelist the MAC addresses of the required clients. However, I don't see a way of doing that without disabling the ports that are successfully authenticating with dot1x, and as a result having to reconfigure the ports that were authenticating with dot1x to authenticate with whitelisted MAC addresses, which is inferior and less secure than dot1x. Have I missunderstood the situation, or does my description and diagnosis above sound right? Thanks Jim
... View more
Feb 1 2021
11:03 AM
Now I'm gonna move the goalposts, sorry.....its been suggested that I could use the inbuilt MAC capabilities of the MX to do what I need, so create a firewall rule to block everything, apply that, then use a client rule to whitelist the clients by MAC address. That should work OK, but I believe setting the firewall deny-all rule will prevent the existing ports on dot1x from working. That being the case, I will have to whitelist all devices and can't use dot1x even for the devices upobn which it works. Is the situation as I describe, or have I misunderstood something Thanks Jim
... View more
Jan 27 2021
12:03 AM
Guys, this should be a simple problem, if I could just find the right documentation! I have a Meraki MX67, with a site-to-site VPN linking to a hub Meraki MX84 HA pair. I have client PCs successfully doing IEEE802.1x authentication on the MX67, using an ISE (v2.7) in the network at the MX84 end, so I know both ends work fine. However, the user wants to authenticate devices with no supplicant, so needs to use MAB. The MX67 has an option to use MAB, but it fails (reject) despite the devices being configured in the ISE. Other documentation I've found says that the ISE is looking for the "call-check" attribute when authenticating, but the MX67 doesn't provide it. As a result, the MAB fails, and indeed I can see failure notiifcations in the log and the traffic in the packet trace. So I need to stop the ISE looking for the "call-check" attribute from the devices MAB-ing on the MX67, but I can't find anything that tells me how to do that or if its possible. Yes, I know it would be better to trunk a switch to the MX67 and do "normal" MAB on a "normal" switch port, that was my original response, but apparently a switch won't fit the budget. If there is any document that says how to do it, can I have a link, or some idea of how to do the job. It sounds like just switching something off....? Any hints will be gratefully recieved! Thanks Jim
... View more
Jan 16 2021
9:49 AM
Thanks for the comment KarstenI. I thought that might be the answer, because I couldn't get confirmation anywhere that my proposed solution would work. So if I have three VLANs on the remote site, am I right in believing that client devices on all remote site VLANs can send send traffic to the VPN, the traffic will traverse the VPN tunnel running from the remote to the central MX (which will be running on a single physical link), and emerge from the central MX on the native VLAN, with source IP address remaining as it was when sent?? Have I got anywhere near the truth? Thanks Jim
... View more
Jan 16 2021
8:55 AM
The scenario I'm thinking of is as follows: Central Data Centre site with two MX84s in HA Mode. Remote site with a single MX67. Internet access at both sites (of course!). I want to support three VLANs on the remote site, Data, Voice and Wi-Fi, and I plan to run Split-Tunnel VPN from the remote site to the Data Centre. I know I can set up VLANs on the remote site, with a local SVI. I know I can set up VLANs on the central site, but my question is: "How do I set the MXs up so that the VLAN ID/traffic etc, is retained across the VPN?", so for example, the Data VLAN traffic created on the remote site emerges over a trunk port, in the right VLAN in the Data Centre. I've Googled to no avail....there are suggestions that this should work but I can't find hard facts. As a side issue, I believe if I'm going to do this, I can't run the Data Centre MXs in VPN Concentrator mode, but need to use Routed mode, and use two ports, not run the MX one-legged. That seems reasonable because the VPN will come in on one port (native VLAN) and will exit in a VLAN contained in a trunk on another port...is that right? Any example documents showing how to do what I'm trying to do would be a bonus! Thanks Guys! Jim
... View more
Mar 27 2018
8:07 AM
I have a Walled Garden set-up with more than one destination address configured. VPN clients use the facility so that users can associate with the AP with no authentication, but can only go to (internet exposed) VPN concentrators without the extra step of manual authentication. This is necessary because the same SSID has to give connection for several different VPN clients going to different concentrators. It works reasonably well, but the NOC has in the past added addresses to the Walled Garden without taking redundant addresses out (when a VPN address changes, for instance) Is there any way I can find out which of the addresses are actually being used, like a hit count or even something like a simple use indicator that just indicates use or no use over a period? That would simplify the tidying up on the configurations
... View more
Jan 2 2018
1:20 AM
Certainly that was my understanding as well, but its good to confirm it. That means, in words of one syllable, that if you loose the Internet, you've lost RRM too 😞 Thanks Jim
... View more
Jan 2 2018
12:21 AM
Hi Guys, I've read a bunch of articles on the 'net that say that the Meraki Control Plane has to have connectivity to the Internet, and so to the Cloud Controller, for things like RRM to work properly. I've also seen articles that suggest that the situation may be changing, but can find no evidence that it has done so yet. Can anyone advise: I know that the Data plane doesn't need to go to the Cloud Controller; I know that the Management plane must go to the Cloud Controller if adds/moves/changes are to be made; but I still don't know if the Meraki Control plane must connect to the Cloud Controller for things like RRM to work properly. Thanks for any clarification Jim
... View more
© 2024 Cisco Systems, Inc.
