C3600 Vlan's convert from IOS V 12.4 to 15.2

Question

Hello,
I need some help to get vlan's to get working again.
I have a c2500 with v12.4 that works with the config above, now with a new c3600 with the smae config but with v15.2 I can't put vlan's working.
I also read about it but I can get it work:
Autonomous AP Will Treat The Sub-interface Tied To Bridge-group1 As The Native Vlan
AnchorWhen using a configuration on an autonomous AP where there is no native VLAN defined, each interface is being dot1q tagged, communication will fail after upgrading to 15.2(2)JA or later. It appears that the configuration is still correct after the upgrade, but the AP sends the untagged frames for bridge-group 1, even though the encapsulation is not defined as native. The autonomous AP will treat the sub-interface tied to bridge-group 1 as the native VLAN, even if it is not defined with the native keyword: "encapsulation dot1 <vlan> native". The VLAN associated with bridge-group 1 must be set to native on the connecting switchport configuration
AnchorThe workaround for this is to configure VLAN 100 as the native VLAN on the connected switchport trunk, even though the encapsulation is not specified as native on the AP.
AnchorIP Routing Enabled By Default
AnchorIP routing is enabled by default in 15.2(2)JB. This default configuration will render ip default-gateway statements inoperable. The workaround is to disable ip routing globally (config t, no ip routing), configure a default route instead of a default-gateway (e.g. config t, ip route 0.0.0.0 0.0.0.0 <default-gateway> ), or disable IP routing using the following cli command:
Current config for:
Cisco IOS Software, C3600 Software (AP3G2-K9W7-M), Version 15.2(4)JB5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Thu 01-May-14 22:04 by prod_rel_team
interface GigabitEthernet0.1
 encapsulation dot1Q 1 native
 no ip route-cache
 bridge-group 1
 bridge-group 1 spanning-disabled
 no bridge-group 1 source-learning
interface GigabitEthernet0.14
 encapsulation dot1Q 14
 ip address 192.168.14.253 255.255.255.0
 ip helper-address 192.168.14.254
 no ip route-cache
 bridge-group 14
 bridge-group 14 spanning-disabled
 no bridge-group 14 source-learning
interface GigabitEthernet0.16
 encapsulation dot1Q 16
 ip address 192.168.16.253 255.255.255.0
 ip helper-address 192.168.16.254
 no ip route-cache
 bridge-group 16
 bridge-group 16 spanning-disabled
 no bridge-group 16 source-learning
interface GigabitEthernet0.100
 encapsulation dot1Q 100
 ip address 192.168.100.51 255.255.255.0
 no ip route-cache
interface BVI1
 ip address 10.0.0.1 255.255.0.0
 no ip route-cache
ip default-gateway 192.168.100.254
bridge 1 route ip
my config in my HP SW (I use trunk port 24 to c3600):
 J9776A Configuration Editor; Created on release #YA.15.13.0005
; Ver #05:08.63.ff.37.27:81
hostname "HP-2530-24G"
trunk 24 trk1 trunk
trunk 1-2 trk4 lacp
no telnet-server
ip default-gateway 192.168.100.254
vlan 1
   name "DEFAULT_VLAN"
   no untagged 3-22
   untagged 23,25-28,Trk1,Trk4
   no ip address
   exit
vlan 10
   untagged 3-22
   tagged 23,Trk1,Trk4
   ip address 192.168.10.250 255.255.255.0
   ip helper-address 192.168.10.254
   exit
vlan 11
   tagged Trk1,Trk4
   no ip address
   voice
   exit
vlan 15
   tagged Trk1,Trk4
   ip address 192.168.15.251 255.255.255.0
   exit
vlan 100
   tagged 23,Trk1,Trk4
   ip address 192.168.100.248 255.255.255.0
   exit
management-vlan 100
spanning-tree Trk1 priority 4
spanning-tree Trk4 priority 4
From SW i can't ping vlan 100 or other vlan's
I also debug arp packets and see that the packets arrive to router but don't get out.
Any help ?

Answer 1

Hi,
A couple of comments to your configuration.
On your HP switch, you have the trunk 24 trk1 trunk command configured. I believe that you do not really want that command to be configured. In HP's vocabulary, a trunk is an EtherChannel. With this command, you have essentially configured a static (that is, non-LACP) EtherChannel that contains only a single physical port 24. That does not make sense and I see no reason to do that. I suggest you remove that command from your HP configuration and refer to the port 24 directly instead. If you want to define a trunk port (that is, a port carrying traffic from multiple VLANs) on this HP switch, you simply define the port as tagged or untagged in individual VLANs. There is no equivalent for a switchport mode trunk command on your HP switch.
I do not have hands-on experiences with the C3600 access points but I remember from my experiments with 1200 series access points that IP address must be configured on BVI interfaces only. Even though the 1200 series access points allowed IP addresses to be configured on physical interfaces or on subinterfaces, these IP addresses were somehow inactive - the AP simply did not respond when contacted using them. This would explain your own observations. Therefore, if you want your AP to be reachable in VLAN 14 or 16, you have to create a BVI14 or BVI16 and move the IP settings from the subinterface to the appropriate BVI. If you want your AP to be reachable in VLAN 100, you have to create another bridge-group, say, 20, put your Gi0.100 into the bridge-group 20 and move the IP address from Gi0.100 to BVI20. You cannot currently contact your AP in VLAN1 (BVI1) because your switch does not have an IP address in VLAN1. If it had, you should be able to ping the AP from your switch.
You have configured your AP as if it was a router, assigning IP addresses to Gi0.x subinterfaces along with configuring IP helper addresses. I believe this is a mistake. Your AP is a bridge between a wireless and a wired network but it does not perform any routing functions. Therefore, apart from a BVI for the remote management, this AP should not be assigned any other IP address. In particular, defining a helper address is useless here because of two reasons: First, your AP is not a router and bridges all DHCP requests back and forth between the wired and wireless network; second, the IP address of the DHCP server you have configured is obviously inside the same network and IP space, indicating that the DHCP requests can reach it directly without the need for any helper.
Can you try implementing the suggested changes and telling us if it did make any difference?
Best regards,
Peter