10-14-2011 12:36 PM - edited 03-07-2019 02:48 AM
I finally got the IPSec tunnel working between our office PFSense router (YEA!) using the same supernet config we had in place before. As part of a staged migration however, we had plugged the production PFSense router into the 4507 cabs and moved all of our servers onto those switch blades to get the increase in bandwidth. That has been working fine and the only road block was the IPSec tunneling issue. When I tried to cut over and unplugged the production PFSense router from the switch however I found I could not route internally on the layer 3 switch. This was working fine in testing prior to pluging in the PFSense router to those switches. The issue appears to be a corrupted VTP VLAN database on the Catalyst 4507s. VTP reports it was last updated on 8/30/2011 by address IP x.x.132.2, which is the day we plugged in the PFSense router, and is also the IP address of the PFSense router. We lost half the VLANs, and VTP does not seem to able to remove or add new ones.
Has anyone else run into this? Is there a known issue with PFSense and Cisco VLANs? Does anyone have a sugestion on how to fix this? Unplugging the PFSense router and rebooting the switches does not have an effect, but based on the date and IP of the last update, it seems almost certain that PFSense is the original source of the issue. There is no VLAN service running on PFSense either, so I don't understand what or why this happened. How do you fix a corrupt VTP database? If I delete vlan.dat will it get recreated?
Thanks in advance!
Here is the relevant output from Cisco:
show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : corp
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 0017.5abd.a700
Configuration last modified by
x.x.132.2
at
8-30-11
17:39:31 - (from me... bold IP and date match PFS router and date it was plugged into switch)
Local updater ID is 10.0.132.4 on interface Vl1 (lowest numbered VLAN interface found)
Feature VLAN:
--------------
VTP Operating Mode : Server
Maximum VLANs supported locally : 1005
Number of existing VLANs : 6
Configuration Revision : 1
show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi1/3, Gi1/4, Gi1/5, Gi1/6, Gi3/3, Gi3/4, Gi4/2, Gi4/3, Gi4/4, Gi4/5, Gi4/6, Gi4/7
Gi4/8, Gi4/9, Gi4/10, Gi4/11, Gi4/12, Gi4/13, Gi4/14, Gi4/15, Gi4/16, Gi4/17, Gi4/18
Gi4/19, Gi4/20, Gi4/21, Gi4/22, Gi4/23, Gi4/24, Gi4/25, Gi4/26, Gi4/27, Gi4/28
Gi4/29, Gi4/30, Gi4/31, Gi4/32, Gi4/33, Gi4/34, Gi4/35, Gi4/36, Gi4/37, Gi4/38
Gi4/39, Gi4/40, Gi4/41, Gi4/42, Gi4/43, Gi4/44, Gi4/45, Gi4/46, Gi4/47, Gi4/48
30 VLAN0030 active Gi3/17, Gi3/18, Gi3/19, Gi3/20, Gi3/21, Gi3/22, Gi3/23, Gi3/24, Gi3/25, Gi3/26
Gi3/27, Gi3/28, Gi3/29, Gi3/30, Gi3/31, Gi3/32
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsup
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1 enet 100001 1500 - - - - - 0 0
30 enet 100030 1500 - - - - - 0 0
1002 fddi 101002 1500 - - - - - 0 0
1003 trcrf 101003 4472 - - - - - 0 0
1004 fdnet 101004 1500 - - - ieee - 0 0
1005 trbrf 101005 4472 - - - ibm - 0 0
VLAN AREHops STEHops Backup CRF
---- ------- ------- ----------
1003 0 0 off
Remote SPAN VLANs
------------------------------------------------------------------------------
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
The 2 missing VLANs are the production VLANs, 10 & 20 respectively, but routing between existing VLANs also appears to be an issue now. All VLANs were there prior and routing between them was working fine. Thanks Again!
Solved! Go to Solution.
10-14-2011 01:16 PM
Yes you can. Delete the vlan.dat/reboot and then if you only have around 5 vlans use VTP transparent and manually create the vlans on each switch.
Jon
10-14-2011 12:44 PM
How many other switches are connected to the 4500 ?
I ask because the easiest and most secure solution is to make your 4500 VTP transparent and simply recreate vlan 10 and vlan 20. VTP transparent does not allow any updates to modify it's own VTP database.
How was the PFSense device connected to the 4500 ie. a trunk link or an access port ?
Jon
10-14-2011 12:54 PM
We have 2 4507 cabs, both with 2 X 48 port mods. Both linked via 2 X 10gb fiber trunk links (right now using rstp, but I plan to use eatherchannel to get the full 20GB later). One is set to vtp server, the other to vtp client. vtp domain, version2, etc are all identicle on both switches. PFSense was plugged into access ports, I was afraid that truck ports might cause an unforseen issue... like this one :/.
10-14-2011 12:56 PM
If the PFSense was not connected with a trunk then it cannot send a VTP update.
Could you just clarify whether the PFSense was a trunk port or not ?
Are there any other switches apart from the 4500 switches ?
Jon
10-14-2011 01:05 PM
Thanks for the replies Jon.
Yes, there are dumb unmanaged 1gb Netgear switches that will go away, but will also require a major recabling of the colo racks... which is the only reason they are still there
I am 100% certain that PFSense is plugged into access ports. I set those and triple checked them myself before plugging in the router ports. Which is why I am puzzled by vpt reporting the last updte from one of the IPs on the PFSense router. Maybe that is mis-reported and the vtp corruption is a coinicdence?
10-14-2011 01:11 PM
Can I unplug PFSense and then just delete the vlan.dat and reboot the cabs? Then recreate everything from scratch?
10-14-2011 01:16 PM
Yes you can. Delete the vlan.dat/reboot and then if you only have around 5 vlans use VTP transparent and manually create the vlans on each switch.
Jon
10-17-2011 11:34 AM
Note: "delete cat4000_flash:vlan.dat" returned a permission denied error. "erase cat4000_flash:" was the command that worked, just so others with similar issues can save some time
Cheers,
Aubrey
10-14-2011 12:55 PM
With rstp active, I assume that last "none" is correct:
o sh int trunk
Port Mode Encapsulation Status Native vlan
Te1/1 on 802.1q trunking 1
Te1/2 on 802.1q trunking 1
Port Vlans allowed on trunk
Te1/1 1-4094
Te1/2 1-4094
Port Vlans allowed and active in management domain
Te1/1 1,30
Te1/2 1,30
Port Vlans in spanning tree forwarding state and not pruned
Te1/1 1,30
Te1/2 none
10-14-2011 01:15 PM
Aubrey
Yes, the RSTP output is correct because you are currently running the 2 links separately so STP has to block one link otherwise you have a L2 loop. As you say, using etherchannel would be a better way to go.
The PFSense issue is confusing. Without a trunk link it should not be possible to send a VTP update.
If you only have these 2 4500 switches i would do as i suggested before and use VTP transparent to avoid this sort of thing in the future.
Jon
10-14-2011 01:19 PM
Thanks Jon,
I will try that this weekend and let know Monday how it went.
Have a great weekend!
Cheers,
Aubrey
10-17-2011 11:32 AM
Hi Jon,
Thanks for your help! Can you send me a private message, I wanted to communicate with you offline if possible. Thanks!
Cheers,
Aubrey
10-17-2011 11:52 AM
Aubrey
Sent.
Jon
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide