Cisco ASA Fail over Active / Standby

You want to deploy 2 Cisco ASA 55xx Series firewalls in an Active/Standby failover configuration.



Solution


Assumptions.

Hardware on both ASA firewalls is identical.
The correct licence's for failover are installed on both firewalls.
The same software versions are installed on both firewalls.
You have your PRIMARY firewall set up and running correctly (Everything works!).

In this example the firewalls were ASA5510's and all interfaces were being used, so the Management port was used as the "Failover Link" (That needs a security plus licence!).
This Link will use a crossover cable (Only available after version 7.0(2) before that you had to use a switch - I think!).

Also I'm using the same link for LAN Based failover (heartbeat) AND Statefull replication.

IP Addresses

Each interface will need its existing IP address, and an address to use whilst in "Standby". In this example I will use the following,


Click For Larger Image

Outside Interface (Ethernet 0/0) 123.123.123.123 255.255.255.0
Outside Interface STANDBY 123.123.123.124 255.255.255.0
DMZ1 Interface (Ethernet0/1) 192.168.1.1 255.255.255.0
DMZ1 Interface STANDBY 192.168.1.254 255.255.255.0
DMZ2 Interface (Ethernet0/2) 192.168.2.1 255.255.255.0
DMZ2 Interface STANDBY 192.168.2.254 255.255.255.0
Inside Interface (Ethernet 0/3) 172.16.1.1 255.255.255.0
Inside Interface (STANDBY) 172.16.1.254 255.255.255.0
Failover Interface (Management0/0) 172.16.254.254 255.255.255.0
Failover Interface STANDBY 172.16.254.250 255.255.255.0


Step 1 Carry Out this procedure on the PRIMARY (Already configured and working) firewall.

1. Backup the running config on the primary firewall.
PetesASA# copy run flash:/before_failover.cfg

Source filename [running-config]?

Destination filename [before_failover.cfg]?
Cryptochecksum: babed83d 62a5fba7 e5ea368d 642157bd

8549 bytes copied in 3.670 secs (2849 bytes/sec)
PetesASA#

2. Blow away the config on the interface you are going to use for failover.
PetesASA(config)# clear configure interface m0/0
PetesASA(config)# int m0/0
PetesASA(config-if)# no shut
PetesASA(config)#
3. Change the interface IP addresses – (to add the standby addresses for each interface).
PetesASA(config)#
PetesASA(config)# interface Ethernet0/0
PetesASA(config-if)# speed 100
PetesASA(config-if)# duplex full
PetesASA(config-if)# nameif Outside
PetesASA(config-if)# security-level 0
PetesASA(config-if)# ip address 123.123.123.123 255.255.255.0 standby 123.123.123.124
PetesASA(config-if)# interface Ethernet0/1
PetesASA(config-if)# speed 100
PetesASA(config-if)# duplex full
PetesASA(config-if)# nameif DMZ1
PetesASA(config-if)# security-level 50
PetesASA(config-if)# ip address 192.168.1.1 255.255.255.0 standby 192.168.1.254
PetesASA(config-if)# interface Ethernet0/2
PetesASA(config-if)# speed 100
PetesASA(config-if)# duplex full
PetesASA(config-if)# nameif DMZ2
PetesASA(config-if)# security-level 55
PetesASA(config-if)# ip address 192.168.2.1 255.255.255.0 standby 192.168.2.254
PetesASA(config-if)# interface Ethernet0/3
PetesASA(config-if)# speed 100
PetesASA(config-if)# duplex full
PetesASA(config-if)# nameif Inside
PetesASA(config-if)# security-level 100
PetesASA(config-if)# ip address 172.16.1.1 255.255.255.0 standby 172.16.1.254
PetesASA(config-if)# exit
PetesASA(config)#
4. Set up the failover LAN interface (In config mode!).
PetesASA(config)#
PetesASA(config)# failover lan interface failover m0/0
INFO: Non-failover interface config is cleared on Management0/0 and its sub-interfaces
PetesASA(config)#
5. Setup failover link IP address.
PetesASA(config)#
PetesASA(config)# failover interface ip failover 172.16.254.254 255.255.255.0 standby 172.16.254.250
PetesASA(config)#
6. Setup a shared key.
PetesASA(config)#
PetesASA(config)# failover lan key 666999
PetesASA(config)#
7. Set it as the primary firewall.
PetesASA(config)#
PetesASA(config)# failover lan unit primary
PetesASA(config)#
8. Turn on failover.
PetesASA(config)#
PetesASA(config)# failover
PetesASA(config)#
9. Now we need to enable statefull failover.
PetesASA(config)#
PetesASA(config)# failover link failover Management0/0
PetesASA(config)#
10. Save the config.
PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 5c8dfc45 ee6496db 8731d2d5 fa945425

