The 4000 series does things a little differently with Bridge groups then older ISRs. The below is on a Cisco ISR 4331. In this case I needed to have a bridge group to go to two separate switches, one port would be blocked by spanning tree to keep loops out.
a Bridge-group, Groups the physical interfaces into one logical group. and the Bridge Virtual Interface (BVI) is the layer 3 routing interface associated to that bridge group.
In this scenario I have two vlans 4006 and 4007, I will create a bridge group so basically the two ports of the bridge group are a switch. Spanning tree will pass through the bridge group and one of my ports will be blocked. The reason for the bridge group if that I have two Distro switches and I want to have switch redundancy (Yes, I know the router is still a single point of failure). If one of my core switches die, it should be only a few seconds and I will be back up and going at Layer2 to my core. In this scenario I have a reason to not use ECMP or routing on the router interconnects – I need to keep them at layer 2.
Config:
bridge-domain 4006
bridge-domain 4007
interface GigabitEthernet0/0/0
description **Connected to Primary Core**
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 1
!
service instance 4006 ethernet
encapsulation dot1q 4006
rewrite ingress tag pop 1 symmetric
bridge-domain 4006
!
service instance 4007 ethernet
encapsulation dot1q 4007
rewrite ingress tag pop 1 symmetric
bridge-domain 4007
!
int gig 0/0/2
description **Connected to Primary Core2**
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 1
!
service instance 4006 ethernet
encapsulation dot1q 4006
rewrite ingress tag pop 1 symmetric
bridge-domain 4006
!
service instance 4007 ethernet
encapsulation dot1q 4007
rewrite ingress tag pop 1 symmetric
bridge-domain 4007
!
!
interface BDI1
no ip address
shutdown
!
interface BDI4006
ip address 1.1.1.1 255.255.255.0
!
interface BDI4007
ip address 2.2.2.1 255.255.255.0
no ip redirects
!
Thats, it. The Vlan and vlan interfaces are up and working. When I check spanning-tree on the switch I see the correct one blocked – which could totally be load balanced or modified.
Cisco ASA (Pre X series) are still extremely common.
This entry describes a redundant VPN setup of two ISPs on the Branch firewall (Cisco 5505), and one ISP on the Datacenter/hub side (Cisco ASA 5510).
The Branch office has a cable connection as their primary ISP and a backup 4G Cradle Point. We will be using SLAs to track the internet status of the Cable connection, and a floating static route to control backup route priority.
The idea behind the branch office is that two different Crypto Maps exist, one mapped to each of the interfaces. If the SLA fails and brings down the primary internet the traffic starts going out of the backup connection which has a backup Crypto map applied. When the primary interface comes back up, then traffic will start going over the crypto map applied to it. Therefore we do not have flip/flop VPNs and it solves the issue of having one crypto map applied to two different interface.
interface Vlan2
nameif PRIMARY
security-level 0
ip address 1.1.1.10 255.255.255.0
!
interface Vlan12
nameif BACKUP
security-level 0
ip address 2.2.2.10 255.255.255.0
object-group network CORE-SUBNETS — Object group for Core subnets
network-object 10.0.0.0 255.255.255.0
network-object 192.168.0.0 255.255.255.0
object-group network BRANCH-SUBNETS — Object group for Branch subnets
network-object 192.168.18.0 255.255.255.0
object network Any-Cable — NAT For Primary
nat (inside,PRIMARY) dynamic interface
object network Any-Backup — NAT For Backup Internet
nat (inside,BACKUP) dynamic interface
NO-NAT
nat (inside,any) source static BRANCH-SUBNETS BRANCH-SUBNETS destination static CORE-SUBNETS CORE-SUBNETS
SLA config:
sla monitor 123
type echo protocol ipIcmpEcho 8.8.8.8 interface PRIMARY
sla monitor schedule 123 life forever start-time now
route PRIMARY 0.0.0.0 0.0.0.0 1.1.1.1 1 track 2 – The Track statement maps that SLA to the route
route BACKUP 0.0.0.0 0.0.0.0 250 – Floating Static – Makes this a backup route. I set the distance to 250
access-list VPN-to-CORE permit ip object-group BRANCH-SUBNETS object-group CORE-SUBNETS
crypto ipsec ikev1 transform-set AES256SHA esp-aes-256 esp-sha-hmac
Primary Crypto
crypto map BRANCH_MAP 100 match address VPN-to-CORE
crypto map BRANCH_MAP 100 set peer 3.3.3.1
crypto map BRANCH_MAP 100 set ikev1 transform-set AES256SHA
crypto map BRANCH_MAP 100 set security-association lifetime seconds 28800
crypto ikev1 enable PRIMARY
crypto map BRANCH-MAP interface PRIMARY
BACKUP Crypto MAP
crypto map BRANCH-MAP-BK 100 match address VPN-to-CORE
crypto map BRANCH-MAP-BK 100 set peer 3.3.3.1
crypto map BRANCH-MAP-BK 100 set ikev1 transform-set AES256SHA
crypto map BRANCH-MAP-BK 100 set security-association lifetime seconds 28800
crypto map BRANCH-MAP-BK interface BACKUP
crypto ikev1 enable BACKUP
crypto ikev1 policy 10
authentication pre-share
encryption aes-192
hash sha
group 2
lifetime 86400
tunnel-group 3.3.3.1 type ipsec-l2l
tunnel-group 3.3.3.1 ipsec-attributes
ikev1 pre-shared-key password
object-group network CORE-SUBNETS — Object group for Core subnets
network-object 10.0.0.0 255.255.255.0
network-object 192.168.0.0 255.255.255.0
object-group network BRANCH-SUBNETS — Object group for Branch subnets
network-object 192.168.18.0 255.255.255.0
NO-NAT
nat (inside,any) source static BRANCH-SUBNETS BRANCH-SUBNETS destination static CORE-SUBNETS CORE-SUBNETS
access-list VPN-to-BRANCH permit ip object-group CORE-SUBNETS object-group BRANCH-SUBNETS
crypto ipsec ikev1 transform-set ESP-AES-256-SHA-TRANS esp-aes-256 esp-sha-hmac
crypto map outside_map 100 match address VPN-to-BRANCH
crypto map outside_map 100 set peer 1.1.1.10 2.2.2.10 —Notice both IPs
crypto map outside_map 100 set ikev1 transform-set ESP-AES-256-SHA
crypto map outside_map 100 set reverse-route
crypto ikev1 enable outside
crypto map outside_map interface outside
crypto ikev1 policy 10
authentication pre-share
encryption aes-192
hash sha
group 2
lifetime 86400
tunnel-group 1.1.1.10 type ipsec-l2l
tunnel-group 1.1.1.10 ipsec-attributes
ikev1 pre-shared-key password
tunnel-group 2.2.2.10 type ipsec-l2l
tunnel-group 2.2.2.10 ipsec-attributes
ikev1 pre-shared-key password
The other day I needed to use the the blue mini-USB console cable that Cisco will now send. Its been around a long time, but I always have my normal console laying around and just use that. When I attempted to use it I first installed the USB driver provided by Cisco, everything seemed to work, but I could not open the com port. Today I did some research and got it working – I was just missing a small part, but thought I would write up the steps to try and help someone else. My OS is Windows 10.
So first we have to install the USB driver this can be downloaded from Cisco.com , using your CCO account. Then install according to the computer, and then reboot. The problem comes in after the reboot – Windows will use the Windows USB driver, and not the Cisco one. So you have to manually change it.
So to walk through, after the install/reboot I connected the cable – Went into device manager to see what com port it was associated to. Com3. Great, then I tried to console to that port – and it would not work.
So, after a lot of troubleshooting I found that you need to update the driver to a locally install one, and when you do that Cisco’s driver will pop up. Those steps are below.
So, lets first change the driver.
Select “update driver software”
Then Select “Let me pick from a list of device drivers on my computer”
Bam! Now, select the Cisco driver.
Now, we see that Cisco serial driver is in use.
So, now we should be able to launch Putty and change it to COM3 and it should work.
Thats it!
cisco usb console driver not working
Cisco USB
Unsupress maps in Cisco can really be a very helpful tool in situations where you might be summarizing a bunch of /24s to maybe a /20, but you need to leak out one of the /24s without summarization, and still advertise the larger summary route.
By default, once you use summarize all networks that fall under your summary route do not advertise any more. In my situation I was testing ECMP and needed to advertise one /24 to each of my MPLS neighbors, so my hub router could get back on either path. I couldn’t test this with the full /24 due to outage concerns so we had to do this for a /24 that was not used that often. I am not going to show the layout of the Dual MPLS , but just one.
Below shows the topology
Great, now for config on the Cisco Routers.
Steps:
My Prefix list name will be UMAP and my route-map will be named UMAP-MAP
So lets take a look at our advertised routes to my neighbor 10.0.5.22 before making the changes.
Notice that just the /20 is being advertised. Now check out the config below, and lets apply.
config t
ip prefix-list UMAP seq 5 permit 10.32.39.0/24
route-map UMAP-MAP permit 10
match ip address prefix-list UMAP
router bgp 64551
neighbor 10.0.5.22 unsuppress-map UMAP-MAP
Then clear update BGP
clear ip bgp * soft
So that’s it for the config. Lets look at the advertised routes now.
Great! we are advertising our /24 and everything is now working perfectly. Unsuppress maps to the rescue!
Recently I created a tunnel for a client between two Cisco ASAs, and they monitor VIA PRTG and make automated backups via Solarwinds. After the tunnel creation, all traffic worked great except traffic (SSH,SNMP,PING) directed to the device’s inside interface. There are a few simple command that fix this. In this entry I will point out those commands and explain why the commands actually fix the issue.
So the above images shows a simple layout of what I have going on. All is working with the VPN, its up and functioning everything is great accept access to the ASA itself from the remote subnet. The ASA in question is 192.168.19.1/24.
There are really two commands here. First:
Management access <Inside interface>
As Cisco States it:
“If your VPN tunnel terminates on one interface, but you want to manage the ASA by accessing a different interface, you can identify that interface as a management-access interface. For example, if you enter the ASA from the outside interface, this feature lets you connect to the inside interface using ASDM, SSH, Telnet, or SNMP; or you can ping the inside interface when entering from the outside interface”.
Awesome, so that allows us to actually use the inside for management when connecting through a different interface (VPN). For me this did not work, still could not access the device from the remote subnet.
The next command that resolved the issue for me had to do with my nat statement. The firmware version of this device is 9.x, so we use object based nat to do our NO-NAT statements.
nat (inside,outside) source static LOCAL-NETWORKS LOCAL-NETWORKS destination static 10.0.0.0/24 10.0.0.0/24 route-lookup
to note, local networks is a group that has my 192.168.19.0/24 subnet in it.
The route-lookup command on top of the NO-NAT resolve the issue. The reason being is that when packets are sent to a destination the device looks for the needed egress interface or in this case the interface specified in our NAT rule which is “outside”. This makes a lot of sense. But, we don’t want to send this traffic out of the WAN interface, we want to send it out of the tunnel. So specifying the command route-lookup tells the firewall to look at the routing table for the entry and then forward the packet accordingly, basically overriding the identity NAT statement interface (interface listed int the NO-NAT). According to Cisco the ASA looked at the routing table by default in older firmwares but to make this more flexible with NAT, now you have to specify the keyword.
That’s it all communication to your ASA should now work.
I decided to write up the steps so I could always refer back to this if I get hit in the head really hard and forget, which is very likely to happen. Remember to always read the release notes of the firmware you are installing.
In this case I have Cisco ASA 5505 running newer 9.X firmware, and just want both the ASA and ASDM images to be the latest suggested. In this scenario I am using TFTP64 to copy the files over but if I had a Flash drive handy I would have went that route.
First I downloaded the newest images from Cisco, both for the ASDM and the ASA firmware.
Then I moved those over to my TFTP server directory. On the ASA I will run these commands to copy the files to flash, then set options to boot to those images.
VIP-ASA# copy tftp flash
Address or name of remote host: 192.168.19.10
Source filename: asa917-12-k8.bin
Destination filename:asa917-12-k8.bin
Accessing tftp://192.168.19.10/asa917-12-k8.bin…!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
26709020 bytes copied in 33.860 secs (809364 bytes/sec)
Now to copy over the ASDM image
VIP-ASA# copy tftp: flash
Address or name of remote host: 192.168.19.10
Source filename: asdm-771.bin
Destination filename: asdm-771.bin
Accessing tftp://192.168.19.10/asdm-771.bin…!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
26709020 bytes copied in 33.860 secs (809364 bytes/sec)
Great, our images are on the flash, now we need to set our boot variables.
VIP-ASA(config)# boot system flash:/asa917-12-k8.bin
INFO: Converting flash:/asa917-12-k8.bin to disk0:/asa917-12-k8.bin
Remove the old boot variable
VIP-ASA# show boot
BOOT variable = disk0:/asa917-12-k8.bin
Current BOOT variable = disk0:/asa917-12-k8.bin;disk0:/asa821-k8.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
VIP-ASA# config t
VIP-ASA(config)# no boot system disk0:/asa821-k8.bin
VIP-ASA(config)# show boot
BOOT variable = disk0:/asa917-12-k8.bin
Current BOOT variable = disk0:/asa917-12-k8.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
VIP-ASA(config)#
Set your ASDM image to the new one, and then check your ASDM boot image
config t
VIP-ASA(config)# asdm image disk0:/asdm-771.bin
VIP-ASA# show asdm image
Device Manager image file, disk0:/asdm-771.bin
Now save config, and reboot – That’s it! Reading the release notes is super important to know what has changed, and if there is a certain firmware you need to be at before upgrading. In this example I upgraded to 9.1.7 and ASDM 7.7.1. If you were upgrading VIA USB it is basically the same config, except replace tftp with usb.
Recently we were troubleshooting some network issues with a Cisco 1242 AP that suddenly stopped communicating with our WLC.
Controller firmware is 8.0.133
We consoled into the AP and found logs that looked like below. Then we logged into the WLC and saw similar logs.
Seems the AP cert had expired. To get around this we had to enable a command in the WLC that ignored the AP cert. The happened because the Manufacturer Installed Certificate (MIC) has now become older than ten years and has expired. This will not be accepted now.
I SSH’d into the controller and ran the below command:
config ap cert-expiry-ignore mic enable
This allowed the AP to come back online immediately.
If you happen to be on 7.0.252.X the command and logs are different:
log example:
Failed to complete DTLS handshake with peer 10.32.41.96 for AP 00:1d:45:36:97:30
*spamReceiveTask: Sep 19 21:42:59.855: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 10.32.41.101 for AP 00:1d:45:56:b6:1c
Each log will of course be different due to IP/MAC. The commands to resolve this:
config ap lifetime-check {mic|ssc} enable
So:
config ap lifetime-check mic enable
config ap lifetime-check ssc enable
That should do it!
Cisco information:
This configuration was in ASA 8.4
Spoke to spoke communication has always been super easy in ASA Site to Site VPNs. As long as your CRYPTO ACL has the remote subnets in it, and NO-NAT Statements are there everything pretty much works.
The other day I had an issue getting it to work. After some research I was still struggling. All of my remote sites were in my Crypto ACL, my VPN was up and working to the hub, and any subnet behind the hub would work, but access to other IPSEC tunnels connected behind were not working. See rough sketch of the network below.
I checked Nat statements, looked great, but my traffic was not flowing. I decided to debug via ASDM this is the error I received.
Routing failed to locate next hop for ICMP then my outside (Louisville), and inside (Italy) address.
Other examples are:
Routing failed to locate next hop for TCP then my outside (Louisville), and inside (Italy) address.
Routing failed to locate next hop for UDP then my outside (Louisville), and inside (Italy) address.
Well, 192.168.17.0/24 does not live inside my firewall – it should be connected to the outside (US-Signal) VIA the VPN. Boom, that’s when it clicked. My nat statement is wrong, well not wrong, just missing. Since these connections are connecting to my outside network, and then going to my outside network – I need to create the nat statement with the source interface and destination interface being US-Signal.
A few things to note about the below statement – I put it at the top of my manual nat entries, and notice the interface – both are US-Signal my outside interface.
object network Louisville-Subnet
subnet 10.26.0.0 255.255.0.0
object network Italy-Subnet
subnet 192.168.17.0 255.255.255.0
nat (US-Signal,US-Signal) source static Louisville-Subnet Louisville-Subnet destination static Italy-Subnet Italy-Subnet no-proxy-arp route-lookup
As soon as I added this statement everything worked great. All of my spoke to spoke communication flowed through the hub perfectly.
Before learning the more about Manual or “Twice Nat” I would use individual object NAT (Auto NAT) for my incoming services, and use Manual NAT for my No-NAT or if I had to NAT VPN traffic before encryption (Policy NAT).
Recently though I started using it for everything. Once you get the hang of it, it is much more applicable to everyday NAT needs.
Something to note about Manual NAT:
Lets get started with a few examples. A list of all examples is below:
Static NAT – Public address/server to Private address/service
Group/Range of services forwarded into private server
Port redirection
Dynamic NAT
Policy Based Nat
Something to always note – 8.3 and above firmware’s require you to put in the private or real ip address of destination , not the public or Natted address.
Static NAT – Public address/server to Private address/service
Lets say my internal web servers is at 10.20.20.10. The external IP I am using is 23.4.3.10. I want to NAT in only HTTP (80) traffic to my server. No problem.
Lets create the our address Objects
object service OBJ-TCP-80
service tcp source eq 80
object network OBJ-10.20.20.10
host 10.20.20.10
object network OBJ-23.4.3.10
host 23.4.3.10
Great! Now lets create our Manual nat rule to allow that traffic in.
nat (inside,outside) source static OBJ-10.20.20.10 23.4.3.10 service OBJ-TCP-80 OBJ-TCP-80
Thats it, we would create our ACL to allow traffic to the Private host (Remember that, big time change in 8.3) and that’s it. Our traffic would be natted from Public, to Private port 80.
The next example will be a 1 to 1 NAT from our private object created above, to our public object also created above.
NAT (inside,outside) source static OBJ-10.20.20.10 OBJ-23.4.3.10
Modify the ACL to allow traffic to 10.20.20.10 and traffic should make it to the host.
Forward in a group or range of services
In this example we will forward in a group of service objects. Lets say HTTP, HTTPS, and SSH . Still using our local/public hosts. You have two options, 1 create a service group full of existing objects, or create a group of Service-objects. Int the below example I will create a group of predefined objects. This is due to having so many different configurations of groups.
object service OBJ-TCP-80
service tcp source eq 80
object service OBJ-TCP-443
service tcp source eq 443
object service OBJ-TCP-22
service tcp source eq 22
object-group service Web-services
group-object OBJ-TCP-80
group-object OBJ-TCP-443
group-object OBJ-TCP-22
object network OBJ-10.20.20.10
host 10.20.20.10
object network OBJ-23.4.3.10
host 23.4.3.10
So now our NAT rule:
nat (inside,outside) source static OBJ-10.20.20.10 23.4.3.10 service Web-services Web-services
Port redirection
Sometimes we have the need to make a port such as 8080 on the outside go to our websever on the inside at port 80. The below example shows how to do that. In this example we will forward in port 8080 on our public IP to port 80 on our private webserver. First we need to create the objects for the service and networking addresses, and then apply the nat rule – an don’t forget our ACL. To help visualize whats happening here look at the format of the rule:
nat (source interface,destination interface) source static object ((private) IP) object ( Natted (Public IP)) service Private-Service Public-Service
object service OBJ-TCP-80
service tcp source eq 80
object service OBJ-TCP-8080
service tcp source eq 8080
object network OBJ-10.20.20.10
host 10.20.20.10
object network OBJ-23.4.3.10
host 23.4.3.10
So now our nat rule:
nat (inside,outside) source static OBJ-10.20.20.10 23.4.3.10 service OBJ-TCP-80 OBJ-TCP-8080
Dynamic NAT
I like to usually do this through Auto nat, but you can most definitely do this through Manual.
object network OBJ-10.0.0.0/8
host 10.0.0.0/8
nat (inside,outside) source dynamic OBJ-10.0.0.0/8 interface
You could also specify “any” instead of the internal address object, or specify the public IP you want to be natted to instead of “interface”.
Policy Based manual NAT
Manual NAT is the only way I believe that Policy based natting is done. You would use this if you had to NAT traffic into some other IP when going to a certain destination address. In this example lets say we need to NAT traffic from 10.0.0.0/8 int 1.1.1.1 when going to destination 3.3.3.3. This comes up a lot in healthcare when both sides need to nat into a Public address so there are no address conflicts.
Lets first create our objects, then our Nat rule.
object network OBJ-10.0.0.0/8
host 10.0.0.0/8
object network OBJ-3.3.3.3
host 3.3.3
object network OBJ-1.1.1.1
host 1.1.1.1
So now our nat rule:
nat (inside,outside) source static OBJ-10.0.0.0/8 OBJ-1.1.1.1 destination static OBJ-3.3.3.3 OBJ-3.3.3.3
This reads that whenever 10.0.0.0/8 is going to 3.3.3.3, nat 10.0.0.0/8 into 1.1.1.1. This might help:
nat (inside,outside) source static Private-IP Natted-IP destination static Real-destination Natted-Destination
So, if this was used for a VPN you would just create an Crypto-ACL and the source would be your Natted-IP, and destination would be your 3.3.3.3 or whatever address lives across the tunnel that you set as your NAT destination.
Errdisable is an extremely cool feature on Cisco switches that can place a port into a disabled state due to some reason/errors on the port. There are many reasons a port can be disabled:
Duplex mismatch
Port channel misconfiguration
BPDU guard violation
UniDirectional Link Detection (UDLD) condition
Link-flap detection
Security violation
Port Aggregation Protocol (PAgP) flap
DHCP snooping rate-limit
Incorrect GBIC / Small Form-Factor Pluggable (SFP) module or cable
And many more. Here is Cisco’s Documentation :http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/69980-errdisable-recovery.html
The beauty of this feature is that if I screw something up, or if for example a I configure Port security and there’s and error it will shut down the port so that horrible things like loops or security violations are not allowed. By default Err-disable will shut down the port and it will take a manual shut/no shut of the port.
Finding out what ports and why they were put into ERRDisable
It is very frustrating to see ports come online, and then get shut off for some unknown reason. We can find out why they were shut off with a few simple commands
to find out what ports might be having errdisable problems we can do a :
show interfaces status errdisable
This command will show us all ports that are currently shutdown due to errdisable and the reason why. You can also get more specific with the :
show interfaces gig 1/0/12 status errdisable
to get more information just from that port.
You can of course also see what is happening through the logs or syslog showing something like this
%SPANTREE-SP-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port.
Auto Recovery options
So how can we make this a temporary setting – what if I was putting a switch in a school, and I want to make sure that if someone plugs up another switch, and I see a BPDU, I shutdown the port and then want that port to come back online in x amount of time. There are two parts to that problem. 1, you have to set BPDU Guard on the port or whole switch. Once that is setup, it will automatically be put into Err-disable state. Now, to bring it out of that state automatically, we have to modify the err-disable recovery option, and the cause option (unless we want all causes to automatically come back up – which might not be good). There are a few commands to help us figure out what has been set already:
Show errdisable recovery
This command will report back to you any recovery options that have been set, and the default recovery value of 300 seconds.
Show errdisable detect
This command will show you if we are detecting this error. By default all should be detecting.
So, lets say I only want BPDUguard to recovery iteself every 60 seconds. This is what I would do:
Config t
errdisable recovery cause bpduguard
errdisable recovery interval 60
This will effectively enable recovery only for BPDUguard, and will change ALL recovery times to 60 seconds.
The following is the show recovery after the change:
Errdisable is a great feature that Cisco implements in almost all of their switches. It can really save some pain if you incorrectly configure a etherchannel, or have a bad cable that is really sending a ton of CRCs.
Recent Comments