A typical connection between a hub router and a spoke router has much less bandwidth than a connection in the network core. Therefore attempting to use such connections as transit paths would typically results in excessive congestion. EIGRP stub routing can prevent this problem by restricting the spoke router from advertising the routes from a hub router to another hub router. As a result, the hub routers would not notice there is an alternative path through the spoke router. However, stub routing is unable to stop the hub router from advertising routes to spoke router. Manual summarization is required on the hub to advertise only a default route to the spokes.
Note: A stub router would not advertise routes received from a neighbor to another neighbor.
Without stub routing implemented on dual-homed spoke routers, route filtering configuration is required on the spoke routers to prevent them from appearing as transit paths to the hub routers.
When the remote sites are not acting as a transit sites between the regional sites, the regional routers (hubs) should be configured to advertise only a default route to the remote routers. The remote routers (spokes) should be configured to advertise only their directly connected stub networks back to the regional routers to reduce the complexity of EIGRP convergence (the query-reply process) and the sizes of the EIGRP topology table and IP routing table.
EIGRP stub routing an efficient method for limiting the query range, therefore conserves bandwidth due to unnecessary queries, prevents SIA events, and improves network stability.
An EIGRP stub router would inform its stub status to upstream routers via the Hello packets. Any neighboring upstream router that receives such Hello packets will not query the stub router for lost routes, as the stub router has no downstream EIGRP neighbors and hence would not have alternative paths for a lost route. The upstream routers which connected to the stub router would answer any query on behalf of the stub router, which results in improved convergence time.
The eigrp stub [receive-only | connected , static , summary , redistributed] router subcommand configures an EIGRP router as an EIGRP stub router. An EIGRP stub router would advertise its connected and summary routes to other neighboring routers by default. Below describes the optional keywords that can be used to modify this behavior:
|receive-only||Restricts an EIGRP stub router from advertising any route to other routers. This option cannot be used with any other option as it prevents the advertisement of any type of route, which is not really useful; the other options can be configured in any combination. Use this option when the stub router has only a single interface.|
|connected||Allows an EIGRP stub router to advertise its connected routes. The network statement is required to include the connected interfaces into the EIGRP routing process. The redistribute connected router subcommand can also be used to redistribute connected subnets into the EIGRP routing process. This option is enabled by default and is the most widely used option.|
|static||Allows an EIGRP stub router to advertise its static routes. The redistribute static router subcommand is required to redistribute static routes.|
|summary||Allows an EIGRP stub router to advertise its summary routes. Summary routes can be configured manually with the ip summary-address eigrp interface subcommand or automatically with the auto-summary router subcommand. This option is enabled by default.|
|redistributed||Allows an EIGRP stub router to advertise external EIGRP routes learnt from other routing protocols or other EIGRP autonomous systems.|
By implementing EIGRP stub routing on BR1 and BR2, HQ1 and HQ2 would notice both branch routers as stub routers and will suppress the queries to these neighbors. HQ1 and HQ2 will no longer query BR1 and BR2 when the successor to 172.16.1.0/24 is lost; they will send update packets to BR1 and BR2 instead. However, BR1 and BR2 will still query HQ1 and HQ2 as they lost both the successor and feasible successor to 172.16.1.0/24.
HQ1#sh ip eigrp neighbors detail IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 2 10.10.10.10 Se1/1 14 00:02:28 1 4500 0 22 Version 12.3/1.2, Retrans: 2, Retries: 0 Stub Peer Advertising ( CONNECTED ) Routes Suppressing queries 1 10.10.10.6 Se1/0 13 00:02:29 1 4500 0 22 Version 12.3/1.2, Retrans: 2, Retries: 0 Stub Peer Advertising ( CONNECTED ) Routes Suppressing queries 0 10.10.10.2 Fa0/0 12 00:02:30 424 3816 0 25 Version 12.3/1.2, Retrans: 1, Retries: 0 HQ1#