8695 bytes copied in 3.670 secs (2898 bytes/sec)
[OK]
PetesASA(config)#


NOW CONFIGURATION IS FINISHED ON THE PRIMARY FIREWALL, ENSURE THE CABLING IS IN PLACE ON BOTH FIREWALLS THEN CONNECT TO THE STANDBY FIREWALL

Step 2 Carry Out this procedure on the Standby Firewall.

11. Enter enable mode .
ciscoasa>
ciscoasa> en
Password:
ciscoasa#
12. Open the failover link and issue a “no shut” command.
ciscoasa#
ciscoasa# conf t
ciscoasa(config)# interface m0/0
ciscoasa(config-if)# no shut
ciscoasa(config-if)# exit
ciscoasa(config)#
13. Turn on LAN interface for failover.
ciscoasa(config)#
ciscoasa(config)# failover lan interface failover m0/0
INFO: Non-failover interface config is cleared on Management0/0 and its sub-interfaces
ciscoasa(config)#
14. Give it an IP address (YES: that’s the same as the primary firewall there WON’T be a conflict).
ciscoasa(config)#
ciscoasa(config)# failover interface ip failover 172.16.254.254 255.255.255.0 standby 172.16.254.250
ciscoasa(config)#
15. Give it the same key you used above (In step 6).
ciscoasa(config)#
ciscoasa(config)# failover lan key 666999
ciscoasa(config)#
16. Set it as the secondary (standby firewall).
ciscoasa(config)#
ciscoasa(config)# failover lan unit secondary
ciscoasa(config)#
17. Turn on failover.
ciscoasa(config)#
ciscoasa(config)# failover
ciscoasa(config)#
18. You should see......

Detected an Active mate
Beginning configuration replication from mate.

19. When is says that is has ended replication On the secondary firewall, issue a "show failover" (Note: the hostname will have changed to the one on the primary firewall).

PetesASA(config)#
PetesASA(config)# show failover
Failover On
Failover unit Secondary
Failover LAN Interface: failover Management0/0 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 7.2(2), Mate 7.0(5)
Last Failover at: 14:49:43 UTC May 4 2007
This host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
Interface Outside (62.254.170.254): Link Down (Waiting)
Interface DMZ1 (172.31.5.254): Link Down (Waiting)
Interface DMZ2 (172.31.4.254): Link Down (Waiting)
Interface Inside (172.31.3.254): Link Down (Waiting)
slot 1: empty
Other host: Primary - Active
Active time: 514 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.0(5)) status (Up Sys)
Interface Outside (62.254.170.225): Link Down (Waiting)
Interface DMZ1 (172.31.5.1): Link Down (Waiting)
Interface DMZ2 (172.31.4.1): Link Down (Waiting)
Interface Inside (172.31.3.3): Link Down (Waiting)
slot 1: empty
20. To double check go back to the PRIMARY firewall and issue the same command.
PetesASA(config)# show failover
Failover On
Failover unit Primary
Failover LAN Interface: failover Management0/0 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 15 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 7.0(5), Mate 7.2(2)
Last Failover at: 13:21:42 UTC May 4 2007
This host: Primary - Active
Active time: 616 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.0(5)) status (Up Sys)
slot 1: empty
Interface Outside (62.254.170.225): Link Down (Waiting)
Interface DMZ1 (172.31.5.1): Link Down (Waiting)
Interface DMZ2 (172.31.4.1): Link Down (Waiting)
Interface Inside (172.31.3.3): Link Down (Waiting)
Other host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
slot 1: empty
Interface Outside (62.254.170.254): Link Down (Waiting)
Interface DMZ1 (172.31.5.254): Link Down (Waiting)
Interface DMZ2 (172.31.4.254): Link Down (Waiting)
Interface Inside (172.31.3.254): Link Down (Waiting)

21. The failover time out of the box is a bit pants, to nail it down a little, on the PRIMARY ASA
PetesASA(config)#
PetesASA(config)# failover poll 1 hol 3
PetesASA(config)# failover poll interface 3
PetesASA(config)# int m0/0
PetesASA(config-if)# failover poll interface 3
PetesASA(config)#
22. Save the config. (Note: config changed WILL be replicated to the standby firewall).
PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 6650f6c9 09bbb5f0 0dafa0d1 8fc08aba

8756 bytes copied in 3.680 secs (2918 bytes/sec)
[OK]
PetesASA(config)#

23. When done pull the power on ASA 1 to fail. With a constant ping running you usually will only lose 1 ping packet.

CEF and load sharing

Load-sharing is one of the clumsy areas that is full of confusing parts. In this post we should be covering its ABCs, and latter on we should be covering more parts in details. We chose the name “CEF and load sharing” as the post name due to the main role that CEF plays when talking about load sharing.

In IP routing context the forwarding/switching mechanism that the router uses is the actual controller of the load sharing process (data/forwarding plane operation), having multiple routes in the routing table has no significance on how exactly will load sharing be done, you might be left with poor load sharing or no load sharing at all, although you have multiple routes for a certain destination in the routing table.

The routing protocols are responsible for placing multiple paths in the routing table in the first place (control plane operation), by default all the IGPs are capable of inserting 4 equal cost paths, while BGP defaults to only 1 (BGP behaves completely different than the IGPs, we should be covering load-sharing with BGP in details in a later post). To control the maximum paths allowed per routing protocol we can use the maximum-paths command (The maximum was 4 in IOS releases earlier than 11.0, 8 with IOS Release 12.0S based software, 16 with IOS Release 12.3T based software, and 32 with IOS Release 12.2S based software.

NOTE This post is not meant to explain CEF operation, we’ll only be focusing on CEF load-sharing, however we might consider to have a dedicated CEF inside out post later.

The most popular forwarding/switching mechanisms with Cisco routers are; Process switching (performs per-packet load-sharing), fast switching (performs per-destination load-sharing) and CEF (can do both per-packet and per-destination (completely different than fast switching per-destination load-sharing), plus also a new flavor which is per-port load-sharing).

NOTE According to Cisco, IPv4 fast switching is removed with the implementation of the Cisco Express Forwarding infrastructure enhancements for Cisco IOS 12.2(25)S-based releases and Cisco IOS Release 12.4(20)T. For these and later Cisco IOS releases, switching path are Cisco Express Forwarding switched or process switched. This makes the switching decision easier for future development of software features. Starting with the implementation of the Cisco Express Forwarding enhancements and the removal of IPv4 fast switching, components that do not support Cisco Express Forwarding will work only in process switched mode.

Load-sharing with CEF

For each destination with multiple equal cost paths (or unequal-cost in the case of EIGRP using variance, or with BGP using the BGP Link Bandwidth feature and also in the case of MPLS-TE) the router creates a 16 hash buckets, each pointing to one of the available paths.

The load sharing is controlled by the ratio of the number of buckets pointing to each path (outgoing interface), with equal-cost paths the buckets are fairly distributed (two equal cost paths results in 8 buckets per each path, three equal cost paths results in 5 per each (yes, one bucket is omitted), 4 equal cost paths results in 4 per each, and so on). While with unequal-cost scenarios each path will be associated with different number of buckets (according to the load sharing ratio).

CEF has three load-sharing options:
•per-destination (per-session):

I prefer to name it per-session – as stated in the show ip cef x.x.x.x internal command output – since it is actually done based on both the source and the destination IP addresses in the IP packet rather than solely the destination, by hashing both into a 4-bit hash value that is used to select the outgoing interface) – This is the default CEF load sharing option.


Easy AdSense by Unreal

It is clear that per-destination load-sharing performs statistical distribution of traffic, and accordingly load sharing becomes more effective as the number of source/destination pairs increases as compared to lower number of source/destination pairs. Obviously this might result in having one link overloaded while the other(s) underutilized, if a relatively heavy session flows between a certain source/destination pair over this link.

The hash calculation depends on the algorithm used. The original algorithm uses only the source and destination IP addresses to compute a 4-bit hash value, giving 16 probabilities, and thus choosing an outgoing bucket from the 16 available buckets pointing to one of the outgoing paths, this results in all the routers in the network running the same algorithm with the same results, which introduced a load sharing hitch called CEF Load-Sharing Polarization (you can see a good example for this in Cisco press book “Cisco Express Forwarding”). To circumvent this behavior the universal algorithm (the default in current IOS versions) adds a 32-bit router-specific value to the hash function (called Fixed ID, which can be manually controlled – a router uses its highest loopback IP address as this value when booting) and thus seeding the hash function on each router with a unique ID, ensuring that the same source/destination pair will hash into a different 4-bit value on different routers along the path and thus provides a better network wide load sharing and circumvent the Polarization issue.

NOTE There is a third available algorithm called the tunnel algorithm, I couldn’t find or understand its anatomy, but Cisco stated that this algorithm is meant to solve load sharing when tunneling techniques such as MPLS, GRE and L2TP are in operation, since with tunneling the traffic pattern is taken down to a small number of sessions (between the tunnel head/tail ends) which will introduce another form of traffic polarization. This algorithm also uses a unique per-router ID to work around this issue, again I can’t find more details about this algorithm, but if I do I’ll let you know.
•per-packet

Packets are handled in a round-robin fashion, ensuring that the traffic is balanced over multiple links. However, using Per-packet load sharing is not generally recommended, because it most commonly results in out-of-order packets, affecting TCP traffic throughput (since TCP will bother to fix the out-of-order) and UDP data loss (since UDP will not bother to fix the out-of-order) and to make things more scary out-of-order packets might be interpreted as an attack by firewalls.

The default CEF load sharing mode is per-destination, and we can change this using the ip load-sharing per-packet interface command on the outgoing interfaces involved.

NOTE Since load sharing decisions are made on the outbound interfaces, thus either choosing to do per-packet or per-destination load sharing should be done on the outbound interfaces.
•per-port (per-flow)

This is the most adequate option (was introduced with IOS 12.4(11)T release) with networks with low number of sources/destinations with the majority of the traffic between hosts that use different port numbers, commonly seen with Real-Time Protocol (RTP) streams, it simply adds the layer 4 source or destination ports or both in the CEF hashing function. This option is enabled via the ip cef load-sharing algorithm include-ports command in the global configuration.

The most common scenario with this option as the only effective solution is when having a subnet of hosts NATed to a single IP then having a router with multiple paths in the path to their traffic destination, per-destination option is obviously useless in this case if all the hosts are communicating with a single destination, since it is always a single source/destination pair, and accordingly if the layer 4 ports are involved in the hashing function this would enhance the load sharing process.

I hope that I’ve been informative.

Regards
Mirza Mukaram Baig

ARP Caching and TimeOut

From time to time I find myself craving to the fundamentals; I do this for two main reasons, the first one is that fundamentals are the building blocks of all complex networking topics and deeply understanding them makes a better engineer, the second one is longing to simplicity after doing some complex tasks.

One of these fundamentals that is worth reviewing is the Address Resolution Protocol, this protocol is one of the main building blocks of any network existing on earth today.



Every time a network device is sending an Ethernet frame to another device, it constructs a frame and to construct the frame it needs to find the hardware address mapping of the IP address. ARP is responsible for doing this job.

Each time a device sends an ARP message, network resources are consumed. This means that for two hosts to communicate; ARP messages should be exchanged between them and repeated for every packet. Imagine how ugly is this when transferring large data streams like large file exchange via FTP.

ARP caching provides the solution for this efficiency problem as explained below.

ARP Caching

If you know you are going to send many emails to a friend; is it effective to call him every time asking for his email address?. I think the answer is no unless you are fascinated by listening to his voice. Simply you call him one time asking for the address and cache the information somewhere for future uses and that’s exactly what ARP does.

