Wired Intelligent Edge

Hello,

I want to follow this thread because I have noticed same "issue" with fw 10.13 and 10.15 in cores routing L3 (8360) and edges (6300M/F which has usually only management SVI) 

These drops seems to not affect any data streams running in network so I would also like to know what are these "drops" anyway.

Yesterday, I opened a TAC Case on this. I will provide updates here.

Any updates?

Yesterday, I opened a TAC Case on this. I will provide updates here.

I´m still in contact with TAC. The first level support-engineer couldn´t find the cause, therfore the case is escalated to the next level support-engineer. 

As soon as I get any specific infos I will give an update here. 

My I ask if you see something similar in your infrastructure?

Any updates?

Yesterday, I opened a TAC Case on this. I will provide updates here.

Yes, I'm seeing this issue.  High number of copp drops due to ip-exceptions.  The only out-of-the-ordinary factor is that we're seeing this in vlans with IDs above 4000.

I´m still in contact with TAC. The first level support-engineer couldn´t find the cause, therfore the case is escalated to the next level support-engineer. 

As soon as I get any specific infos I will give an update here. 

My I ask if you see something similar in your infrastructure?

Any updates?

Yesterday, I opened a TAC Case on this. I will provide updates here.

Hello,

I want to follow this thread because I have noticed same "issue" with fw 10.13 and 10.15 in cores routing L3 (8360) and edges (6300M/F which has usually only management SVI) 

These drops seems to not affect any data streams running in network so I would also like to know what are these "drops" anyway.

Those alerts recently appeard for one of my deployement. And while the switch had no SVI working.  I wonder if it's an alert flagged because of a specific firmware. It's my only site using FW 10.16.1020

No other sites use that firmware and flags this alert. 

Yes, I'm seeing this issue.  High number of copp drops due to ip-exceptions.  The only out-of-the-ordinary factor is that we're seeing this in vlans with IDs above 4000.

I´m still in contact with TAC. The first level support-engineer couldn´t find the cause, therfore the case is escalated to the next level support-engineer. 

As soon as I get any specific infos I will give an update here. 

My I ask if you see something similar in your infrastructure?

Any updates?

Yesterday, I opened a TAC Case on this. I will provide updates here.

Hello,

At the moment I have sites running 10.13.1070 and 10.15.1030 fw's and both reports excessive ip-exception drops so problem seems to be in multiple firmwares.

One common thing between my sites are media streams (Dante/Ravenna/NDI/etc..) and there is quite a lot of multicast there.
I haven't have real problems which would be visible in media streams but I tuned up "class igmp" to not have that much "drops" there in igmp class.

I would like to know how can I monitor which packets copp process reports to drop and should it affect to L2 traffic between ports or does copp just protect cpu and passes traffic  as-is?

Those alerts recently appeard for one of my deployement. And while the switch had no SVI working.  I wonder if it's an alert flagged because of a specific firmware. It's my only site using FW 10.16.1020

No other sites use that firmware and flags this alert. 

Yes, I'm seeing this issue.  High number of copp drops due to ip-exceptions.  The only out-of-the-ordinary factor is that we're seeing this in vlans with IDs above 4000.

I´m still in contact with TAC. The first level support-engineer couldn´t find the cause, therfore the case is escalated to the next level support-engineer. 

As soon as I get any specific infos I will give an update here. 

My I ask if you see something similar in your infrastructure?

Any updates?

Yesterday, I opened a TAC Case on this. I will provide updates here.

Hello,

I want to follow this thread because I have noticed same "issue" with fw 10.13 and 10.15 in cores routing L3 (8360) and edges (6300M/F which has usually only management SVI) 

These drops seems to not affect any data streams running in network so I would also like to know what are these "drops" anyway.

Hello,

I want to share the status of this issue.
Yesterday I had a remote sesseion with TAC-Engineer and we did some deeper troubleshooting and packet capture on shell of the switch.
The Engineer assisted in tacking packet captures that only include packets that are hitting the copp class ip-exceptions so we are able to find the source of the packets.
It turned out that packets arriving with TTL=1. All of them were some kind of multicast packets coming from our AMX/NDI/Dante Devices. We also saw a few packets coming from Wifi-devices in our Guest Wifi which are using mDNS.

The point is: although the packets are counted as "dropped" in the copp statistics (because they have TTL of 1) the packets are actually NOT dropped. This explains why we don´t have any issues regarding performance.
I mentioned to the TAC-Engineer, that this behavior (packets are statistically reported as dropped although there are NOT dropped) is not what I would expect and if it is possible to open some kind of bug-report that this is corrected in future releases. He told me, that this already happend and was reviewed but it was considered as designed and changes will not be possible at this stage.

