Re: Each vpn client causes OSPF to update routes

danieldiaz · ‎03-15-2006

I have ip local pool configured on router, in order for this range to be reached, I added reverse-route within crypto dyn-map. In addition, I created a static route for this range which then I re-distributed into ospf. The problem is that everytime a vpn client establishes tunnel it inserts its self into OSPF as a /32 route and causes OSPF to send route updates to attached routers. How can I prevent this from occuring each time a vpn client establishes a tunnel.

pkhatri · ‎03-15-2006

Would you be able to post the relevant bits of your config ?

Paresh

danieldiaz · ‎03-19-2006

Yes I can, but as I mentioned to jstrine@pnco.com let me clean up my config. I tried several things to get this to work. And eventhough I re-distributed the static, it was dropping every other packet to the host from a remote network. Once I inserted the revers-route, it replied to all ICMP requests. Once I do I will post it.

Thank you for your reply.

danieldiaz · ‎03-24-2006

Same symptom; each host route is injected into OSPF table. Our OSPF area is large and not too summarized so it is updating all my routers. It appears that I need to inject the route via RRI as wells as redistributing into OSPF. Some Cisco docs indicate RRI should inject into OSPF automatically while another indicated I need to redistribute static into OSPF. Bottom line it breaks if I dont do both. Here is an example from a neighbor router:

core-rtr#show ip route 192.168.122.0

Routing entry for 192.168.122.0/24, 5 known subnets

Variably subnetted with 3 masks

O 192.168.122.49/32 [110/392] via 208.140.4.106, 02:27:39, Serial2/0.30

O 192.168.122.32/28 [110/391] via 208.140.4.106, 02:27:39, Serial2/0.30

O E2 192.168.122.128/27 [110/20] via 208.140.4.106, 02:27:29, Serial2/0.30

O E2 192.168.122.129/32 [110/20] via 208.140.4.106, 02:09:18, Serial2/0.30*****VPN CLIENT

O 192.168.122.160/27 [110/391] via 208.140.4.106, 02:27:39, Serial2/0.30

jstrine · ‎03-15-2006

If you created the static route for the entire range for the VPN users (e.g., x.x.x.x/24) then just get rid of the reverse-route command. The /32 entries are just redundant at that point (since they are included in the /24 advertisement). The reason they get distributed, however, is because routes are chosen/redistributed with (all other things being equal) the most specific ones taking presecense (i.e., /32 over /24).

So really, with the reverse-route command and the /24 static route, all your routers are actually using the /32 because it is more specific and virtually ignoring the /24.

danieldiaz · ‎03-19-2006

I did try with just the static route being re-distributed but when I conducted ICMP test from a remote network it dropped every other packet. Once I configured the reverse-route every packet was being replied too.

I will start with a fresh config, I did try several things and my config is pretty extensive. I will try what you have suggested. Thank you.

jstrine · ‎03-19-2006

No problem. Repost if the clean config gives you similar results.

While I don't know if this is your situation or not, I have seen every-other-packet-drops when two routers advertise the same route with the same metric. For example, we moved our VPN tunnels from one fw to another, and until the route was deleted on the old, our core routers had two equal routes to the destination (but only the new firewall had the IPSec tunnel) and every other packet was effectively dropped. To check this, go to one of your core routers and "show ip route". Make sure the destination network has only one route.

danieldiaz · ‎03-24-2006