Quantcast
Channel: IEOC - INE's Online Community
Viewing all articles
Browse latest Browse all 10672

traffic through VTI broken when cef is enabled

$
0
0

this one has me scratching my head a bit. Going through the IPsec VTI Tunnel int exercise in the v5 workbook using the IPsec VPN initial config. I arrived at correct config based on the task list.

All the verifications check out per the lab doc. 

Testing reachability between R10 Lo0 and R9 Lo0 was failing. Using pings with a specific pattern(0xBADA) sourced from R9 I was able identify that with CEF enabled the traffic doesn't make it to the crypto engine and into the encrypted tunnel. This occurs even though the cry ip sa output shows the local/remote ident is 0.0.0.0/0 and the routing tables points to the tunnel interface.

This is with;

debug ip cef packet all output 1 rate 0 detail

debug ip cef packet all input 1 rate 0 detail

debug crypto engine packet detail

R7#

CEF-Debug: Packet from 150.1.9.9 (Gi0/0.79) to 150.1.10.10

  ihl=20, length=100, tos=0, ttl=254, checksum=32106, offset=0

    ICMP type=8, code=0, checksum=17743

         ECHO

CEF-Debug: Packet from 150.1.9.9 (Gi0/0.79) to 150.1.10.10 (Tu0)

  ihl=20, length=100, tos=0, ttl=254, checksum=32106, offset=0

    ICMP type=8, code=0, checksum=17743

         ECHO

R7#

This is with;

no ip cef

debug ip packet 1 detail

debug crypto engine packet detail

 

IP: s=150.1.9.9 (GigabitEthernet0/0.79), d=150.1.10.10, len 100, input feature

    ICMP type=8, code=0, MCI Check(92), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: tableid=0, s=150.1.9.9 (GigabitEthernet0/0.79), d=150.1.10.10 (Tunnel0), routed via RIB

IP: s=150.1.9.9 (GigabitEthernet0/0.79), d=150.1.10.10 (Tunnel0), len 100, output feature

    ICMP type=8, code=0, TCP Adjust MSS(54), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=150.1.9.9 (GigabitEthernet0/0.79), d=150.1.10.10 (Tunnel0), g=169.254.78.8, len 100, forward

    ICMP type=8, code=0

IP: s=150.1.9.9 (GigabitEthernet0/0.79), d=150.1.10.10 (Tunnel0), len 100, post-encap feature

    ICMP type=8, code=0, IPSEC Post-encap output classification(13), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=150.1.9.9 (GigabitEthernet0/0.79), d=150.1.10.10 (Tunnel0), len 100, sending full packet

    ICMP type=8, code=0

Before encryption:

0E003BB0:                   45000064 001B

R7#0000          E..d....

0E003BC0: FE017D68 96010909 96010A0A 0800786A  ~.}h..........xj

0E003BD0: 000C0000 00000000 007E23B4 BADABADA  .........~#4:Z:Z

0E003BE0: BADABADA BADABADA BADABADA BADABADA  :Z:Z:Z:Z:Z:Z:Z:Z

0E003BF0: BADABADA BADABADA BADABADA BADABADA  :Z:Z:Z:Z:Z:Z:Z:Z

0E003C00: BADABADA BADABADA BADABADA BADABADA  :Z:Z:Z:Z:Z:Z:Z:Z

0E003C10: BADABADA BADABADA BADABADA           :Z:Z:Z:Z:Z:Z

After encryption:

0E36AF50:                   45000098 1E010000          E.......

0E36AF60: FF326221 96010707 96010808 D482307B  .2b!........T.0{

0E36AF70: 0000004D 6A23D2CC E2E6163C 0AF0DDCB  ...Mj#RLbf.<.p]K

0E36AF80: 4362385C 6ADCD763 B125FC60 B838A429  Cb8\j\Wc1%|`88$)

0E36AF90: 3F3152DD CE996851 1016933D 1749BC61  ?1R]N.hQ...=.I<a

0E36AFA0: FA00D02F 937CEFEE 3D32113D 982B6C9B  z.P/.|on=2.=.+l.

0E36AFB0: CE9B29F3 D9B80539 6ADEED15 8FF0154A  N.)sY8.9j^m..p.J

0E36AFC0: CBFA1252 49DDCD8B 7F4D1786 1CF148D7  Kz.RI]M..M...qHW

0E36AFD0: 3B7D32E4 BF270F0D 997F94B2 656CE7A5

R7# ;}2d?'.....2elg%

0E36AFE0: 4C675355 FE91F524 5C74AEBD 4C820281  LgSU~.u$\t.=L...

0E36AFF0:

post_crypto_ip_encrypt: Data just encrypted, 152 bytes

Process switched encrypted packet

Punt packet to process switch

IP: tableid=0, s=150.1.7.7 (local), d=150.1.8.8 (GigabitEthernet0/0.67), routed via RIB

IP: s=150.1.7.7 (local), d=150.1.8.8 (GigabitEthernet0/0.67), g=155.1.67.6, len 152, forward, proto=50

IP: s=150.1.7.7 (local), d=150.1.8.8 (GigabitEthernet0/0.67), len 152, sending full packet, proto=50

IP: s=150.1.8.8 (GigabitEthernet0/0.67), d=150.1.7.7, len 136, input feature, proto=50, MCI Check(92), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=150.1.8.8 (GigabitEthernet0/0.67), d=150.1.7.7, len 136, rcvd 2, proto=50

IP: s=150.1.8.8 (GigabitEthernet0/0.67), d=150.1.7.7, len 136, stop process pak for forus packet, proto=50

IP: s=150.1.8.8 (GigabitEthernet0/0.67), d=150.1.7.7, len 136, enqueue feature, pr

R7#oto=50, TCP Adjust MSS(5), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

 

I am seeing a similar behvaior on the far end R8 router. Everything is fine as long as ip cef is disabled on R7 and R8. 

I've got to be missing something here. Hoping I'm not troubleshooting a bug in my lab. Lab is GNS3. all routers are 7206/npe400 running 15.2(4)S4. Has anyone else run through this and hit a similar issue?


Viewing all articles
Browse latest Browse all 10672

Trending Articles