.jpg "Opportunities, Appliacation, Openings"){kind=small}
.jpg "Hand Job, Blow Job, Job Search, Monster Job"){kind=small}
.jpg "pusat resume, daftar kerja, cari kerja"){kind=small}
.jpg "Project Manager, SOftware Engineer, SAP Consultant"){kind=small}
why doesn’t far end switch show near end host as CDP neighbor on incoming trunk link?
Hello,
I am trying get my head around a semi-complex protocol tunneling task, but I have some questions on the basics.
Here’s the topology
“Near end host”: BB1 “Far end switch”: CAT2
[BB1]f0/1—–f0/11[CAT1]f0/23—–dot1q trunk—–f0/23[CAT2]f0/1—–f0/1[R1]
To get cdp tunneling to work (and it does work) I enable this on CAT1 and CAT2 access ports:
CAT1: interface f0/11 switchport mode access switchport access vlan 100 l2protocol-tunneling cdp no cdp enable
CAT2: interface f0/1 switchport mode access switchport access vlan 100 l2protocol-tunneling cdp no cdp enable
The trunk between CAT1 and CAT2 carries vlan 100 as well as others.
This is what I understand so far:
BB1 sends a multicast CDP packet on it’s port to CAT1. Since CAT1 has cdp tunneling enabled, it forwards it rather than processes it. Is this correct? CAT1 sends this packet out all trunk links that have vlan 100 allowed AND any access ports on VLAN100. Is this correct? The packet still has the cisco CDP destination MAC. Is this correct? The packet is dot1q tagged and sent out port fa0/23 and still has cisco CDP destination MAC address. Is this correct?
Question:
CAT2 doesn’t have tunneling on port fa0/23. Why doesn’t CAT2 now process this CDP packet and show BB1 has a CDP neighbor on fa0/23? Does trunking override this behavior? Does CAT2 treat this packet differently because it is a tagged CDP packet?
Thanks,
Blogs and organic groups at http://www.ccie.net
