cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
473
Views
0
Helpful
4
Replies

Debug conditions not producing the desired output

Mitrixsen
Level 1
Level 1

Hello, everyone!

I am studying debugging for my ENCOR exam which also includes conditional debugs. For some reason, the only condition that I could get to actually work was the one related to an interface, none of the available conditions really work. Take a look at this:

 

R1#debug ip packet
IP packet debugging is on

*Mar  8 11:11:37.075: IP: s=192.168.1.10 (GigabitEthernet0/2), d=192.168.1.1
*Mar  8 11:11:37.075: IP: tableid=0, s=192.168.1.10 (GigabitEthernet0/2), d=192.168.1.1 (GigabitEthernet0/2), routed via RIB

 

I've made the debug output shorter so it's easier to read. Now, you can see that R1 is receiving a packet from 192.168.1.10, this is all just a simple ping. Now, if I create a condition like this:

 

R1#debug condition ip 192.168.1.10
Condition 1 set

R1#show debug
Generic IP:
  IP packet debugging is on

Condition 1: ip 192.168.1.10 (0 flags triggered)

 

The device isn't producing any debug output, despite the IP address matching the device who was pinging R1 before. The interface condition works.

 

R1#debug condition interface G0/2
Condition 2 set

*Mar  8 11:18:35.512: IP: s=192.168.1.10 (GigabitEthernet0/2), d=192.168.1.1
*Mar  8 11:18:35.512: IP: tableid=0, s=192.168.1.10 (GigabitEthernet0/2), d=192.168.1.1 (GigabitEthernet0/2), routed via RIB

 

 Does anyone know what's happening here?

Thank you.

David

2 Accepted Solutions

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame

"Does anyone know what's happening here?"

I don't, but sometimes Cisco devices functions don't adhere to exactly the same processing rules between transit traffic and non-transit traffic.

View solution in original post

M02@rt37
VIP
VIP

Hello @Mitrixsen 

Your IP condition is not working because IOS only applies it to routed packets, not locally generated ones. CEF might also be interfering—try "no ip cef" and see if it helps. The interface condition works because it applies at a lower level. You can also use an acl with "debug ip packet 100 detail" to filter packets more effectively.

So, why no ip cef ? When CEF is enabled, some packets might not trigger debug output unless they are punted to the CPU. If you disable cef, all packets go throught process switching, making them visible to the debug command. Better to do that in lab environnement...

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

View solution in original post

4 Replies 4

Joseph W. Doherty
Hall of Fame
Hall of Fame

"Does anyone know what's happening here?"

I don't, but sometimes Cisco devices functions don't adhere to exactly the same processing rules between transit traffic and non-transit traffic.

M02@rt37
VIP
VIP

Hello @Mitrixsen 

Your IP condition is not working because IOS only applies it to routed packets, not locally generated ones. CEF might also be interfering—try "no ip cef" and see if it helps. The interface condition works because it applies at a lower level. You can also use an acl with "debug ip packet 100 detail" to filter packets more effectively.

So, why no ip cef ? When CEF is enabled, some packets might not trigger debug output unless they are punted to the CPU. If you disable cef, all packets go throught process switching, making them visible to the debug command. Better to do that in lab environnement...

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

"When CEF is enabled, some packets might not trigger debug output unless they are punted to the CPU."

As a side note, but not really germane to OP, different platforms and/or IOS versions, even on the same platform, processing paths vary.  Both "process switching" and/or "punted to the CPU" imply taking a less optimal, and slower, forwarding logic path, but, again, depending on platform and its IOS, CPU, and other acceleration hardware, might be used regardless of forwarding logic path.  Also, CEF is, generally, mostly superior for first seen packet to a destination network.

In other words, forwarding is complicated and actual mechanics may vary by platform/IOS, and although CEF is almost always a "good thing" as is "punting" a packet is almost always a "bad thing", why that is (or isn't), and to what degree, is very variable.

The only reason I even mention this, is because on software based routers, without any additional acceleration hardware, packet forwarding is done by the same CPU regardless whether fast/interrupt past vs. process switching path but the processing time for the two paths, for the same result, can, also again, vary considerably, and often do.

Lastly, I recall (?) bumping into some situations where device would not allow CEF to be disabled.  I also recall (?), on some devices, if CEF disabled, some other features are also disabled.  (I don't know reasons for either, but it sort of reminds when a later generation of Windows was released that "required" Internet Explorer.)

"If you disable cef, all packets go throught process switching, . ."

BTW, don't believe disabling CEF always necessitates process switching (once upon a time, I recall it didn't).  Interrupt/fast path, possibly with cacheing options, might be available on the platform.  Although, much may depend on actual platform/IOS.