cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6325
Views
5
Helpful
2
Replies

Nexus 7000: hardware verify ip

mullzkBern_2
Level 1
Level 1

Hi everybody
Last week we encountered a serious problem with our Nexus 7000-environment. Some 3rd-party Service-Provider had their IP-Packets fragmented although the Don't Fragment Bit was set. When our N7K began to silently drop these packets silently, troubleshooting was very hard, until we found out about the "Hardware IP Verify Fragment"-Feature.

To prevent further problems of this kind, we decided disable not only the Fragment-Verification, but all the others hardware ip-tests as well: In our network we have the policy, that we do not manipulate nor even drop traffic if there is no need to do so. Before we do so, we just wanted to ask three things:
- Is there any configuration on the Nexus (NX-OS 4.2(2a)) for not dropping any packets silently? The fragment-verification-thing would not have been as bad as it was, if the N7K had warned us about violated IP-Standards or anything like this. Without any notification we had to find out about the fragmentation, find out about the hardware ip verify-feature AND switch to the default-vdc as the hardware-verify-settings- and -counters can only be seen from this vdc.
- Are there any other filters on the Nexus enabled per Default which alter the traffic-forwarding compared to the behavior of the cat6500-Platform? (e.g. some "software ip verify"?)
- If we disable all the Verifications below, do we shoot ourselves into the foot? Are any of those tests vital for a stable network, or are they all just some "nice to filter out to save on our ressources and provide a little bit more security"-filters?

Thanks a lot in advance & greetings from Berne
Mullzk


n91003# sh hardware forwarding ip verify

IPv4 and v6 IDS Checks         Status     Packets Failed
-----------------------------+---------+------------------
address source broadcast       Enabled    0             
address source multicast       Enabled    0             
address destination zero       Enabled    234665        
address identical              Enabled    419           
address reserved               Enabled    116           
address class-e                Disabled   --
checksum                       Enabled    0             
protocol                       Enabled    0             
fragment                       Disabled   --
length minimum                 Enabled    0             
length consistent              Enabled    0             
length maximum max-frag        Enabled    0             
length maximum udp             Disabled   --
length maximum max-tcp         Enabled    0             
tcp flags                      Disabled   --
tcp tiny-frag                  Enabled    0             
version                        Enabled    0             
-----------------------------+---------+------------------
IPv6 IDS Checks                Status     Packets Failed
-----------------------------+---------+------------------
length consistent              Enabled    0             
length maximum max-frag        Enabled    0             
length maximum udp             Disabled   --
length maximum max-tcp         Enabled    0             
tcp tiny-frag                  Enabled    0             
version                        Enabled    0             
n91003#

1 Accepted Solution

Accepted Solutions

Chad Peterson
Cisco Employee
Cisco Employee

The issue you saw has been pretty common.  In 5.0(2) and I think 4.2(6) (please correct me if I am wrong), we will now log when we drop packets due to these checks.

Typically if you are loosing some traffic, check interface counters as you usually would.  Check 'show hardware forwarding verfiy ip' as you did.  Check CoPP 'show policy-map interface control-plane', and check hardware rate-limiters 'show hardware rate-limit'.

Typically something here will show you want you are looking for.

As far as disabling the checks, you are not shooting yourself in the foot.  Any invalid traffic will still get dropped at the end device.

View solution in original post

2 Replies 2

We just ran into the same issue. We have a piece of carrier voice gear that is setting both DF and MF. We had spent hours troubleshooting WAN transport possibilities and found it to be w/in the data center on the N7K.

I completely agree with you; there should be some log or notification when packets get filtered against a default-on feature such as this.

-chris

Chad Peterson
Cisco Employee
Cisco Employee

The issue you saw has been pretty common.  In 5.0(2) and I think 4.2(6) (please correct me if I am wrong), we will now log when we drop packets due to these checks.

Typically if you are loosing some traffic, check interface counters as you usually would.  Check 'show hardware forwarding verfiy ip' as you did.  Check CoPP 'show policy-map interface control-plane', and check hardware rate-limiters 'show hardware rate-limit'.

Typically something here will show you want you are looking for.

As far as disabling the checks, you are not shooting yourself in the foot.  Any invalid traffic will still get dropped at the end device.

Review Cisco Networking for a $25 gift card