The Cisco Short Questions Thread v12.4.9(WTF)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cisco Short Questions Thread v12.4.9(WTF)

guppy: Sep 21, 2004; sting like a byob

Super basic questions about DHCP snooping that I'm slightly embarrassed to ask. My main goal here is to prevent rogue DHCP servers from interfering, less as a security concern and more along the lines of preventing operational problems from non-technical staff plugging in unauthorized devices. Cisco's documentation is, as usual, not great.

First question, I guess, is: is this the right tool for the job? It seems like it is. I know DHCP snooping is often deployed with DAI, but I don't think I actually need that for my purposes.

I watched a video about the configuration process, and it seemed straightforward enough, but I have a slightly more involved setup than their example. I have a whole mess of sites, and generally each site has an on-premise DHCP server (separate from the network hardware) that serves as the primary, with a secondary one in an off-site datacenter as a fallback in case the on-prem box dies. I just have the one WAN uplink for my site routing devices; the on-premise server has teamed NICs, but the switchports themselves aren't port-channeled or anything. From the routing device it's generally a hub-and-spoke topology. These sites carry end-user traffic, these aren't datacenter networks or anything. The networks in question are running on Cisco hardware.

I know I need to enable DHCP snooping globally and on the VLANs in use, and if the video I watched was to be believed, I also need to specifically disable insertion of Option 82 or else it will be enabled by default:

code:

ip dhcp snooping
ip dhcp snooping vlan ##,##,##,##,##
no ip dhcp snooping information option

I know I then need to specify the trusted interfaces, which is question #2: Am I correct in thinking that my routing device needs to trust 1. the interfaces going to the teamed NICs (to allow the on-prem DHCP server to work) and 2. the WAN uplink interface (to allow the backup DHCP server to work)?

code:

interface <WAN uplink>
  ip dhcp snooping trust
interface range <interfaces for DHCP server>
  ip dhcp snooping trust

Question #3: I think I also need to configure this on the access-layer switches as well, trusting only their uplink ports, right?

code:

ip dhcp snooping
ip dhcp snooping vlan ##,##,##,##,##
no ip dhcp snooping information option
interface <whatever>
  ip dhcp snooping trust

Do I have this right, anything obviously wrong or potential landmines I haven't understood?

EDIT: Wait, is there any point to configuring it on the routing device? I think just configuring it on the access-layer switches would be enough.

guppy fucked around with this message at 02:19 on Jan 7, 2023

# ¿ Jan 7, 2023 01:50

Adbot: ADBOT LOVES YOU

# ¿ May 13, 2024 21:33

guppy: Sep 21, 2004; sting like a byob

Oh, I remember why I thought I needed it on the routing device. It's a little hard to explain, but there's gear that we don't control that connects to our network at our routing device and we've had issues with that gear trying to serve DHCP. We've been isolating their stuff on to its own VLAN as well, but it takes a lot of time to get changes through on their side (and, frankly, on our own side as well). So I think I am going to need to enable it there too and trust only my own links to the DHCP server and the WAN uplink. Otherwise the rogue offers are just going to get distributed through the now-trusted links to the access switches.

# ¿ Jan 7, 2023 12:22

guppy: Sep 21, 2004; sting like a byob

Yes, exactly.

# ¿ Jan 8, 2023 00:36

guppy: Sep 21, 2004; sting like a byob

The real answer to this is something like that AirCheck or an Ekahau Sidekick. It's not going to happen because that stuff costs money and then you have to teach people how to use it, which also costs money. None of the actual "testing" results you're going to get without them are going to be worth much, and if they were, the users wouldn't believe them anyway.

Real talk: the answer to every, and I mean every wireless question is "it depends." Wireless deployments are designed to support specific applications in specific locations with a whole bunch of specific parameters. Nobody except you cares about that and everyone else assumes that wifi is magic that exists everywhere and functions perfectly, and if whatever they're trying to do isn't working, they think the wireless is "broken." This is the opposite of the truth: 802.11 is built on all kinds of compromises and assumptions, and it's a miracle it works at all, much less as well as it does. This is a thankless, unfunded mandate that will accomplish literally nothing.

The only actually-useful thing you can do with student workers who don't know much about wireless technologies is to send them to go talk to the people complaining and gather much, much more specific information. When did this problem start? Any changes or new equipment around that time? What specifically are you trying to do, and what happens when it doesn't work? Are they associating but not getting an IP address? Are they getting an IP address but DNS doesn't work? Can they not associate at all? What specific error message, if any, are they getting? Is it possible that they're trying to use a particular application, and it's that application that has a problem? Are there any commonalities or distinctions between the users having problems? Does everyone in this area have a problem? If not, what's different about the people who don't?

Expect getting these answers from anyone to be like pulling teeth, but unless your student goes there, tests, and finds that they, too, are unable to associate to an AP, you aren't getting anywhere until you play 20 Questions. There can absolutely be real wifi problems. But a lot of "wifi problems" aren't really and you gotta start by determining what the actual point of failure is.

EDIT: I know you already know that their effectiveness will be limited. But they may actually be able to help you accomplish if they know the right questions to ask.

# ¿ Feb 9, 2023 02:21

guppy: Sep 21, 2004; sting like a byob

If it makes you feel better, we have that stuff and the training and certifications to use it, and the users and even other support groups still don't believe us.

guppy fucked around with this message at 10:21 on Feb 9, 2023

# ¿ Feb 9, 2023 09:25

guppy: Sep 21, 2004; sting like a byob

