cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1559
Views
0
Helpful
4
Replies

how to protect a trunk port

Thomas.Meyer
Level 1
Level 1

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

4 Replies 4

milan.kulik
Level 10
Level 10

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

Hi Milan,

thank you for you suggestion. I tried UDLD with aggressive mode, but it did not hinder a PC from connecting.

Show UDLD says that the current bidirectional state be "Unkown", and will leave the interface up, even after minutes:

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

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

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

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco