Redistribute static into BGP

Using the redistribute static command injects all static routes into BGP. Again, the router periodically must examine the RIB to see if there are any additions to or deletions from the static route configuration. This takes extra CPU cycles. And if the next hop to where the static route points disappears, the static route is withdrawn, with a resulting withdrawal from BGP. A withdrawal from BGP results in a route flap, as mentioned previously. (As in the IGP case, the permanent static route is designed to work around this issue, but the problem is best avoided in the first place!)

Again, redistributing static routes into BGP covers all static routes configured on a routing device. Some prefixes (such as the RFC 1918 prefixes) might not desirable in BGP, so ISPs would add a route map to apply an access-list filter to the redistribution process. This can potentially lead to the situation discussed in the case of redistribute connected.

Some situations demand redistribute static, especially when communities are attached to the prefixes inserted into the BGP process. This appears to be the preferred process among ISPs because they find it easier to manage than applying a prefix matching the route map to individual network statements. The following example is very typical on a customer aggregation or edge device that sets a community of 65534:1234 on all the ISP's customer prefixes:

router bgp 65534 redistribute static route-map static-to-bgp

route-map static-to-bgp permit 5

match ip address prefix-list netblock-to-bgp set community 65534:1234 set origin igp

ip prefix-list netblock-to-bgp permit 220.220.0.0/16 le 30 !

ip route 220.220.1.32 255.255.255.224 serial 0/0 !

There are dangers with this: The prefix list could be deleted, but the ISP must weigh this danger against the administrative inconvenience/overhead of setting communities and so on on a per-network-statement basis.

The recommendation is to try to avoid using redistribute static if at all possible and then use it only if the situation (such as the one described previously) really warrants it.

IGP Configuration Hints

ISPs should be aware of a few configuration hints when configuring IGPs for their backbones. When the decision between EIGRP, OSPF, and IS-IS has been made, the aim is to design the IGP for efficient operation, fast failover, and, most important, scalability.

Continue reading here: Configuring OSPF

Was this article helpful?

+1 0