When a host sends an ARP request to another host and a reply is received the sender caches the received information is a table for later use.


Easy AdSense by Unreal

Going back to our analogy of the email sender, what if you know that you are not going to send any more emails to your friend “God keep you friends ” Is it still effective to keep his address in your cache table ?. I think not, you have to timeout unused information. Again this is exactly what ARP does.

If an ARP entry is not used a specific amount of time called the ARP timeout the entry is removed from the caching table.

There is no standard value for this amount of time and it varies from one vendor to another. I will limit my discussion to Cisco devices to clear up the idea.

One more point to mention here is that entries in the ARP table can be static; created by manual configuration or dynamic; created automatically by the normal operation of the protocol. Static entries remain in the table forever and are not timed out.

The default timeout timer for is 4 hours for Cisco devices, this means that a dynamic ARP entry will remain for 4 hours in the cache table before the router attempt to refresh the entry. If the entry is no longer needed it will be removed.

You can show the ARP table using the command show arp and change the timeout timer for a specific interface using the interface level command arp timeout seconds.

Configuration
R1#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.11.1 - sa00.0a11.0001 ARPA FastEthernet0/0
Internet 10.10.11.3 97 sa02.0a11.0002 ARPA FastEthernet0/0
Internet 10.10.11.1 8 sa00.0a11.0003 ARPA FastEthernet0/5
Internet 10.10.11.5 136 sa04.0a11.0004 ARPA FastEthernet0/2

!-- setting the timeout for 10 seconds
R1(config-if)#int f0/2
R1(config-if)#arp timeout 15

!-- see the debug output, shows 15 seconds difference between replies
R1#
Jan 1 00:01:14: IP ARP: sent req src 10.10.10.1 sa00.0a74.0005,
dst 13.13.13.3 ca02.0a74.0008 FastEthernet0/0
Jan 1 00:01:14: IP ARP: arp_process_request: 10.10.10.1, hw: sa02.0a74.0008; rc: 3
Jan 1 00:01:14: IP ARP: rcvd rep src 13.13.13.3 sa02.0a74.0008, dst 13.13.13.1 FastEthernet0/0
Jan 1 00:01:14: IP ARP: creating entry for IP address: 13.13.13.3, hw: sa02.0a74.0008
R1#
Jan 1 00:01:24: IP ARP: sent req src 13.13.13.1 ca00.0a74.0008,
dst 13.13.13.3 ca02.0a74.0008 FastEthernet0/0
Jan 1 00:01:24: IP ARP: arp_process_request: 13.13.13.3, hw: ca02.0a74.0008; rc: 3
Jan 1 00:01:24: IP ARP: rcvd rep src 13.13.13.3 ca02.0a74.0008, dst 13.13.13.1 FastEthernet0/0
Jan 1 00:01:24: IP ARP: creating entry for IP address: 13.13.13.3, hw: ca02.0a74.0008
Note: ARP cache table is not the same as MAC address table used by switches and each one has its own different timers.

Thank you once again.

Regards

How To Install Loop back Adapter in Win 7

I Found while i was searching for installation of Virtual Adapter, 

The key step I was missing was how to find the Hardware Wizard:
Click the Start menu.
Search for “cmd".
Right-click on “cmd” and select “Run as Administrator”
Enter “hdwwiz.exe”
From that point on it's the same approach as under Vista, i.e.:
In the "Welcome to the Add Hardware Wizard", click Next.
Select "Install the hardware that I manually select from a list (Advanced)" and click Next.
Scroll down and select "Network adapters" and click Next.
Select under Manufacturer "Microsoft" and then under Network Adapter "Microsoft Loopback Adapter" and click Next.
I've tested this and it's working for me (connecting the host to a VPC using the loopback adapter).

Cisco Catalyst 2960 switch IOS recovery

Sometimes in my lab happens that students delete IOS of the switch from its flash. Unfortunately switches does not have rommon to realize quick IOS recovery over tftp. Only one way is over Xmodem.

Cat 2960 switchIOS recovery

To speed up the process of the recovery we may setup Xmodem speed to higher rate as default 9600 bits:

