...or why a shut interface is not always shut...
Copying from Wikipedia:
Address Resolution Protocol (ARP) spoofing, also known as ARP poisoning or ARP Poison Routing (APR), is a technique used to attack an Ethernet wired or wireless network which may allow an attacker to sniff data frames on a local area network (LAN), modify the traffic, or stop the traffic altogether (known as a denial of service attack). The attack can obviously only happen on networks that indeed make use of ARP and not another method.
The principle of ARP spoofing is to send fake, or "spoofed", ARP messages to an Ethernet LAN. Generally, the aim is to associate the attacker's MAC address with the IP address of another node (such as the default gateway). Any traffic meant for that IP address would be mistakenly sent to the attacker instead. The attacker could then choose to forward the traffic to the actual default gateway (passive sniffing) or modify the data before forwarding it (man-in-the-middle attack). The attacker could also launch a denial-of-service attack against a victim by associating a nonexistent MAC address to the IP address of the victim's default gateway.
ARP spoofing attacks can be run from a compromised host, a jack box, or a hacker's machine that is connected directly onto the target Ethernet segment.
"...or a backup 7200 with shut interfaces." i should add :-P
Here is the complete story...
Some months ago a fellow engineer had to replace a 7200/G1 with a 7200/G2. He had prepared the 7200/G2 with the same configuration as the 7200/G1, shut all the interfaces and made sure that the new ethernet/optical cables were working ok.
Both the 7200s were connected to a 6500 switch. 7200/G1 was the production router, 7200/G2 was the backup router to be put in production during a maintenance window in 2 days. One day later, we had a power failure on the 7200/G2 which caused the router to reload. Nothing to worry, since its power supplies were connected to a test facility and during the maintenance window they would be moved to the normal facilities. But here comes the fun part that came up during the reload:
Sep 24 13:29:12: %LINK-3-UPDOWN: Interface GigabitEthernet3/21, changed state to up
Sep 24 13:29:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/21,
changed state to up
Sep 24 13:29:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/21,
changed state to down
Sep 24 13:29:14: %LINK-3-UPDOWN: Interface GigabitEthernet3/21, changed state to down
Sep 24 13:29:12: %IP-4-DUPADDR: Duplicate address x.x.x.x on GigabitEthernet0/1,
sourced by xxxx.xxxx.xxxx
During the reload, the ethernet interfaces of the 7200/G2 (which were shut in the configuration) moved to the up state for some seconds. And during those seconds, the ip functionality of them was activated! So we had 2 identical ip addresses on the same LAN, sending similar arp messages. This is more than enough to cause havoc in the production router (something that happened in our case), until arp-cache times out or arp-table is updated/cleared.
For everyone interested, the bug opened is CSCsv69222 and it's still being investigated by the developers, who think that it's a very corner case and fixing it might break something else.
It applies to 7200s with either NPE-G1 or NPE-G2 using a Marvell ethernet controller, under these conditions:
GBIC & no autonegotiation (enabled through "no negotiation auto")
RJ-45 & autonegotiation (enabled through "speed/duplex auto")
RJ-45 & no autonegotiation (enabled through "speed/duplex 1000/full")
In the case of
it doesn't seem to apply.
GBIC & autonegotiation (enabled through "negotiation auto")
What worries me most is the fact that a part of the configuration ("ip address") seems to be activated before everything else, even the shut command. Or even better, according to Cisco's answer, the shut command is ignored :
resolution to this problem is having "no ip addr" or to change the IP address statement in the configuration, since this is common to all interfaces and the problem is due to the IOS init code implementation. The actual implementation is that we should have some different "ip addr" related statement in the configuration. Otherwise during reload time, it will consider them as new interface, so to put them in shutdown mode we have to include the "no ip addr".
shut + ip addr => no shut + ip addr
shut + no ip addr => shut + no ip addr
Surely there are quite a few of workarounds that can be implemented (shut the 6500 ports instead, remove portfast from switch, enable carrier-delay on 7200, etc), but why should i prefer a workaround instead of a bug fix?