I'm trying to get wired 802.1x implemented in a Cisco environment, currently in the very early testing stage. I have a mix of device types, but I am currently working with a 9200L running IOS-XE 17.6.3. I watched a Pluralsight video on the topic; the video series assumes you're using ISE, which I'm not, but I'm not even to the point of caring about the RADIUS auth source. I'm trying to get a sample interface configured. I'm starting from an existing port configuration. I have successfully entered the following:

code:

access-session port-control auto
dot1x pae authenticator
access-session host-mode multi-auth

The Pluralsight video told me to do the following:

code:

authentication order dot1x mab
authentication priority dot1x mab

These don't work. They are deprecated and I am directed to use "cpl." I have no idea what that is and the Cisco documentation is useless. Googling for other people's examples suggests that this is going to involve class- and policy-maps, and indeed my access-session commands seem to have created a policy map for this. But I don't know what I'm doing and could really use some guidance or some links to some documentation that is comprehensible and actually correctly reflects the state of the platform. Pluralsight also told me that the way to enable multi-auth was "authentication host-mode multi-auth," and that didn't work either, but in this case the deprecation message at least pointed me to a replacement command that functions identically and is easy to understand. The error for the other two lines does not point me anywhere useful.

# ¿ Mar 6, 2023 18:35

guppy: Sep 21, 2004; sting like a byob

Thanks! Not a stupid question, I think the Plurasight video was about IOS, but all the other stuff I've found suggests that this stuff should still work in XE. However, it appears that someone has at some point configured this device to use "new-style" configuration, which is what the post right above me is talking about. This is not a revertable change, apparently; I'd have to wipe the switch to revert to legacy. Which, happily, I can do, because this is a test switch!

# ¿ Mar 6, 2023 20:23

guppy: Sep 21, 2004; sting like a byob

Pile Of Garbage posted:

I loathe ACLs on IOS devices. We've got a pair of Cisco ISR 4331 routers at work which sit at the WAN edge and have an ACL configured for filtering inbound traffic. It's not that big, only about 100 entries and yet we repeatedly encounter a bug where when we add entries to the ACL it just breaks and the newly added entries refuse to match traffic. We've escalated to TAC twice and each time they're just like "oh yeah idk just recreate the ACL." So yeah now we're up to INTERNET-IN-05 or something

I think the thing I find most baffling about ACLs on... I'm not sure if it's all IOS variants or not, but definitely at least some, is that you can't remove an ACL entry. You have to remove the whole list, then re-create it.

# ¿ Aug 26, 2023 15:02

guppy: Sep 21, 2004; sting like a byob

Does the LACP rate (for PDUs) have to match on both ends? I know that when you configure LACP on port-channel members, the rate you specify (fast or slow) dictates how fast the device tells its partner it wants to receive PDUs, but if one side is configured for fast and the other side is configured for slow, will that prevent the link from functioning? Or does it only dictate how fast a failed member link is pruned once it fails?

# ¿ Oct 9, 2023 18:56

guppy: Sep 21, 2004; sting like a byob

Thanks, this is about what I thought. Coworkers are telling me it won't work if they're mismatched, which does not comport with what I was reading. I plan to match them, they are already up, I'm just having issues that may require a change and I'm wondering if the link will be down after changing one until the other side matches. Sounds like it won't.

# ¿ Oct 9, 2023 21:34

guppy: Sep 21, 2004; sting like a byob

This seems like a basic question, but is there an easy way to capture LACP traffic (and only LACP traffic) on a Cat9k/IOS-XE? I'm aware of debug lacp and maybe that will be good enough, but I'm not sure which side of this port-channel is the issue. I'm already capturing it on the other side, which is where we have been assuming the problem lies, but now I need to rule this side in or out. Googling for this is almost impossible as you get all kinds of documentation for entirely different operating systems like IOS-XR and NX-OS.

The interfaces in question are extremely high-throughput and just capturing all traffic from the interface is going to be a problem. Some other Cisco OSes have a very simple lacp packet-capture, but that doesn't seem to exist here. I've seen monitor capture, but it's not clear to me how/whether I can capture L2 traffic with it; all their examples specify ports and the like that aren't going to apply here.

# ¿ Oct 11, 2023 11:12

guppy: Sep 21, 2004; sting like a byob

The specific issue I'm trying to troubleshoot is the LACP channel going down very, very briefly -- but it's enough to interrupt real-time stuff. The Catalyst side doesn't even report the issue because it's so brief. The other device says it isn't receiving the PDU in time, and we are trying to figure out if the Catalyst side isn't sending it in time/is sending something malformed, or if the other device isn't processing it in time.

# ¿ Oct 11, 2023 12:08

Adbot: ADBOT LOVES YOU

# ¿ May 13, 2024 21:33

guppy: Sep 21, 2004; sting like a byob

The timers were definitely not mismatched.

tortilla_chip posted:

Is ELAM still supported on Catalyst 9000?

edit: https://www.cisco.com/c/en/us/suppo...-hId-1997310445

Thanks! I'll take a look at this tomorrow.

We are actually thinking now that it is an issue with a scheduled task on the Catalyst side that is unexpectedly (but every time) screwing up and taking up excess CPU time. For now we have changed the LACP timers and we'll see how things go tomorrow.

Incidentally, for anyone wondering about the original question of whether the link would function with them mismatched, it will. I changed them on the Cisco side and the interface went down for a moment and then came back up, and continued to be up indefinitely. I am enjoying being the one who was right about this, mainly because it would have been a pain in the rear end otherwise (but also a little bit because I read up on the subject and am apparently the only one).

# ¿ Oct 12, 2023 00:53

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cisco Short Questions Thread v12.4.9(WTF)