Most of Network Engineers are well aware about benefits of using Route Summarization. It's one of those tools which plays an important role in any modern network design specially EIGRP based large scale networks which are prone to old Evil known as Stuck In Active (SIA).
Now there are couple of benefits that Summarization offers like:
> Hiding More Specific Routes - Which Means If one or more networks becomes unreachable or are not stable, The Devices beyond summarization point won't notice this and hence will not cause network convergence
> Also the devices beyond summary point will have only summary route in their Routing Tables instead of more specific routes. Which means less memory utilization and less calculation over head on CPU.
Now what most documents and books doesn't talk about usually are side effects of summarization.
.jpg)
Pick EIGRP for instance.
Let's first understand how EIGRP chose it's metric that it should advertise to EIGRP Peers for given summary route.
The metric of a summary is based on the metrics of its components where EIGRP chooses the metric of the lowest cost component route as the metric of the summary. When EIGRP creates a summary route, it has to determine the metric to include with the route advertisement—EIGRP examines every entry in the database (topology table) looking for components of the summary that will be suppressed (thus represented by) the summary; EIGRP finds the component with the best composite metric and then copies the metric details from it (bandwidth, delay, etc.) into the summary topology table entry.
Now this technique works well for most of the time except if the component the metric was derived from flaps, the summary flaps as well.
Though we are using the summary to hide reachability information, yet changes to the metric information causes the routers beyond the summary to perform work to keep up with the metric changes. Also there is processing overhead for EIGRP to recalculate the summary metric each time a component changes.
Another Issue With Summarization is as shown below:
It's a typical Hub and Spoke Network where Spokes (R4/R5) are advertising specific subnets to Hub Routers (R2/R3) which are summarizing the Spoke Networks and advertising summary towards the Core Network.
Now as we know that CEF decisions are flow based usually. Which means although R1 will have two Next Hops in routing table for any given spoke subnet. It will still use one particular next hop to specific flow based on CEF Hash. Let's assume it chose R2 for that flow as shown below:
Now everything works well until the Link Between R2-R4 goes down.
Now from R1's prospective nothing has changed since it was receiving summary route from R2 and R3. Since it's just a specific route that has failed, nothing will change from summary standpoint. So our friend R1 never notice any network change and keep forwarding . Where as R2 has no physical connectivity to R4 any longer and effectively black hole the traffic.
Though this design can be fixed easily by introducing a link between R2 & R3:
But this remind us important role of Network Testing Phase as part of your network design and understanding Network Failure Domains well.
Further Readings:
Load Balancing With CEF
HTH...
Deepak Arora
Evil CCIE
Now there are couple of benefits that Summarization offers like:
> Hiding More Specific Routes - Which Means If one or more networks becomes unreachable or are not stable, The Devices beyond summarization point won't notice this and hence will not cause network convergence
> Also the devices beyond summary point will have only summary route in their Routing Tables instead of more specific routes. Which means less memory utilization and less calculation over head on CPU.
Now what most documents and books doesn't talk about usually are side effects of summarization.
Pick EIGRP for instance.
Let's first understand how EIGRP chose it's metric that it should advertise to EIGRP Peers for given summary route.
The metric of a summary is based on the metrics of its components where EIGRP chooses the metric of the lowest cost component route as the metric of the summary. When EIGRP creates a summary route, it has to determine the metric to include with the route advertisement—EIGRP examines every entry in the database (topology table) looking for components of the summary that will be suppressed (thus represented by) the summary; EIGRP finds the component with the best composite metric and then copies the metric details from it (bandwidth, delay, etc.) into the summary topology table entry.
Now this technique works well for most of the time except if the component the metric was derived from flaps, the summary flaps as well.
Though we are using the summary to hide reachability information, yet changes to the metric information causes the routers beyond the summary to perform work to keep up with the metric changes. Also there is processing overhead for EIGRP to recalculate the summary metric each time a component changes.
Another Issue With Summarization is as shown below:
It's a typical Hub and Spoke Network where Spokes (R4/R5) are advertising specific subnets to Hub Routers (R2/R3) which are summarizing the Spoke Networks and advertising summary towards the Core Network.
Now as we know that CEF decisions are flow based usually. Which means although R1 will have two Next Hops in routing table for any given spoke subnet. It will still use one particular next hop to specific flow based on CEF Hash. Let's assume it chose R2 for that flow as shown below:
Now everything works well until the Link Between R2-R4 goes down.
Now from R1's prospective nothing has changed since it was receiving summary route from R2 and R3. Since it's just a specific route that has failed, nothing will change from summary standpoint. So our friend R1 never notice any network change and keep forwarding . Where as R2 has no physical connectivity to R4 any longer and effectively black hole the traffic.
Though this design can be fixed easily by introducing a link between R2 & R3:
But this remind us important role of Network Testing Phase as part of your network design and understanding Network Failure Domains well.
Further Readings:
Load Balancing With CEF
EIGRP for IP: Basic Operation and Configuration (The Addison-Wesley Networking Basics Series)
Deepak Arora
Evil CCIE
No comments:
Post a Comment