Set the speed rate to 115200 baud on the switch prompt of the switch:

switch: set BAUD 115200

Of course we lose our console session and therefore we need to restart it with the correct speed settings. Then  we may realize the recovery.

Enter copy command:

copy xmodem: flash:filename

for our Cat2960-24TTL:

switch:copy xmodem: flash:c2960-lanbasek9-mz.122-52.SE.bin
Begin the Xmodem or Xmodem-1K transfer now...
CCC

and start sending of the file over console Xmodem software.

Recovery over HyperTerminal

Choose Transfer > Send File.

 

and than we choose as protocol the Xmodem and in filename click Browse and select the Cisco IOS image (.bin file) from the disk to be uploaded.

and click Send to send the file,

Recovery over Putty

Putty does not support Xmodem protocol, tears.

Final steps

To boot the new image that we just copied over with the Xmodem procedure issue the boot flash:filename command, as the example shows:

switch: boot flash:c2960-lanbasek9-mz.122-52.SE.bin

After the Xmodem recovery, we set the BAUD rate back to 9600. If the set BAUD 9600 command does not bring the baud rate to 9600, issue the unset BAUD command in order to bring the baud rate to a default value of 9600 bps.

Connect Vmware VM 2 GNS3 Lab

1. Select network adapter "Host only" to your Virtual machine in Vmware 
2. Check from Windows Network connections how this network adapter (vmnet1) is named.
3. Add cloud to your workspace in GNS3
4. Configure cloud and select the network adapter you just checked from Windows Network connections menu.

• Right Click cloud and select Configure
• Select your cloud C0
• Select NIO Ethernet
• Select Generic Ethernet NIO
• Select appropriate adapter from drop-down menu and press Add button

5. Connect cloud to your topology. (For example to router)
6. Assing IP addresses from same subnet to the Virtual Machine and to emulated router in GNS3.
7. Ping between router and virtual machine should be successful.

Configure the Native VLAN on Both Side Of The Trunk

Be sure to remember to configure the native VLAN on both sides of the trunk link or you will get this error until you do so (or disable CDP):

*Mar  1 01:35:01: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/13 (1), with sw1 FastEthernet0/13 (10).

They come in once every minute (CDP updates go every 60 seconds by default):

*Mar  1 01:38:01: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/13 (1), with sw1 FastEthernet0/13 (10).
*Mar  1 01:39:01: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/13 (1), with sw1 FastEthernet0/13 (10).
*Mar  1 01:40:01: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/13 (1), with sw1 FastEthernet0/13 (10).

sw2(config-if)#do sh cdp
Global CDP information:
        Sending CDP packets every 60 seconds
        Sending a holdtime value of 180 seconds
        Sending CDPv2 advertisements is  enabled

What happens if you disable CDP?  Will you still get the error?

sw1:
sw1(config)#do sh run int fa0/13
Building configuration…

Current configuration : 128 bytes
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 10
 switchport mode trunk
end

sw2:
sw2(config-if)#do sh run int fa0/13
Building configuration…

Current configuration : 110 bytes
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no cdp enableend

***
sw1#sh int fa0/13 trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/13      on           802.1q         trunking      10

sw1#sh int fa0/13 switch | i Native VLAN
Administrative Native VLAN tagging: enabled

sw1#sh cdp int fa0/13
FastEthernet0/13 is up, line protocol is up
  Encapsulation ARPA
  Sending CDP packets every 60 seconds  Holdtime is 180 seconds

sw2#sh int fa0/13 trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/13      on           802.1q         trunking      1

sw2#sh int fa0/13 switch | i Native VLAN
Administrative Native VLAN tagging: enabled

sw2#sh cdp int fa0/13
[Note: No output because we've disabled CDP]sw2#

It’s been a few minutes and no alarms(on either switch):

*Mar  1 01:42:14: %SYS-5-CONFIG_I: Configured from console by console
sw1#sh clo
*01:48:09.468 UTC Mon Mar 1 1993

*Mar  1 01:41:51: %SYS-5-CONFIG_I: Configured from console by console
sw2#sh clo
*01:45:09.826 UTC Mon Mar 1 1993

Another good reason to run CDP.