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 mcbrown
mcbrown
Comes here often
Member since Nov 11, 2020
Mar 22 2023
Community Record
14
Posts
0
Kudos
0
Solutions
Badges
Aug 27 2022
10:20 AM
I installed all the new switches last night and it doesn't look like multicasting is routing correctly. I need multicasting for Informacast Fusion which is our PA system and computer imaging but I am most concerned about the PA system right now.. My Informacast server and speakers are all on vlan 100 (10.10.100.0/24) at the main building. There is only one server for the network. At the remote site my speakers sit on vlan 100 (10.11.100.0/24). I switched some things around with support today. Here is what I have set right now: On core 425s: Multicast routing is enabled on vlan 100 and on the transit vlan My rendezvous point is the SVI of vlan 100 - 10.10.100.1 On the 350s: Multicast routing is enabled on vlan 100 and the transit vlan The rendezvous point on the 350 network is set to 10.10.100.1 (the svi of vlan 100 on the 425s) The speakers are all connected to a combination of Meraki and Cisco switches that are trunked to the core 425s at the main location and a combo of Cisco and Meraki switches that are trunked to the core 350s at the remote location. I was working with Meraki support for most of the day and they said: "Verified that the groups are being formed but all joining different groups. While most speakers are joining group 227.75.76.77, the server is only joining group 239.x.x.253, preventing the devices from communicating." Any ideas what can be causing this? Is it a routing issue?
... View more
Aug 24 2022
9:34 AM
Is multicast routing enabled only needed on the sender vlans and transit vlans? Is it needed on receiver only vlans too? Got it. I set it to the transit vlan SVI at the core and at the remote sites I set the rendezvous point using the custom IP option and pointing it to the core transit vlans IP.
... View more
Aug 23 2022
8:02 AM
Thanks GIdenJoe. My transit vlan is vlan 20 on the 425s at the main site and vlan 20 on the 350s at the remote site. So in this case I should be doing the following: CORE: set "Multicast Routing" to "Enabled Multicast Routing" on Vlans 10,15,20,100 REMOTE: Instead of setting "Multicast Routing" to "Enabled Multicast Routing or IGMP querier", set "Multicast Routing" to "Enabled Multicast Routing" on vlan 10,15,20 Basically enable Multicast Routing on every sending and receiving vlan and any transit vlans? Correct? Does it make sense to make the Rendezvous Point the transit vlan's SVI IP since this really is central to both switches? Is there a need to set a Rendezvous point at the remote site or only at the core?
... View more
Aug 22 2022
4:22 PM
I have a network with 2 locations/buildings: Main Building (core) Remote building The Core/Main Building (425 stack) connects to the remote building (350 stack) via a trunk. OSPF is enabled at both sides and the trunk between the 2 locations only allows the management and transit vlan for OSPF. I have two servers at the core that will provide multicasting traffic. Server 1 sits on vlan 100 at the core (OSPF enabled) Server 2 sits on vlan 10 at the core (OSPF enabled) The receivers for the multicasting traffic from Server 1 are on vlan 100 (10.10.100.0/24) at the main building and vlan 100 (10.11.100.0/24) defined locally on the 350s at the remote site. The receivers for multicasting traffic from Server 2 can be on vlan 10 (10.10.10.0/24) and 15 (10.10.15.0/24) defined on the core at the main building and 10 (10.11.10.0/24) and 15 (10.11.15.0/24) defined on the 350s at the remote site. For multicasting: On the core, set "Multicast Routing" on vlan 10 and vlan 100 to "Enabled Multicast Routing" Set a rendezvous point on the core enable "IGMP snooping" and disable "Flood unknown multicast traffic" on the 425 stack at the core and the 350 stack at the remote site and at the remote site set "Multicast Routing" to "Enabled Multicast Routing or IGMP querier" on vlan 10 and vlan 100 Am I on the right track here? Is there a preferred IP/Interface for the rendezvous point? Is there an advantage to adding rendezvous points on the core for both the svi of vlan 10 and the svi for vlan 100? Do I need a rendezvous point on the remote site's 350 stack? Does the transit vlan need multicast routing enabled? Thanks
... View more
Aug 13 2022
3:01 PM
Have a follow up on this. I am trying to figure out the best way to isolate VLANs at my spokes? I have guest VLANs for WIFI and also have IOT VLANs that I want to fully isolate and only allow access to the internet. My MS425s at the hub/core are trunked to a pair of active/passive Palo Alto firewalls. The way I have isolated guest and IOT VLANs in the past is with VRFs that default route to a dedicated guest interface on the Palo Altos at the Core/hub. I know VRFs are not an option on Merakis so was wondering if there are any options on the Merakis to fully isolate a VLAN other than ACLs? Thanks.
... View more
Aug 3 2022
6:55 AM
Ok good. It's the same vlan number at the remote site but it is a different subnet. Core vlan 110 is 172.20.110.0/24 and at the remote site it is 172.19.110.0/24. Got it. Thanks for the confirmation Brash.
... View more
Jul 31 2022
8:02 AM
I have a stack of MS425s connecting to a stack of MS350s. I have the following VLANs setup on the MS425 (network core) 19 (172.20.19.0/24 - 172.20.19.1) - transit between the 425s and the 350s 219 (172.20.219.0/24 - 172.20.219.1)- management VLAN for the 350s 10 (172.20.10.0/24 - 172.20.10.1) - test VLAN at the network core 110 (172.20.110.0/24 - 172.20.110.1) - AP Management at the core I have the following VLANs on the 350s (remote building) 19 (172.20.19.0/24 - 172.20.19.2) - transit between the 425s and the 350s 110 (172.19.110.0/24 - 172.19.110.1) - AP management at the remote building The uplink from the 350s to the 425s is setup as a trunk with allowed 19,219 and no native VLAN I have enabled OSPF on both the 425s and the 350s. On the 425s OSPF is enabled on: 19 (passive false, area 0) 110 (passive true, area 0) On the 350s OSPF is enabled on: 19 (passive false, area 0) 110 (passive true, area 10 Stub) default route 172.20.19.1 First question is does this setup look correct? Second question is if I run a ping from the 350s from int 172.19.110.1 to 172.20.10.1 (VLAN 10 on 425s) it is successfully pinging. VLAN 10 is not part of OSPF and VLAN 10 is not an allowed VLAN on the uplink from the 350s to the 425s so why are the 350s able to ping 172.20.10.1? Last concern is when I run the Routing Table tool on the 350s or the 425s it just spins forever and never shows the results? Thanks for the help.
... View more
Labels:
- Labels:
-
Interfaces
-
Layer 3
Jul 5 2022
7:35 PM
Thanks to everyone for their responses. Couple follow up questions. Is it correct to say that the switch management IP should come from a VLAN defined on the closest layer 3 switch in the uplink chain? If using OSPF between the 425s and the 350s should the management VLAN be advertised on OSPF or is it better to not advertise? I am going to open up a can of worms with the next couple of questions but here we go: If I define a Meraki network for each site/building, is it best practice to place all Meraki devices (switches, access points) in that building's Meraki network or should a site for each type of device be defined for each site/building? I had planned to use OSPF and create stub areas for each spoke. We only have about 35 switches total and most resources are at the data center in the hub so one area will work but I don't see a downside in creating the additional areas for each spoke. Is there a downside to creating the additional areas? Last thing, creating the management VLAN for the 350s on the 425s got me thinking, is there any advantage to creating all of my VLANs for the network on the 425s and then sending them over the layer 2 trunk to the 350s as opposed to using OSPF between the 425s and the 350s and defining VLANs on both the 350s and 425s? Thanks again for everyone's input.
... View more
Jul 4 2022
6:49 PM
Hi Everyone, We have a hub and spoke WAN. I am doing a full conversion over to Meraki with a combination of 425s, 350s and 225s. A 425 stack is installed at the “hub” and is basically the core of the network. The 425 stack connects to our firewalls via a trunk. The management IPs of the 425s are in the 172.20.254.0/24 network and the gateway of this vlan is the IP of the firewall. The 350s are the core of the “spoke” and will connect to our 425s via a trunk and ospf will be enabled on both the 425s and 350s. I have a transit vlan setup on both the 425s and the 350s that will be used for ospf. I am having a problem with the management IPs on the 350s. It appears that the only way the 350s can get out to the internet is if they get an IP from the 172.20.254.0/24 network. I would like the 350s to get an IP from the 172.19.254.0/24 network that is defined on the 350s. That second octet is how I define what building the devices are in. Is it possible to set up the management IPs on the 350s this way? Thanks for your help.
... View more
Dec 9 2020
7:07 AM
Any ideas on if there is there a way to send the ipsk to the radius server in the access-request from Meraki?
... View more
Dec 8 2020
8:32 AM
Worked with PacketFence and we added a line to send back the tunnel-password. Works now. Another question though, is there a way to send the ipsk to the radius server in the access-request from Meraki?
... View more
Nov 12 2020
1:50 PM
Any idea how to tell FreeRadius to send additional attributes with the access-accept? Do you think the firmware update on the 21st will have some additional coding for IPSK?
... View more
Nov 12 2020
7:14 AM
It's a little different than what is in that document because I am using PacketFence not just FreeRadius. The MACs and the PSKs are stored in a database instead of the conf file. I checked some additional logs and it looks like PacketFence is passing the tunnel-password back in the reply but it is passing it as attribute Cisco-AVPair. Here is the log.: RADIUS Request RADIUS Request User-Name = "00e04c19dddd" User-Password = "******" NAS-IP-Address = 172.20.10.20 Called-Station-Id = "68:3a:1e:85:cc:cc:WIFI-BYOD" Calling-Station-Id = "00:e0:4c:19:dd:dd" NAS-Port-Type = Wireless-802.11 Event-Timestamp = "Nov 12 2020 09:58:47 EST" Connect-Info = "CONNECT 11Mbps 802.11b" Message-Authenticator = 0x2458d1c2852dfb55ec85d8484624cccc Meraki-Network-Name = "Network" Meraki-Ap-Name = "AP-01" Stripped-User-Name = "00e04c19dddd" Realm = "null" FreeRADIUS-Client-IP-Address = 172.20.10.20 Called-Station-SSID = "WIFI-BYOD" PacketFence-KeyBalanced = "8e4b512c5636628cd16b291bf294eeee" PacketFence-Radius-Ip = "172.20.100.2" SQL-User-Name = "00e04c19dddd" RADIUS Reply Tunnel-Type = VLAN Tunnel-Private-Group-Id = "118" Tunnel-Medium-Type = IEEE-802 Cisco-AVPair = "psk=otahreeddttreeee" Cisco-AVPair = "psk-mode=ascii"
... View more
Nov 11 2020
7:23 AM
Hi Everyone, I am trying to get iPSK working with PacketFence/FreeRadius radius. It looks like everything is working on the PacketFence side of things. Here are the logs from PacketFence: PACKETFENCE LOG: Oct 17 22:18:07 srv-pf-02 packetfence_httpd.aaa: httpd.aaa(2131) INFO: [mac:00:e0:4c:19:dd:dd] Connection type is MAC-AUTH. Getting role from node_info (pf::role::getRegisteredRole) Oct 17 22:18:07 srv-pf-02 packetfence_httpd.aaa: httpd.aaa(2131) INFO: [mac:00:e0:4c:19:dd:dd] Username was defined "00e04c19dd56" - returning role 'WIFI-IT-STAFF-DISTRICT' (pf::role::getRegisteredRole) Oct 17 22:18:07 srv-pf-02 packetfence_httpd.aaa: httpd.aaa(2131) INFO: [mac:00:e0:4c:19:dd:dd] PID: "user", Status: reg Returned VLAN: (undefined), Role: WIFI-IT-STAFF-DISTRICT (pf::role::fetchRoleForNode) Oct 17 22:18:07 srv-pf-02 packetfence_httpd.aaa: httpd.aaa(2131) INFO: [mac:00:e0:4c:19:dd:dd] (172.20.110.19) Added VLAN 118 to the returned RADIUS Access-Accept (pf::Switch::returnRadiusAccessAccept) Oct 17 22:18:07 srv-pf-02 packetfence_httpd.aaa: httpd.aaa(2131) INFO: [mac:00:e0:4c:19:dd:dd] security_event 1300003 force-closed for 00:e0:4c:19:dd:dd (pf::security_event::security_event_force_close) RADIUS LOG: Oct 17 22:18:07 srv-pf-02 auth[2992]: [mac:00:e0:4c:19:dd:dd] Accepted user: and returned VLAN 118 Oct 17 22:18:07 srv-pf-02 auth[2992]: (12467) Login OK: [00e04c19dd56] (from client 172.20.10.19/32 port 0 cli 00:e0:4c:19:dd:dd) Radius is authenticating correctly and returning vlan 118 which is correct but on the Windows machine I am trying to join from I get "Can't connect to this network" Here are my SSID settings: Association requirements: Identity PSK with RADIUS WPA encryption mode: WPA2 Splash page: None Readius server set to PacketFence management Radius testing: disabled Radius CoA: disabled Client IP assignment: Bridge mode VLAN tagging: Don't use Radius override: Radius response can override VLAN tag Here is the Meraki log for the client: AP-01 WIFI-BYOD IT-VM-TEST-02 802.11 disassociation client has left AP AP-01 WIFI-BYOD IT-VM-TEST-02 WPA deauthentication radio: 1, vap: 0, client_mac: 00:E0:4C:19:DD:DD « hide client_ip 0.0.0.0 aid 1114159115 AP-01 WIFI-BYOD IT-VM-TEST-02 RADIUS authentication resp: reject AP-01 WIFI-BYOD IT-VM-TEST-02 802.11 association channel: 153, rssi: 26 Thanks.
... View more
© 2024 Cisco Systems, Inc.
