cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1004
Views
5
Helpful
8
Replies

EIGRP not distributing networks

Ricky S
Level 3
Level 3

Hi all, I have a router that terminates VPN connections for remote access users for a particular office. This router also builds an EIGRP tunnel(s) to the DMVPN head-end routers at the data center and thats how it communicates with the rest of the corporation.

Router has a local VPN pool of IP addresses that it assigns to the remote access users upon authentication. Problem I am having is that when the users VPN into the router, they can only access local resources. They can't access anything anywhere else in the company.

VPN pool is 192.168.23.1 to 192.168.23.199

Below is the EIGRP section of the router

!

router eigrp 1

redistribute static route-map STATIC-TO-EIGRP

passive-interface default

no passive-interface Tunnel0

no passive-interface Tunnel1

network 10.10.200.0 0.0.0.255

network 10.10.201.0 0.0.0.255

network 172.23.0.0

network 192.168.23.0

network 192.168.155.23 0.0.0.0

no auto-summary

!

ip access-list standard STATIC-TO-EIGRP

permit 192.168.23.0 0.0.0.255

!

For some reason, this router does not advertise 192.168.23.0 to the DMVPN head-end router. Is it because 192.168.23.0 does not belong to any interfaces on this router? If so, is there a way I can get this to work?

Please advise

2 Accepted Solutions

Accepted Solutions

In the original post you ask if it is a problem  because the addresses of the pool are not associated with an interface. That might have been a problem. But your EIGRP is redistributing static routes. And the route map that controls the redistribution does permit the network that covers the address pool. So assuming that there is a static route for the 192.168.23.0 network then EIGRP could advertise that network. The suggestion from Edison is that the redistribution of static routes is not working because you do not specify a default metric for the redistribution. And in EIGRP the redistribution will not work without a default metric being specified. So Edison's suggestion is to add a default metric and then perhaps the redistribution will work.

If you do add the default metric and the redistribution still does not work then I would suggest that you do a show ip route and see if the static route for the 192.168.23.0 network is in the routing table. If it is not in the routing table then this is why the redistribution is not working and you need to work out that problem.

HTH

Rick

HTH

Rick

View solution in original post

Ricky

Probably the most easy thing would be to point the static route to null 0. This would make the static route valid and it would be inserted into the routing table. This would then allow the static route to be redistributed into EIGRP. EIGRP would advertise the entire network to the rest of your network and traffic for any address in that network would be routed back to your router with the VPN pool. If the traffic were for an active VPN user the traffic would be forwarded to the user and all traffic for addresses not currently active in VPN would be discarded. Probably this is the behavior that you want.

I have also seen this kind of thing done a bit differently. You could configure a loopback interface and give it the 192.168.23.0/24 address. Then EIGRP would advertise it and you would not need to worry about redistribution into EIGRP.

HTH

Rick

HTH

Rick

View solution in original post

8 Replies 8

Edison Ortiz
Hall of Fame
Hall of Fame

You are missing the metrics. You can use 1 1 1 1 1

Regards,

Edison

Hi Edison, can you elaborate please?

On the redistribute static command, you must also include metrics. These numbers can be arbitrary and 1 1 1 1 1 could be used as values.

You do have a static route configured for the 23.0 subnet, right?

Actually I don't have a static route on this router for that network. I was wandering about that also since it was setup by the engineer before my time. What would I point the static route to though since it's not assigned to any interfaces on the router.

In the original post you ask if it is a problem  because the addresses of the pool are not associated with an interface. That might have been a problem. But your EIGRP is redistributing static routes. And the route map that controls the redistribution does permit the network that covers the address pool. So assuming that there is a static route for the 192.168.23.0 network then EIGRP could advertise that network. The suggestion from Edison is that the redistribution of static routes is not working because you do not specify a default metric for the redistribution. And in EIGRP the redistribution will not work without a default metric being specified. So Edison's suggestion is to add a default metric and then perhaps the redistribution will work.

If you do add the default metric and the redistribution still does not work then I would suggest that you do a show ip route and see if the static route for the 192.168.23.0 network is in the routing table. If it is not in the routing table then this is why the redistribution is not working and you need to work out that problem.

HTH

Rick

HTH

Rick

Thanks for the info Rick. That explains a lot. However I am still wandering what the static route should point to for network 192.168.23.0 since it's just a local VPN pool?

Ricky

Ricky

Probably the most easy thing would be to point the static route to null 0. This would make the static route valid and it would be inserted into the routing table. This would then allow the static route to be redistributed into EIGRP. EIGRP would advertise the entire network to the rest of your network and traffic for any address in that network would be routed back to your router with the VPN pool. If the traffic were for an active VPN user the traffic would be forwarded to the user and all traffic for addresses not currently active in VPN would be discarded. Probably this is the behavior that you want.

I have also seen this kind of thing done a bit differently. You could configure a loopback interface and give it the 192.168.23.0/24 address. Then EIGRP would advertise it and you would not need to worry about redistribution into EIGRP.

HTH

Rick

HTH

Rick

Thanks! It's working now. Funny what Null0 can do

Much appreciated!