Crypto 4 recvdpktnotipsec


VRF-conscious VPN IPSEC – %CRYPTO-four-RECVD_PKT_NOT_IPSEC: Rec’d packet no longer an IPSEC packet.

I have the subsequent scenario:

MP-BGP – MPLS:      PE31 PE30

IPSEC Tunnel:          PE30 CE35

The community is operating excellent for the choices MPLS part, also I can ping the choices CE35 from PE30 via the VPN IPSEC and so encapsulating the traffic matching the crypto-map…

Here is the choices encryption domain:

PE30: ip get admission to-list prolonged into_VPNpermit ip host 200.200.two hundred.200 host a hundred.one hundred.a hundred.100permit ip host 201.201.201.201 host 100.a hundred.a hundred.a hundred

CE35:get admission to-listing 199 permit ip host one hundred.one hundred.a hundred.one hundred host 200.2 hundred.200.200access-listing 199 permit ip host one hundred.a hundred.100.a hundred host 201.201.201.201

The first supply (PE31 two hundred.200.2 hundred.two hundred/32 it is operating fine):

R30#ping vrf custa 100.a hundred.100.a hundred so lo10 Type get away series to abort.Sending 5, a hundred-byte ICMP Echos to a hundred.a hundred.a hundred.100, timeout is two seconds:Packet sent with a source address of two hundred.200.2 hundred.two hundred !!!!!Success charge is a hundred percentage (five/five), spherical-trip min/avg/max = five/5/6 msR30#sh crypto ipsec sainterface: Ethernet0/1Crypto map tag: mymap, neighborhood addr 1.1.1.1protected vrf: custalocal ident (addr/mask/prot/port): (two hundred.200.2 hundred.200/255.255.255.255/256/0)far flung ident (addr/mask/prot/port): (a hundred.100.one hundred.a hundred/255.255.255.255/256/0)current_peer 1.1.1.2 port 500PERMIT, flags=#pkts encaps: 23, #pkts encrypt: 23, #pkts digest: 23#pkts decaps: 23, #pkts decrypt: 23, #pkts affirm: 23#pkts compressed: zero, #pkts decompressed: zero#pkts now not compressed: 0, #pkts compr. failed: 0#pkts no longer decompressed: 0, #pkts decompress failed: zero#ship mistakes 0, #recv mistakes 0local crypto endpt.: 1.1.1.1, far off crypto endpt.: 1.1.1.2path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/1current outbound spi: 0x3AFB0987(989530503)PFS (Y/N): N, DH organization: none

inbound esp sas:spi: 0xE2974B16(3801565974)remodel: esp-3des esp-sha-hmac ,in use settings =conn identity: 5, flow_id: SW:five, sibling_flags 80000040, crypto map: mymapsa timing: final key lifetime (okay/sec): (4171502/2062)IV length: 8 bytesreplay detection assist: YStatus: ACTIVE(ACTIVE)inbound ah sas:inbound pcp sas:outbound esp sas:spi: 0x3AFB0987(989530503)rework: esp-3des esp-sha-hmac ,in use settings =conn id: 6, flow_id: SW:6, sibling_flags 80000040, crypto map: mymapsa timing: ultimate key lifetime (okay/sec): (4171502/2062)IV size: 8 bytesreplay detection assist: YStatus: ACTIVE(ACTIVE)outbound ah sas:

Unfortunately I’ve positioned two sources in the crypto-map, the latter is a loopback on PE31 (201.201.201.201/32) that I can see within the received routes via IBGP through the MPLS cloud:

R30#sh ip bgp vpnv4 vrf custa 201.201.201.201 BGP routing table access for 1:1:201.201.201.201/32, model 15Paths: (1 available, nice #1, table custa)Not advertised to any peerRefresh Epoch 1Local31.31.31.31 (metric eleven) from 31.31.31.31 (31.31.31.31)Origin incomplete, metric zero, localpref 100, legitimate, inner, bestExtended Community: RT:a hundred:100mpls labels in/out nolabel/20

Unfortunately the choices ping sourced from PE31 isn’t going to be encapsulated.. looks as if isn’t matching the acl on PE30, and I can not recognize why:

output ping source (PE31):

R31#ping vrf custa one hundred.one hundred.one hundred.a hundred so lo10Type break out collection to abort.Sending 5, one hundred-byte ICMP Echos to 100.100.100.100, timeout is two seconds:Packet sent with a source cope with of 201.201.201.201 …..Success price is 0 percentage (0/5)

%CRYPTO-four-RECVD_PKT_NOT_IPSEC: Rec’d packet not an IPSEC packet. (ip) vrf/dest_addr= /100.100.a hundred.100, src_addr= 201.201.201.201, prot= 1

So now, a person could provide me an assist?Actually I suppose it should be a hassle related to the MPLS encapsulataion etc.. any ideas??

You can discover all the configuration connected together with a network scheme.

Solved! Go to Solution.

simply figured the choices hassle. Since there is no route-leaking idea between vrf’s the usage of static routes, it was no longer operating however seeing that you have opposite route, it creates an in-reminiscence static path which acts as path-leaking in this situation.

So, to solve this trouble together with your older configuration of vrf’s, you can configure “redistribute static” on router PE30 under vrf custa address-circle of relatives.

Once you configure it, you may see that PE30 is marketing a hundred.100.a hundred.100/32 prefix to PE 31.

This will clear up your hassle.

View answer in unique submit

Are pings running from [email protected] to [email protected](R35) in handiest one vrf in the simpliest case? I suggest that:

 – with out IPSec between R30 and R35

 – without route-leaking among vrf “custa” and vrf “internet” on R30 and R31.

For example let it be simplest  vrf ‘custa’, in order that:

[email protected] [vrf custa]  –> MP-BGP –> [vrf custa]@R30 –>[email protected]

If it’s going to paintings, add IPSec once more between R30 and R35 and try to ping and appears on debug on R30:

I have tweeked your configuration a piece and this works perfectly satisfactory.

Please permit me recognise when you have any questions.

PS: Please mark the choices query as responded if your problem is resolved.

From your config CE-confronted interface now not in vrf, so IPSec on R30 isn’t always VRF-conscious.

But is it income or poor –  relies upon from favored goal scheme. If Gi0/[email protected] (CE-faced interface with crypto-map) actually need to look closer to Internet (in fact it’s miles interface on our PE towards ISP), in order that  IPSec tunnel mounted  via Internet towards some customer device, I would say that is profit, because hold complete net desk in vrf in ISP-faced-PE (R30 inside the case) – feasible, however not excellent, as to me, and your tweek seems very fashionable.

In maximum cases, if you are having an ISP, you dont truly must make it as a part of VRF. with MPLS VPN, you could still have a VRF however VRF Aware IPSec on top to MPLS VPN reasons some greater overheads. Secondly, with the older technique, you have been uploading the choices RT in custa vrf, in an effort to growth the overhead on that VRF as well. 

Please let me recognise if you have any in addition questions.

PS: Please mark the query as answered in case your query has been resolved.

I believe you selection in any respect.

I just stated that in end result it isn’t always vrf-conscious ipsec, which the choices subject matter starter would like to check.

But let’s ready the choices subject matter starter answer.

Let me perform a little greater studies on it and get lower back to you. 

simply figured the problem. Since there’s no course-leaking concept among vrf’s using static routes, it become no longer operating but when you consider that you’ve got reverse route, it creates an in-memory static course which acts as course-leaking in this example.

So, to remedy this hassle together with your older configuration of vrf’s, you could configure “redistribute static” on router PE30 under vrf custa address-family.

Once you configure it, you will see that PE30 is advertising and marketing 100.one hundred.one hundred.a hundred/32 prefix to PE 31.

This will solve your hassle.

View answer in original post

Thank you for explananations.

Topic starter – Loris, not me)

I’m just seeking to assist and understand which target Loris desired to attain)

Anyway, thanks once more and permit’s wait what Loris says.

Please allow me realize if you have any further queries associated with this. I will also try to document it in a support community report so that it is beneficial for others as nicely.

PS: Please do fee beneficial posts

Hi Vinit,thank you for the total rationalization about the choices supplied answer, it worked perfectly certainly.Actually I would love to present you one more query, what is the choices cause why I wasn’t able to get encapsulated the traffic coming from the choices far flung-PE31 even supposing I changed into meshing the vrf through the import among every different? I imply, why the choices default-direction wasn’t enough to attain the choices destination… or higher I became accomplishing the vacation spot, but the visitors from PE31 was no longer being encapsulated?

So it’s the exact 100.one hundred.100.a hundred/32 necessary to ahead the choices visitors in the course of the tunnel?I realize the choices PE30 has the choices static route to a hundred.one hundred.100.100/32  generated with the aid of the reverse-course, but really I although the choices default on the PE31 changed into sufficient… Just to lab againg extensive I’ve  additionally tried to add the choices “redistribute static” and deleting the default direction, and the choices 100.one hundred.one hundred.one hundred/32 has disappeared from the choices bgp routing desk on the choices faraway PE31, why turned into it?Many thanks for you guide,Best RegardsL.

Regarding the choices one hundred.one hundred.a hundred.100/32 being disappearing, you will must first carry out the ping from PE30

Check out the choices record that i wrote few hours back:

https://supportforums.cisco.com/file/12714611/static-ipsec-mpls-vpn

The prefix will no longer be marketed till the ping is not done from PE30. I may nevertheless need to perform a little extra studies on the choices equal.