cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1295
Views
0
Helpful
14
Replies

VPN and Policy routing

dosic
Level 1
Level 1

hello,

We've a router and 2 uplinks to different ISPs.

The default route is to the first ISP (ISP_A).

And the PBR is used to sends specific traffic to the second ISP (ISP_B). It works fine untill we have local VPN termination.

So it was decided to build VPN tunnel through the ISP_B to the remote site.

I can see isakmp/esp packets from the remote site but the local router sends the reply isakmp/esp to the default GW (to ISP_A).

I'd like to know why the PBR does not work for the VPN traffic?

If the static route to the remote site is added pointing to the ISP_B the tunnel is up, without the static routing (any routing except PBR to ISP_B) the solution does not work.

Any ideas?

Thanks

R(local)------default route---------ISP_A

     |

    (pbr) -----------ISP_B-------remote site

14 Replies 14

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Self-generated traffic does not adhare to PBR.

IP local policy is what you're looking for.

Why not statcally put routes to remote VPN subnets and peer via ISP B instead of playing with PBR?

Marcin

Hi,

I've used local policy, it makes sense for self-generated traffic (ping, telnet etc) and not for VPN ;((

According to some security policies static routes can not be used.

Did it work with local policy? What did you exactly put into that pool and did you change the remote peer config? (Unless you're using multihoming)

IKE (udp/500) session is definetly self generated packet, one can argue that also VPN flows (ESP/AH/UDP port 4500) encapsulations are generated by the router itself and not elsewhere.

Marcin

Hi,

>>Did it work with local policy?

No it does not work. I can not understand why it works for telnet, ping, ssh and other traffic but not for VPN.

>>IKE (udp/500) session is definetly self generated packet.

I understand this. But debug ip packets shows me that for some reason local policy does not work with udp500 or 4500 + esp. These packets are send according to FIB. (to the ISP_A).

>>What did you exactly put into that pool and did you change the remote peer config?

What do you mean? What for reason should I change remote peer config? I can receive udp/esp packets from the remote peer.

Can you share with me show tech and routing table?

If this is not a multihoming scenario, my thought that this should be enough:

- PBR for data.

- crypto map on both interfaces

- local policy specyfing that peer router is available via ISP_B

- peer router poining to ISP_B IP address for crypto.

I guess a lab test would be interesting, but for sure not on Sunday morning ;-)

Marcin

Something like this works for me on 15.1.2..

In this scneario I have two possible ISPs   via 10.3.3.0/24 and 10.4.4.0/24, my normal gateway is via 10.3.3.2 and I want my IPsec to go via 10.4.4.2.

I explicitly applied only crypto map on e1/0.

The far end is using normal routing poiting explicitly both this peer and the subnet via correct interface.

BB_966#sh run | s crypto
crypto pki token default removal timeout 0
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set TRA esp-aes esp-sha-hmac
crypto map MAP 10 ipsec-isakmp
set peer 10.2.2.1
set transform-set TRA
match address VPN
crypto map MAP
BB_966#sh run | i ip route
ip route 0.0.0.0 0.0.0.0 10.3.3.2
BB_966#sh route-map
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): VPN
  Set clauses:
    ip next-hop 10.4.4.2
  Policy routing matches: 2 packets, 228 bytes
route-map VPN_END, permit, sequence 10
  Match clauses:
    ip address (access-lists): VPN_END
  Set clauses:
    ip next-hop 10.4.4.2
  Policy routing matches: 6 packets, 976 bytes
BB_966#sh ip access-l VPN
Extended IP access list VPN
    10 permit ip 10.5.5.0 0.0.0.255 223.255.255.0 0.0.0.255 (7 matches)

BB_966# sh access-lists VPN_END
Extended IP access list VPN_END
    10 permit ip any host 10.2.2.1 (6 matches)
BB_966#sh cry ipsec sa | i ident|caps
   local  ident (addr/mask/prot/port): (10.5.5.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (223.255.255.0/255.255.255.0/0/0)
    #pkts encaps: 1, #pkts encrypt: 1, #pkts digest: 1
    #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1
BB_966#sh ip route
(...omitted...)

Gateway of last resort is 10.3.3.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.3.3.2
      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C        10.3.3.0/24 is directly connected, Ethernet0/0
L        10.3.3.1/32 is directly connected, Ethernet0/0
C        10.4.4.0/24 is directly connected, Ethernet1/0
L        10.4.4.1/32 is directly connected, Ethernet1/0
C        10.5.5.0/24 is directly connected, Ethernet2/0
L        10.5.5.1/32 is directly connected, Ethernet2/0
      223.255.255.0/32 is subnetted, 1 subnets
C        223.255.255.6 is directly connected, Loopback0
BB_966#

BB_966#sh cry map
Crypto Map "MAP" 10 ipsec-isakmp
        Peer = 10.2.2.1
        Extended IP access list VPN
            access-list VPN permit ip 10.5.5.0 0.0.0.255 223.255.255.0 0.0.0.255
        Current peer: 10.2.2.1
        Security association lifetime: 4608000 kilobytes/3600 seconds
        Responder-Only (Y/N): N
        PFS (Y/N): N
        Transform sets={
                TRA:  { esp-aes esp-sha-hmac  } ,
        }
        Interfaces using crypto map MAP:
                Ethernet1/0

Just in case I also checked if packets are really going via e1/0 interface.

BB_966#sh int e1/0
Ethernet1/0 is up, line protocol is up
  Hardware is AmdP2, address is aabb.cc03.c601 (bia aabb.cc03.c601)
  Internet address is 10.4.4.1/24
  MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 5000 bits/sec, 4 packets/sec
  5 minute output rate 5000 bits/sec, 4 packets/sec
     1149 packets input, 196489 bytes, 0 no buffer
     Received 154 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     1390 packets output, 222285 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     6 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Just for clarity, this excercise it purely "acadamic", adding a specific static route for tunnel endpoint resolves this without need for local policy.

Hi, Marcin

I'll test your config. It's very interesting because of 2 route-maps PBR and VPN_END.

Could you specify where have you applied them?

And why there should be 2 route-maps not one?

Thanks.

Hopefully this will also work for you and this is not something that works in my lab because of whatever (topology, stale CEF entries, whatever..)

Regarding two route-maps. I figured that I need normal PBR for all traffic that should go via IPsec.

If that is already getting policy routed to correct interface...

I need to make sure that:

- locally generated traffic will go to the tunnel endpoint when IPsec does it's thing.

- make sure we will not do some sort of u-turn and go out via default gataway, out the other interface (e0/0 being the defailt e0/1 being tha one we want to go out through)

BB_966#sh run int e2/0
Building configuration...

Current configuration : 142 bytes
!
interface Ethernet2/0
ip address 10.5.5.1 255.255.255.0
ip policy route-map PBR
ipv6 address 2001:DB8:DB2:5::1/64
ipv6 eigrp 65002
end

BB_966#sh ip local policy
Local policy routing is enabled, using route map VPN_END
route-map VPN_END, permit, sequence 10
  Match clauses:
    ip address (access-lists): VPN_END
  Set clauses:
    ip next-hop 10.4.4.2
  Policy routing matches: 7 packets, 1052 bytes

Debug IP packet det of tunnel establishing.


*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, local feature
*Oct 25 06:57:08.298:     UDP src=500, dst=500, Policy Routing(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, sending
*Oct 25 06:57:08.298:     UDP src=500, dst=500
*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, output feature
*Oct 25 06:57:08.298:     UDP src=500, dst=500, IPSec output classification(28), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, output feature
*Oct 25 06:57:08.298:     UDP src=500, dst=500, IPSec: to crypto engine(59), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, output feature
*Oct 25 06:57:08.298:     UDP src=500, dst=500, Post-encryption output features(60), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, post-encap feature
*Oct 25 06:57:08.298:     UDP src=500, dst=500, (1), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, post-encap feature
*Oct 25 06:57:08.298:     UDP src=500, dst=500, FastEther Channel(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, sending full packet
*Oct 25 06:57:08.298:     UDP src=500, dst=500
*Oct 25 06:57:08.330: IP: s=10.2.2.1 (Ethernet1/0), d=10.4.4.1, len 216, input feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, IPSec input classification(33), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: IP: s=10.2.2.1 (Ethernet1/0), d=10.4.4.1, len 216, input feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, MCI Check(67), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: FIBipv4-packet-proc: route packet from Ethernet1/0 src 10.2.2.1 dst 10.4.4.1
*Oct 25 06:57:08.330: FIBfwd-proc: Default:10.4.4.1/32 receive entry
*Oct 25 06:57:08.330: FIBipv4-packet-proc: packet routing failed
*Oct 25 06:57:08.330: IP: tableid=0, s=10.2.2.1 (Ethernet1/0), d=10.4.4.1 (Ethernet1/0), routed via RIB
*Oct 25 06:57:08.330: IP: s=10.2.2.1 (Ethernet1/0), d=10.4.4.1 (Ethernet1/0), len 216, rcvd 3
*Oct 25 06:57:08.330:     UDP src=500, dst=500
*Oct 25 06:57:08.330: IP: s=10.2.2.1 (Ethernet1/0), d=10.4.4.1, len 216, stop process pak for forus packet
*Oct 25 06:57:08.330:     UDP src=500, dst=500
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, local feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, Policy Routing(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, sending
*Oct 25 06:57:08.330:     UDP src=500, dst=500
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, output feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, IPSec output classification(28), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, output feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, IPSec: to crypto engine(59), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, output feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, Post-encryption output features(60), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, post-encap feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, (1), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, post-encap feature
*Oct 25 06:57:08.330:     UDP src=500, dst=500, FastEther Channel(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 25 06:57:08.330: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 88, sending full packet
*Oct 25 06:57:08.330:     UDP src=500, dst=50

Hi, Marcin

I've rewrite configs and test lab according to your ip-addresses and checked it a lot of times.

It does not work.

I can not ping from the WS 10.5.5.x the loopback of the remote router (150.1.4.4) throug the VPN.

VPN traffic is still goes to the default direction. May be there is my mistake somewhere?

show run
Building configuration...

Current configuration : 1909 bytes
!
version 12.4
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key cisco address 10.2.2.1
!
crypto ipsec transform-set TRA esp-aes esp-sha-hmac
!
crypto map MAP 10 ipsec-isakmp
set peer 10.2.2.1
set transform-set TRA
match address VPN
!
interface FastEthernet0/0

! ### to ISP_A, to default GW
ip address 10.3.3.1 255.255.255.0
!
interface FastEthernet0/1

! ### want to go this way =)
ip address 10.4.4.1 255.255.255.0
crypto map MAP
!
interface FastEthernet1/1
no switchport
ip address 10.5.5.1 255.255.255.0
ip policy route-map PBR
!

ip local policy route-map VPN_END
ip route 0.0.0.0 0.0.0.0 10.3.3.2
!

ip access-list extended VPN
permit ip 10.5.5.0 0.0.0.255 host 150.1.4.4
!

ip access-list extended VPN_END
permit ip any host 10.2.2.1
!
route-map PBR permit 10
match ip address VPN
set ip next-hop 10.4.4.2
!
route-map VPN_END permit 10
match ip address VPN_END
set ip next-hop 10.4.4.2

####

what next?

This one looks indeed correct ....possibilities:

- Version? Mine is 15.1(2)T, since it's a lab can you bring it up?

- Encyrption - software only encryption on my side.

Three things I'd like to confirm:

- Are ike packets following the path? Ie. is it a problem with IKE or ESP/AH?

- let's check "debu ip packet det" (if this is a lab otherwise we'll be flooded with info).

- check what the behavior will be if you use "ip route 10.2.2.1 255.255.255.255 10.4.4.2" instead of IP local policy. Just so we know we can establish it with routing pointing correctly.

Marcin

Hi.

This one looks indeed correct ....possibilities:
>>Version?
(C3725-ADVSECURITYK9-M), Version 12.4(15)T14

>>Encyrption - software only encryption on my side.
software

Three things I'd like to confirm:


>>Are ike packets following the path? Ie. is it a problem with IKE or ESP/AH?
only ike packets. Since ike packets go to the wrong direction - there is no reply from the remote site - no esp.


>>let's check "debu ip packet det" (if this is a lab otherwise we'll be flooded with info).

ping from the local WS (10.5.5.10 remote loopback 150.1.4.4)
:03.519: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
:03.519: IP: s=10.4.4.1 (local), d=10.2.2.1 (FastEthernet0/1), len 196, encapsulation failed
:03.523:     UDP src=500, dst=500
:13.775: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
:13.779: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 136, rcvd 3
:13.783:     UDP src=500, dst=500
:14.195: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
:14.203: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 332, rcvd 3
:14.203:     UDP src=500, dst=500
:14.867: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
:14.871: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 104, rcvd 3
:14.875:     UDP src=500, dst=500
:15.311: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
:15.311: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 200, rcvd 3
:15.315:     UDP src=500, dst=500
:19.815: IP: s=10.4.4.1 (Null0), d=10.2.2.1 (FastEthernet0/0), len 120, encapsulation failed, proto=50t1/1), d=10.5.5.255 (FastEthernet1/1), len 78, rcvd 3
37.151:     UDP src=137, dst=137

>>check what the behavior will be if you use "ip route 10.2.2.1 255.255.255.255 10.4.4.2" instead of IP local policy. Just so we know we can establish it with routing pointing correctly.

With static routing it works fine:
no ip cef

debug ip packets detail


02.763: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
02.795: IP: s=10.4.4.1 (local), d=10.2.2.1 (FastEthernet0/1), len 196, encapsulation failed
02.795:     UDP src=500, dst=500
07.903: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
13.303: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
13.307: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 136, rcvd 3
13.311:     UDP src=500, dst=500
13.359: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
14.047: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
14.051: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 332, rcvd 3
14.055:     UDP src=500, dst=500
14.715: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
14.715: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 104, rcvd 3
14.719:     UDP src=500, dst=500
15.323: IP: tableid=0, s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), routed via RIB
15.327: IP: s=10.2.2.1 (FastEthernet0/1), d=10.4.4.1 (FastEthernet0/1), len 200, rcvd 3
15.331:     UDP src=500, dst=500
18.879: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
18.883: IP: s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/1), g=10.4.4.2, len 60, forward
18.887:     ICMP type=8, code=0
19.367: IP: tableid=0, s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), routed via RIB
19.371: IP: s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), g=10.5.5.10, len 60, forward
19.375:     ICMP type=0, code=0
21.871: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
21.875: IP: s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/1), g=10.4.4.2, len 60, forward
21.879:     ICMP type=8, code=0
22.291: IP: tableid=0, s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), routed via RIB
22.291: IP: s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), g=10.5.5.10, len 60, forward
22.299:     ICMP type=0, code=0
22.895: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
22.899: IP: s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/1), g=10.4.4.2, len 60, forward
22.903:     ICMP type=8, code=0
23.319: IP: tableid=0, s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), routed via RIB
23.323: IP: s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), g=10.5.5.10, len 60, forward
23.327:     ICMP type=0, code=0
23.851: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
23.855: IP: s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/1), g=10.4.4.2, len 60, forward
23.859:     ICMP type=8, code=0
24.263: IP: tableid=0, s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), routed via RIB
24.263: IP: s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), g=10.5.5.10, len 60, forward
24.263:     ICMP type=0, code=0
24.887: IP: tableid=0, s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/0), routed via RIB
24.887: IP: s=10.5.5.10 (FastEthernet1/1), d=150.1.4.4 (FastEthernet0/1), g=10.4.4.2, len 60, forward
24.887:     ICMP type=8, code=0
25.307: IP: tableid=0, s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), routed via RIB
25.311: IP: s=150.1.4.4 (FastEthernet0/1), d=10.5.5.10 (FastEthernet1/1), g=10.5.5.10, len 60, forward
25.315:     ICMP type=0, code=0

Thanks.

The major difference being....

Yout case:

:03.519: IP: s=10.4.4.1 (local), d=10.2.2.1 (FastEthernet0/1), len 196, encapsulation failed

my case:

*Oct 25 06:57:08.298: IP: s=10.4.4.1 (local), d=10.2.2.1 (Ethernet1/0), len 216, sending

Encap failure, APR entry mismatch or something? Hard to say, maybe "just" a fault in IOS... would you be able to try with my version?

Not sure if old ISRs still support it ;-)

Marcin

I've tested this on different hardware and IOS (mainly 12.4).

The result is the same.

With the static route we have the same encapsulation failed string, but it works=)

I'll try to test with newer 15 IOS.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: