02-16-2004 06:43 AM - edited 03-02-2019 01:37 PM
some of the Cisco switches (like 2940) are not only for the wiring closet, but also for office deployment.
This leads me to the following question: the uplink port of such a switch will most probably be a trunk port. How can I prevent a PC or laptop user from connection directly to the trunk via plugging into the trunk port, which is configured onto the socket of the uplink?
Port security does not appear to be the right solution, as all of the mac-addresses of the stations connected to the 2940 need to be known.
Regards, Thomas Meyer
02-17-2004 02:51 AM
Hi,
just an idea:
What about using UDLD aggressive mode on the trunk line?
I suppose the user PC wouldn't support UDLD....
See http://www.cisco.com/univercd/cc/td/doc/product/lan/cat2940/12119ea1/2940scg/swudld.htm for details.
Redards,
Milan Kulik
02-18-2004 02:37 AM
Hi Milan,
thank you for you suggestion. I tried UDLD with aggressive mode, but it did not hinder a PC from connecting.
Show UDLD
hv01-sw01#SHOW udld gig2/0/15
Interface Gi2/0/15
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Unknown
Current operational state: Advertisement
Message interval: 7
Time out interval: 5
No neighbor cache information stored
hv01-sw01#show int gig2/0/15
GigabitEthernet2/0/15 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 000d.293c.070f (bia 000d.293c.070f)
...
What I could need is some sort of port-security, but in terms of only checking the next neighbour, not all trunk traffic.
Regards, Thomas
02-19-2004 01:11 AM
Hi Thomas,
which CatOS/IOS version are you uisng on the hv01-sw01?
I remember a discussion two years ago with a conclusion there was a bug in UDLD causing a very long timers.
BTW, UDLD waits for 8 missed messages to shutdown the port and the default message interval is 15 secs (7 in you case, I think).
Maybe some timer tuning would help.
I've never played with UDLD personally, it was just an idea when I read your message.
I don't know any command to check the neighbour - nice idea for Cisco IOS engineers, I think.
Another ideas how to protect the trunk port:
1) Use cross cable to interconnect switches on metal lines - the intruder would need a second cross cable to connect his PC instead of a office switch.
2) Configure blind native VLAN on the trunk, i.e. don't put users to this VLAN, no routing from it to anywhere. The intruder would need a 802.1q running on his PC NIC and guess the correct VLAN ID. (If the office switch supports ISL, use ISL on the trunk.)
3) Use DHCP based on PC MAC addresses, not a simple DHCP pool giving an IP address to anybody. The intruder would have to guess the correct IP address. Also use some software reporting MAC - IP changes and new IP activities (Arpwatch, e.g).
4) If you need some really strong security, implement 802.1x or Cisco User Registration Tool in your network.
Regards,
Milan
02-19-2004 02:24 AM
Hi Milan,
> which CaOS/IOS version are you uisng on the hv01-sw01?
> I remember a discussion two years ago with a conclusion there was a
> bug in UDLD causing a very long timers. BTW, UDLD waits for 8 missed
> messages to shutdown the port and the default message interval is 15
> secs (7 in you case, I think).
it's 12.1(14), which should not be too old ...
> I don't know any command to check the neighbour - nice idea for
> Cisco IOS engineers, I think.
yes, Cisco says the following about the 2940 switches I'm configuring
right now:
"The switches are designed to be used outside the wiring closet in
the end-user workspace."
(http://www.cisco.com/en/US/products/hw/switches/ps5213/products_data_sheet09186a00801973c8.html)
If so, it is really an issue to protect the trunk port, even if an
optional cable guard is installed: a malicious user could plug into
the trunk port of the socket where the uplink was established, and
read all network traffic.
As we want to support guest laptops with those switches, blocking DCHP
through only allowing it based on known MAC addresses is no option for
us.
As far as I know, using ISL encapsulation is not a security measure,
as it does only a wrapping of the packets, and I would not be
surprised if tools like Ethereal are able to sniff that.
802.1x, to my knowledge, is no option for trunk ports.
Our approach so far is to allow only certain VLANs on the
trunk. Default VLAN indeed is not used for anything by purpose and is
not being routed.
Still, I would find it good if Cisco engeneers set up some mechanism
to nail down which neighbours a trunk port is willing to see.
Thanks, Thomas
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: