We have a couple of ASA 5510s running OS v7.0(6) setup with A/S failover.
The firewall has 4x 100mbps interfaces. These interfaces have been configured as follows
e0: Outside (internet facing)
e1: Inside (internal facing)
e2: 802.1Q trunk (DMZ subinterfaces with various security levels)
e3: 802.1Q trunk (DMZ subinterfaces with various security levels)
I am attempting to setup 802.1Q trunk on the e1 interface which connects back to a 6509 running CatOS 8.4(6) on the active firewall and IOS 12.2(17) on the standby firewall.
When I complete the setup, connectivity between the FW devices and the 6509's fails. By that I mean L2 and L3 connectivity (ie. SPAN shows no traffic on the uplink to the firewall)
Can anyone offer any insight on the root cause of my problem?
I have inlcuded an extract of the configuration here for your review:
no ip address
no nameif inside
ip address 172.19.1.1 255.255.255.0 standby 172.19.1.2
ip address 192.168.7.1 255.255.255.0 standby 192.168.7.2
Set vlan 8 name ABC
trunk 1/5 on dot1q 1-4094
sw trunk encap dot1q
sw mode trunk
sw trunk allow vlan add 1
sw trunk allow vlan add 8
Thanks in advance
The configuration looks correct.
Can you please check if the interfaces on both the ASA and the switch is showing Up/Up status?
Assuming you have VLAN interfaces configured on the L3 switch, can you see if you can ping to and from the ASA?
Bewildering isn't it?
Yes, interfaces on both ends were up/up. No L2 or L3 traffic was traversing the wire.
The switch was set to use .1q with the trunk in the On mode. I believe the firewall is always on, just by creating subinterfaces, or am I wrong in this assumption? (ie. Do I need to specifically state the .1q encapsulation? I havent done this on the DMZ interfaces and they work a treat so I'm guessing not)
Absolutely correct. Nothing needs to be configured on the ASA physical interface. Just need to create subinterface and it becomes trunk port.
Last resort would be checking the cable, or possibly trying different interface on the switch.
Unfortunately, there are no additional interfaces, hence the need for the trunk. And the cable is currently connected and passes traffic without incident.
Adding a trunk is not a L1 issue so its not going to be the cable.
I havent done anything incorrectly, or missed nything on the CatOS have I?
You do not need to setup trunk port if your fire inside address is on the same subnet on
your 6509 vlan port. or adding this might help on your both core switches.
switchport mode dot1q-tunnel. Might have to increase mtu size to 1504 on your
description inner vlan 1,8
switchport access vlan 8
switchport trunk encapsulation dot1q
switchport mode dot1q-tunnel
no cdp enable
vlan 8 is created in the switch's database? Also vlan 1 is this native vlan? If so packets will come untagged but we would be expecting them tagged.
What do captures on the interfaces show?
cap capin int inside
sh cap capin
cap capabc int abc
sh cap capabc
Are packets leaving the interface? Are there any packets coming back to the interface?
Thanks for your feedback.
The native vlan on the switches is vlan 1. I assume this is the case on the ASAs aswell since I see no config suggesting otherwise. How do I check this?
If both devices have vlan 1 as their native vlan both will not tag the packets and as such it shouldn't affect traffic, right?
Regarding captures, I didnt run one on the firewall (this a production environment so I cant test again right now), however I had SPAN running on the switch port the FW is connected to. It shows no traffic, what-so-ever - which seems odd to me, shouldnt I at least see traffic improperly tagged, or does the switch drop it before it copies it to the destination span port?
Pls. refer this link below:
Preventing untagged packets on the physical interface—If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets.
Since this is a sub-interface that is configued for vlan1 we would send packets with tags out of our interface.
What do captures show?
I'm not sure what that article is suposed to demonstrate. I am not passing traffic out the physical interface in the scneario mentioned above. I am however, as you say, passing traffic out the vlan 1 interface and as it is the native vlan .1q will pass this untagged. But the switch also has vlan 1 as its native vlan so it will expect the packets untagged, will it not?
Packet captures on the switch interface show absolutely no traffic was received on the port connected to the firewall once I created the sub interfaces. When I removed the sub interfaces and used the physical inerface I could see traffic flow again as expected.
It sounds to me like I need to run this setup again with captures on the firewall itself. Typically I dont do this as the captures arent very informative and I rely on SPAN on the connected switch interface. Is SPAN something that is available on the ASA? If I can use that then I can run some captures for further diagnosis.
The switch might drop it. If you had captured on the ASA you might have seen it sending arp request packets with vlan 1 tag and no packets received.
Next time you do this test if you could try the following that would be good.
1. instead of vlan 1 configure some other unused vlan (create one on the switch)
2. create a layer 3 interface on the switch (int vlan blah) and give it an ip address.
3. try to ping from the switch to the asa and vice versa. It should work.
4. If the above works then you can remove this layer 3 interface on the switch and configure the interface on the ASA with a standby IP address and see if failover will sync up and you can ping the ASA interface connected to the other switch.
5. If option 3 doesnt work then captures on the ASA and span on the swtich are our only option. Captures on the ASA is a must. I'd like to see if the packets are leavin the firewall interface.
Those were my thoughts aswell hwoever I had limited time to play around (only 10 minutes). I will look at testing again using something other than vlan 1.
Is there a more detailed method of packet capture on the ASA than just the packet hit count? Ie. can I do SPAN?
They syntax that I provided will capture packets that you can save as .pcap file and view it using wireshark.
Follow this link for more information: packet capture ASA/PIX/FWSM: https://supportforums.cisco.com/docs/DOC-1222
Thanks for your input.
The trunk is required as multiple VLANs will traverse the link (see vlan 1 & 8 in my sample config).
According to Cisco's CLT, the dot1q-tunnel command is a script, and it implements the switchport mode trunk comand along with disabling cdp and enabling bpdu filtering. Those last 2 I dont need, as the firewall supports neither packet type, and the first has been implemented as you will note in my config.
I was confused Scott sorry, #1 ASA5510 only supported 10/100 speed unless you have 4 Gig SSM card, #2 your active firewall is running 8.4 or your supervisor Cat OS?? And IOS 12.2 on standby firewall??
Any way below config should fix your trunk issue on your switch I hope. My end is working fine.
description ASA 5510 Ethernet0/1 Trunk
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,8
switchport mode trunk
no ip address
I think you misunderstand my scenario.
I have 2x ASA 5010's connected to each other and operating in failover mode. One of these (the active ASA) is connected to a 6509 running CatOS 8.4. The other (the standby ASA) is connected to a different 6509 running IOS 12.2.
When I create the trunk between the ASAs and the 6509's, as per the config listed above, traffic does not traverse the link. The link is in the up/up status but I see no traffic hitting the swithc ports the ASAs are connected to. I am using SPAN to monitor these ports and it provides me ziltch/nudda/nothing once the trunks are configured.
You will also note that my configuration already delivers the meat of what you have suggested.
Thanks Scott for your clarification. Since active and standby firewall is connected to two switches I assuming SVI has been setup between your 6909s. You probably need to enable ""firewall multiple-vlan-interfaces" on your 6509 device but please verify first.
I was able to resolve this issue. It turned out that, as expected, I was not tagging the native vlan (vlan 1) on the 6500s whereas the firewall was. Subsequently when one device type sent to another the frames were not tagged as expected and dropped. Enabling native vlan tagging (which needs to be done globally first and then secondaly on the desired interface) did the job.
Thanks for everyones input, much appreciated.