cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
673
Views
0
Helpful
13
Replies
cg113
Beginner

Strange Trunking problem? Haven't Solved

We are experiencing an issue, where just one trunk port is getting dhcp and able to reach another network that isn't making much sense to us.  For example:

 

Switchport:

 

 switchport trunk encapsulation dot1q
 switchport trunk native vlan 54
 switchport trunk allowed vlan 43,54
 srr-queue bandwidth share 10 10 60 20
 srr-queue bandwidth shape  10  0  0  0
 priority-queue out
 mls qos trust cos
 auto qos voip trust
 spanning-tree portfast

 

43 is a voice vlan, 54 is the data vlan. 

 

 

This interface is on a switch, that is connected to the core switch.   The core switch is directly connected to a dhcp server, and the gateway for vlan 54 has a helper address pointed to that dhcp server:

 

interface Vlan54
 ip address 172.17.6.1 255.255.255.0
 ip helper-address 172.16.10.1

 

The core switch is also connected to another network, that is separate from us.  We control access between the two networks via an access list.  There are routes to access this other network but we do not have any vlans or the like.

 

When connecting a client machine to the interface in question, this worked fine typically.  It gets an address from the dhcp server on vlan 54.  Today we attempted to plug in a new pc, and it received an ip address from a dhcp server on that other connected network, that we do not have vlan information for.  This other network was connected to access an application, and there is routing and an access list on the interface it connects to.  The access-list was allowing dhcp through.  It received an address of 10.70.32.152 from the dhcp server.

 

By modifying the access list so it doesn't allow dhcp requests, this no longer worked, but that interface would now not receive any dhcp information.  This switchport configuration works for other ports fine thus far.  I changed this port to an access port and it received the correct dhcp information.  Back to trunk and it would not receive any, unless i opened that access-list and it would receive it from the other network. 

 

What was wrong with the trunking on this port?  I cannot explain how it is reaching this.  What further information can I provide to assist in explaining the issue?  I have not been able to duplicate this in any other way thus far, and tried other switchports with the same config and could not duplicate

13 REPLIES 13
chrihussey
Collaborator

Hello,

Could you provide the configs for the access and core switch?

I can post portions, what portions are you looking for?

1- Connection interfaces on the core to the access switch and other network and dhcp server port.

2- Relevant L3 VLAN interfaces on the core

3- Routing protocol configs (OSPF, EIGRP, static, etc)

Good place to start anyway

 

proper vlan 54 interface:

 

interface Vlan54
 ip address 172.16.2.254 255.255.255.0 secondary
 ip address 172.17.6.253 255.255.255.0
 ip helper-address 172.16.10.1

 

Physical connection to our switch (with the switchport in question):

 

 switchport mode trunk
 auto qos trust dscp
 service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy

 

Interface to other network where this other dhcp came from (we identified the portion of ACL that allowed it):

 

 switchport mode trunk
 ip access-group EXAMPLE_in in
 auto qos trust dscp
 service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy
!

 

 

Interface on access switch having trunking problem:

 

interface FastEthernet2/0/31
 description 20D
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 54
 switchport trunk allowed vlan 43,54
 srr-queue bandwidth share 10 10 60 20
 srr-queue bandwidth shape  10  0  0  0
 priority-queue out
 mls qos trust cos
 auto qos voip trust
 spanning-tree portfast

 

 

Access switch uplink to core switch:

 

interface FastEthernet2/0/48
 switchport access vlan 54
 switchport mode access
 spanning-tree portfast

 

Vlans allowed on access switch:

vlan 41,43,54,63,300-302,306,999-1000

 

No routes, no routing protocols on access switch, just default route to core switch

No routing protocols on core switch, just static routes.  No local routes, this is the route for the other network through the access-list.

ip route 10.70.32.0 255.255.255.0 10.70.30.2

So if I understand things correctly, F2/0/31 is connected to the device getting the wrong DHCP, interface F2/0/48 is an access port in VLAN 54 that serves as the uplink to the core switch and the core switch connection to the access switch is configured as a trunk port.

If that is the case then anything coming from the access switch to the core is ending up in VLAN 1 on the core switch and that's why it's probably propagating to the other network.

You need to make the link between the access switch and core either an access port in VLAN 54 on either side, or make it a trunk port on both sides.

If I've got it wrong, please explain.

Hope this helps.

Why are you connecting a PC to a port that is configured as a trunk?

 

I would do. I used gi0/1 but you would use the port the PC is connected.

int gi0/1

switchport

switchport mode access

switchport access vlan 54

spanning-tree portfast

 

 

 

Good question. They set it up this way for differentiating the data and voice vlans is my understanding. We are changing this over to access ports (ie in this case we made it an access port). This is just the way every port on the network is created, and we do see that as an issue even beyond this. Just not sure why this occured anyways.

That to my knowledge will not separate Voice from data. To properly setup a port to see a phone and then a PC connected to the phone the port needs to look like this.

interface GigabitEthernet1/0/4
switchport access vlan 54
switchport mode access
switchport voice vlan 43
spanning-tree portfast

 

 

Mike

apologize i was actually incorrect.  The port is a trunk port on the access switch:

 

interface FastEthernet1/0/48
 description switch_uplink
 switchport trunk encapsulation dot1q
 switchport mode trunk

 

It is a stack of 2, i looked at the config of 2/0/48 (which is an access port).

 

I'll correct my original text

Can you post the port configuration of the connection to the other network from the core?

Thanks

Core connects to on-prem switch at other site over fiber

interface GigabitEthernet2/0/7
 switchport mode trunk
 ip access-group EXAMPLE_in in
 auto qos trust dscp
 service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy

 

 

 

on-prem switch:

interface FastEthernet1/0/48
 switchport trunk encapsulation dot1q
 switchport mode trunk

 

Hand-off to other network from on-prem switch:

interface FastEthernet1/0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk

 

 

Just trunked across for access to an application only I believe

So it looks like VLAN 54 is trunked to the other network. No telling what is happening over there. Just a guess, but it may be tied to another LAN segment with a DHCP server of its own.It may not have had one in the past, but has one now.

If VLAN 54, or for that matter any of your other VLANs, need not cross the boundary to the other network from a L2 perspective, it would be a good idea not to allow them across the trunk.

Actually forgot to ask this..... are these Cisco phones?