Solved: CGR router with Cellular Interface

Daniel Smith · ‎04-03-2013

We have been deploying dmvpn tunnels and vrf's to separate data on CGR equipped sites. We recently deployed a cellular capable CGR with the same tunnels, but found that it would not pass traffic on either of two tunnels. Using an acl to see if anything was leaving the router, data began flowing. I had a permit icmp any any with log keyword applied, causing pings to be returned. Permit ip any any with log keyword had similar impact on telnet data. The acl had to applied outbound on the tunnel interfaces and had to have the log keyword for a particular data type to flow. This is the first I have seen anything like this and would appreciate hearing any comments.

David Kosich · ‎04-05-2013

Hi Daniel,

I don't know much about the forwarding path on the CGR. But for instance, if this were a switch (cat6500 or Cat4500 for example), and you were seeing the behavior you described, where traffic only flowed with an ACL w/log keyword in place, that would indicate that somthing is wrong with the forward path in hardware, a possible CEF issue. When you add the word "log" at the end of an ACL on a switch (again not sure about the GSR), it causes traffic matching that ACL to be software switched by the CPU, instead of forwarded in hardware as it normally would, without the ACL/Log. So in short, on a switch, if it works when software switched (punted to CPU b/c of 'log'), then that means you likely have some sort of hardware forwarding issue. Not an actual faulty hardware issue, but a case where the hardware was misprogrammed by software.

At the following doc if you search for "Access control entries (ACEs) that require logging, with the log keyword", you'll see that it mentions that these packetss require software/CPU switching on the 6500 -

http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml

Maybe someone else can chime in with expertise on the CGR, but it seems the forwarding path is broken, and the having the LOG at the end of the ACL is forcing it to use a different forwarding path within the router. If that's the case, I would think it's a bug, most likely with CEF. Having TAC look at it with/without the ACL in place would be your best bet, since they will have someone specialized in the CGR to help.

View solution in original post

David Kosich · ‎04-05-2013

Hi Daniel,

I don't know much about the forwarding path on the CGR. But for instance, if this were a switch (cat6500 or Cat4500 for example), and you were seeing the behavior you described, where traffic only flowed with an ACL w/log keyword in place, that would indicate that somthing is wrong with the forward path in hardware, a possible CEF issue. When you add the word "log" at the end of an ACL on a switch (again not sure about the GSR), it causes traffic matching that ACL to be software switched by the CPU, instead of forwarded in hardware as it normally would, without the ACL/Log. So in short, on a switch, if it works when software switched (punted to CPU b/c of 'log'), then that means you likely have some sort of hardware forwarding issue. Not an actual faulty hardware issue, but a case where the hardware was misprogrammed by software.

At the following doc if you search for "Access control entries (ACEs) that require logging, with the log keyword", you'll see that it mentions that these packetss require software/CPU switching on the 6500 -

http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml

Maybe someone else can chime in with expertise on the CGR, but it seems the forwarding path is broken, and the having the LOG at the end of the ACL is forcing it to use a different forwarding path within the router. If that's the case, I would think it's a bug, most likely with CEF. Having TAC look at it with/without the ACL in place would be your best bet, since they will have someone specialized in the CGR to help.