10-29-2008 01:09 AM - edited 03-06-2019 02:11 AM
Greetings,
I have a 1801 router connected to a 3550 switch with a regular 802.1q trunk, and I am curious as to what may be causing the unknown protocol drops on the connected router interface.
The switch is without any configuration at all except the following for the trunk configuration on the interface connecting to the router.
Switch:
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
Router:
Interface FastEthernet8
switchport mode trunk
There is nothing connected to the switch other than the router so the dropped traffic must be originating from the switch itself.
The unknown protocol drop counter on the router increments by one every 30 seconds, and I tried using a packet sniffer but nothing noticeble showed up.
I read elsewhere on these forums that it might be udld, but that is not enabled by default, and just to be sure I tried disabling it on the interface and as expected it said it was not enabled, so I am ruling that one out.
I also read that it could be because the router is recieving traffic from other protocols than IP, but I do not see how it applies in this case.
IOS versions:
3550: 12.2(44)SE3
1801: 12.4(15)xy3
So in short, what does a 3550 send every 30 seconds that my 1801 does not understand?
Could it have something to do with STP?
Any help solving this little mystery will be much appreciated.
Regards,
Sannie
Solved! Go to Solution.
10-30-2008 07:28 AM
Thank you both for the suggestions, but it seems I have found the source of the unknown protocol drops.
It turned out to be DTP which is enabled by default on the switch interfaces and the router apparently doesn't understand dtp.
When I added the
10-29-2008 07:32 AM
Can you 'debug' or 'debug all' on the router? How about disabling STP or changing the STP protocol?
Thanks.
11-27-2024 04:53 AM
For all potential victims: NEVER issue "debug all" on a Cisco device. This is the easiest way to crash a Cisco. There are many more detailed debug flags to troubleshoot issues, but "all" is basically suicide. I don't know why this command even exists.
11-27-2024 07:25 AM
"For all potential victims: NEVER issue "debug all" on a Cisco device. This is the easiest way to crash a Cisco. There are many more detailed debug flags to troubleshoot issues, but "all" is basically suicide. I don't know why this command even exists."
I wouldn't say "never", but certainly "debug all" shouldn't be used without full appreciation of the potential impact. That said, certainly that command poses an operational risk on most production devices outside of scheduled maintenance, but it can be useful debugging during scheduled maintenance or in a lab, such as when you're unsure of what debug monitoring you should be using (or in a teaching situation).
Since that option has such potential impact, rather than arguing the option shouldn't exist at all, possibly it would be nice if you use that option, the system asks for confirmation. But, some broad category debug options can be pretty impactful too. So, it can be difficult to determine where to draw the line on debugging options, unless you confirm all of them. And if we're going to confirm command usage, there are many others than can be quite impactful if misused.
Fortunately, Cisco often supports a multi level command authorization, so if you want, you should be able to lock down usage of this command.
10-29-2008 09:54 AM
Try setting your speed and duplex manually on both sides of the link to see if that helps.
--John
10-30-2008 07:28 AM
Thank you both for the suggestions, but it seems I have found the source of the unknown protocol drops.
It turned out to be DTP which is enabled by default on the switch interfaces and the router apparently doesn't understand dtp.
When I added the
11-01-2008 06:46 AM
Hello Sannie,
>> It turned out to be DTP which is enabled by default on the switch interfaces and the router apparently doesn't understand dtp
Routers don't use DTP : they use Vlan subinterfaces if they are configured for doing so or not.
Other protocol routers don't use is VTP.
Hope to help
Giuseppe
09-07-2012 12:08 AM
Hi Sannie,
Me too faced the same problem....... disabled the DTP on switch end by "switchport nonegotiate" command on interface level. Now no more protocol errors on the router end.
03-13-2013 08:31 AM
Please see below explaination on this issue.
The IP Options Selective Drop feat
ure enables you to protect your network routers in the event of a
denial of service (DoS) attack. Hackers who initi
ate such attacks commonly send large streams of
packets with IP options. By dropping the packets with IP options, you can reduce the load of IP options
packets on the router. The end result is a reduction in
the effects of the DoS atta
ck on the router and on
downstream routers.
Internet service providers (ISPs) a
nd other Cisco customers face increas
ing DoS attacks associated with
IP options set in the IP header. Ci
sco IOS routers are susceptible to
DoS attacks because of the way in
which the routers process IP options. The hardwa
re-based forwarding engine of Cisco IOS routers
cannot handle IP options; therefore, the forwarding engine forwards the IP options packets to the route
processor (RP). Similarly, most of the line cards forward IP option packets to the RP. The software-based
RP processes the packets and performs the extra pr
ocessing that the IP options packets require.
Processing IP options packets in the RP can become problematic. Software-switching of IP options
packets can lead to a serious security problem if a Ci
sco IOS router comes under a DoS attack by a hacker
sending large streams of packets with IP options. The RP can easily become overloaded and drop high
priority or routing protocol packets. Switching packets in software slows down the switching speed of
the router and increases the router’s vulnerability to resource saturation. Some types of IP options, such
as the Router Alert option, can be especially ha
rmful to the router when forwarded to the RP.
By default, Cisco IOS software processes packet
s with IP options, as required by RFC 1812,
Requirements for IP Version 4 Routers
. The IP Options Selective Drop
feature provides the ability to
drop packets with IP options in the forwarding engine so
that they are not forwarded to the RP. This result
in a minimized load on the RP and
reduced RP processing requirements.
26-2
Cisco 10000 Series Router Software Configuration Guide
OL-2226-23
Chapter 26 Protecting
the Router from DoS Attacks
Restrictions for IP Options Selective Drop
Feature History for IP Options Selective Drop
Restrictions for IP Options Selective Drop
Resource Reservation Protocol (RSVP), Multiprotocol Label Switching-Traffic Engineering
(MPLS-TE), Internet Group Management Protocol Version 2 (IGMPV2), and other protocols that use IP
options packets may not function in drop mode if this feature is configured.
How to Configure IP Options Selective Drop
You can configure the router to drop all the inbound IPv4 packets with IP options or all the RP-forwarded
IP options packets.
To configure IP Options Selective Drop and protect
the RP during a DoS att
ack, perform the following
configuration tasks:
•
Dropping Packets with IP Options, page 26-2
•
Verifying IP Options Packets, page 26-3
Dropping Packets with IP Options
Use the following procedure to configure the forwarding engine to drop packets with IP options before
sending them to the RP.
SUMMARY STEPS
1.
enable
2.
configure
terminal
3.
ip options
drop
Cisco IOS Release Description
12.0(23)S This featur
e was introduced.
12.2(2)T This feature was integrated
in Cisco IOS Release 12.2(2)T.
12.2(25)S This feature was integrated
in Cisco IOS Release 12.2(25)S.
12.2(27)SBC This feature was integrated
in Cisco IOS Release 12.2(27)SBC.
12.3(19) This feature was integrated
in Cisco IOS Release 12.3(19).
12.2(31)SB2 This feature was integrated
in Cisco IOS Release 12.2(31)SB2 and
introduced on the Cisco 10000 series router for the PRE2 and PRE3.
26-3
Cisco 10000 Series Router Software Configuration Guide
OL-2226-23
Chapter 26 Protecting the Router from DoS Attacks
Configuration Examples for IP Options Selective Drop
DETAILED STEPS
Verifying IP Options Packets
Use the
show ip traffic
command to verify that the router drops all the packets received with IP options.
Configuration Examples for
IP Options Selective Drop
This section provides the following configuration examples:
•
Dropping IP Options Packets: Example, page 26-3
•
Verifying IP Options Handling: Example, page 26-4
Dropping IP Options Packets: Example
The following sample configuration shows how to configure the router (and downstream routers) to drop
all the packets with IP options that enter the network:
Router(config)#
ip options drop
% Warning:RSVP and other protocols that use IP Options packets may not function in drop or
ignore modes.
end
Command or Action Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Step 2
configure
terminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
ip options
drop
Example:
Router(config)# ip options drop
Turns IP options processing off. The router drops all the
packets received with IP options.
Note
To resume normal options processing, use the
no
form of the command:
no ip options
.
26-4
Cisco 10000 Series Router Software Configuration Guide
OL-2226-23
Chapter 26 Protecting
the Router from DoS Attacks
Related Documentation
Verifying IP Options Handling: Example
The following sample output from the
show ip traffic
command indicates that the router received 2905
packets with IP options set. Because the
ip options drop
command is configured, the router drops all
the packets with IP options, as indi
cated by the options denied counter.
Router#
show ip traffic
IP statistics:
Rcvd: 2905 total, 13 local destination
0 format errors, 0 checksum errors, 0 bad hop count
0 unknown protocol, 1 not a gateway
0 security failures, 0 bad options, 0 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 couldn't fragment
Bcast: 12 received, 3 sent
Mcast: 0 received, 0 sent
Sent: 3 generated, 0 forwarded
Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
0 no route, 0 unicast RPF, 0 forced drop, 0 unsupported-addr
3000 options denied, 0 source IP address zero
Related Documentation
This section provides additional Cisco documentation for the features discussed in this chapter. To
display the documentation, click the document title or
a section of the document highlighted in blue.
When appropriate, paths to applicable sectio
ns are listed below the documentation title.
02-20-2020 01:17 PM
I have same issue but only on interfaces connected to Cisco 7965 IP phone. I have turned on nonegotiate. Its a 9300 Switch with 16.08.01a
7965 phone
App Load ID | P0030801SR02 | |
Boot Load ID | PC0303010100 | |
Version | 8.1(SR.2) | |
DSP | 4.0(5.0)[A0] | |
Expansion Module 1 | ||
Expansion Module 2 | ||
Hardware Revision | 4.3 |
No errors on uplink interface to router?
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