Hello,
I'm doing some testing on 12.4(20)T on a 3825 router that would terminate Cisco software VPN clients using DVTIs. We currently have a
2801 doing the same job running 12.4(15)T5. We have some problems with that, hence the change of platform. What I have found is that the routing appears to have changed & I'm not sure if this is a new bug or one that has been fixed, or just a change in functionality. The outside & inside of the tunnel are in different VRFs.What we are finding is that in 12.4(15)T5, the routes look like this:
router#sh ip route vrf test stat 10.0.0.0/16 is variably subnetted, 123 subnets, 7 masks S 10.0.0.15/32 [1/0] via 0.0.0.0, Virtual-Access75 S 10.0.0.14/32 [1/0] via 0.0.0.0, Virtual-Access83 S 10.0.0.13/32 [1/0] via 0.0.0.0, Virtual-Access53 S 10.0.0.12/32 [1/0] via 0.0.0.0, Virtual-Access3
These host routes get redistributed through the rest of the network & so all is OK.
And in 12.4(20)T the routes look like this:
router-3825#sh ip route vrf test stat 10.0.0.0/16 is variably subnetted, 123 subnets, 7 masks S 10.0.0.187/32 [1/0] via 80.193.x.x, Virtual-Access56 S 10.0.0.185/32 [1/0] via 82.69.x.x, Virtual-Access29 S 10.0.0.184/32 [1/0] via 91.125.x.x, Virtual-Access27
So, the next-hop is seen as the public IP of the client & these routes are not getting redistributed (unless there is also a default route in the vrf).
Interestingly - a router configured as an EZVPN client in network- extension mode works OK on 12.4(20)T. We have a workaround in place of adding a route to null in the vrf for the vpn client subnets as they are local to the router & fall on nice bit-boundaries.
The configs on the two routers are just the same so my question is, I think, has anyone got any ideas about whether this is correct behaviour or a bug in 12.4(20)T? I can't find any relevant bugs on