The clue for me is: although the copp statistics show dropped packets there are actually NO packets dropped. I will keep that in mind if I come accross a similiar behavior (maybe in another copp class).

Alex

Hello,

At the moment I have sites running 10.13.1070 and 10.15.1030 fw's and both reports excessive ip-exception drops so problem seems to be in multiple firmwares.

One common thing between my sites are media streams (Dante/Ravenna/NDI/etc..) and there is quite a lot of multicast there.
I haven't have real problems which would be visible in media streams but I tuned up "class igmp" to not have that much "drops" there in igmp class.

I would like to know how can I monitor which packets copp process reports to drop and should it affect to L2 traffic between ports or does copp just protect cpu and passes traffic  as-is?

Those alerts recently appeard for one of my deployement. And while the switch had no SVI working.  I wonder if it's an alert flagged because of a specific firmware. It's my only site using FW 10.16.1020

No other sites use that firmware and flags this alert. 

Yes, I'm seeing this issue.  High number of copp drops due to ip-exceptions.  The only out-of-the-ordinary factor is that we're seeing this in vlans with IDs above 4000.

I´m still in contact with TAC. The first level support-engineer couldn´t find the cause, therfore the case is escalated to the next level support-engineer. 

As soon as I get any specific infos I will give an update here. 

My I ask if you see something similar in your infrastructure?

Any updates?

Yesterday, I opened a TAC Case on this. I will provide updates here.

Hello,

Kind of great news that drops are not "real drops" 👍

Usually PTPv1 and Dante discovery streams (224.0.0.230-232) are TTL=1 stuff and some of NDI devices default TTL is also 1 but while drops are in L2 devices it does not make sense that L2 device reports such packets.

Hello,

I want to share the status of this issue.
Yesterday I had a remote sesseion with TAC-Engineer and we did some deeper troubleshooting and packet capture on shell of the switch.
The Engineer assisted in tacking packet captures that only include packets that are hitting the copp class ip-exceptions so we are able to find the source of the packets.
It turned out that packets arriving with TTL=1. All of them were some kind of multicast packets coming from our AMX/NDI/Dante Devices. We also saw a few packets coming from Wifi-devices in our Guest Wifi which are using mDNS.

The point is: although the packets are counted as "dropped" in the copp statistics (because they have TTL of 1) the packets are actually NOT dropped. This explains why we don´t have any issues regarding performance.
I mentioned to the TAC-Engineer, that this behavior (packets are statistically reported as dropped although there are NOT dropped) is not what I would expect and if it is possible to open some kind of bug-report that this is corrected in future releases. He told me, that this already happend and was reviewed but it was considered as designed and changes will not be possible at this stage.

The clue for me is: although the copp statistics show dropped packets there are actually NO packets dropped. I will keep that in mind if I come accross a similiar behavior (maybe in another copp class).

Alex

Hello,

At the moment I have sites running 10.13.1070 and 10.15.1030 fw's and both reports excessive ip-exception drops so problem seems to be in multiple firmwares.

One common thing between my sites are media streams (Dante/Ravenna/NDI/etc..) and there is quite a lot of multicast there.
I haven't have real problems which would be visible in media streams but I tuned up "class igmp" to not have that much "drops" there in igmp class.

I would like to know how can I monitor which packets copp process reports to drop and should it affect to L2 traffic between ports or does copp just protect cpu and passes traffic  as-is?

Those alerts recently appeard for one of my deployement. And while the switch had no SVI working.  I wonder if it's an alert flagged because of a specific firmware. It's my only site using FW 10.16.1020

No other sites use that firmware and flags this alert. 

Yes, I'm seeing this issue.  High number of copp drops due to ip-exceptions.  The only out-of-the-ordinary factor is that we're seeing this in vlans with IDs above 4000.

I´m still in contact with TAC. The first level support-engineer couldn´t find the cause, therfore the case is escalated to the next level support-engineer. 

As soon as I get any specific infos I will give an update here. 

My I ask if you see something similar in your infrastructure?

Any updates?

Yesterday, I opened a TAC Case on this. I will provide updates here.

Hello,

I want to follow this thread because I have noticed same "issue" with fw 10.13 and 10.15 in cores routing L3 (8360) and edges (6300M/F which has usually only management SVI) 

These drops seems to not affect any data streams running in network so I would also like to know what are these "drops" anyway.