Redistribute static

wreed420
wreed420 used Ask the Experts™
on
Can someone explain in laymans terms what the command Redistribute static would do when used under EIGRP?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Hi,

redistrubute static will allow you to inject or include your static routes into your eigrp routing protocol.
the word 'Static" will act as the word "Network" in your eigrp statement.

example:
!========static routes========
ip route 192.168.1.0 255.255.255.0 10.1.1.1
ip route 192.168.2.0 255.255.255.0 10.1.1.2
!
router eigrp 100
network 172.16.0.1  0.0.0.255
network 172.17.1.1  0.0.0.255
Redistribute static  <<== will advertise the static routes mentioned above..

Hope that helps

Cheers
John



Author

Commented:
Would those routes then carry on to the main site? Problem is I have gained control of a campus and I need to create a new network for VPN users. We do not exactly get along with HQ that we are connected to. If I add a route to my switch that belongs to their EIGRP system with redistribute static enabled, could I potentially screw up something on their side if I inject a route with a overlapping network?

Author

Commented:
To the Top.
Exploring SharePoint 2016

Explore SharePoint 2016, the web-based, collaborative platform that integrates with Microsoft Office to provide intranets, secure document management, and collaboration so you can develop your online and offline capabilities.

Commented:
Yes, you can screw up doing this.  The 'redistribute static' will ensure that every static route configured is advertised to all EIGRP neighbors, which in turn will advertise it to the rest of the routers running EIGRP.

Either get to better terms with HQ, so that they can assign you an IP address range that is not overlapping, or limit the redistribution by using route-maps to redistribute all static routes except those you created.

Using John's example:  If you want to tell the HQ router about the 192.168.1.0 network, but not the 192.168.2.0 network, you can do the following:

ip access-list standard BlockStatic
 permit 192.168.1.0 0.0.0.255

route-map static_to_eigrp permit 10
 match ip address BlockStatic

router eigrp 100
 redistribute static route-map static_to_eigrp

You could also write the access-list the other way round, by denying your specific routes, and permitting everything else, i.e.
ip access-list standard BlockStatic
 deny 192.168.2.0 0.0.0.255
 permit any

How you do it, should most probably be determined by the number of 'legal' vs 'illegal' subnets.

Just another thing:  If you do not tell HQ about the additional static routes by implementing the route-map, you will not be able to access systems at HQ directly from your VPN connections.  Also, if there is address overlap, you will also not be able to access any of the corporate resources on the overlapping addresses from your branch at all, since a static route is more believable (lower Admin Distance) than routes learned from EIGRP.  This might matter, or might not.

Personally, I would suggest that you'd rather get valid addresses from HQ, since you can cause bigger problems if you implement this kind of under-the-table connectivity without looking at the entire network design.  If you wanted info for OSPF instead of EIGRP, I wouldn't even have answered your question, just in case I'm the 'HQ' you're mentioning... ;-)

Author

Commented:
We will not be getting on good terms with HQ, that is out of the question. We will be breaking off from them in the next couple months.
We do not need to get to any HQ devices on this new network and HQ does NOT need to know about my static routes, so I think it is safe to turn off the redistribute static command on my main router?

Thoughts?
Commented:
Are there any pre-existing static routes, i.e. static routes for subnets other than what you plan to introduce?  If not, you can safely remove 'redistribute static'.  This is sometimes a result of a standard configuration deployed when the network was put into service, and might not be doing anything currently. "show run | include ip route " or "show ip route static" should help you confirm pre-existing static routes.

But, as with every implimentation, make a back-up before changing this, and test the critical features that existed before once you've implemented this.

Author

Commented:
Otto,
We do have a couple static routes to singles hosts over IPSEC VPN tunnels. Currently the "ip routing" command is not enabled, will it need to be for the static routes to function when I remove redistribute static command from EIGRP?

Author

Commented:
Bump I wanna give someone some points!
Commented:
Sorry, business was a bit hectic for a couple of days...

I have trouble with your statement that "the 'ip routing' command is not enabled":  If this is the case (i.e. you have a 'no ip routing'-statement in the running config), the router would not have a routing table ('show ip route' would return an error message), and EIGRP would not be running (and I suspect that one would not be able to configure it).  In other words, your router will look like a Layer2 switch.  In this case, routing will be done by some other device on the network (probably in HQ), and will complicate the implementation of IPSec VPN tunnels somewhat (to put it mildly).

If ip routing is enabled (i.e. the router has a routing table), EIGRP will already advertise any static routes configured, as long as the next-hop addresses are reachable (and HQ will be able to see these routes, and would have complained if it broken their network, I assume).

But regardless of whether ip routing are enabled or not: If there is no static routes that HQ (or other branches) need to see, you can remove the 'redistribute static' without a second thought.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial