Jump to content
Sadikhov IT Certification forums
Sign in to follow this  


Recommended Posts

In hub-and-spoke environments, spoke routers (branch routers) often do not need to maintain complete routing tables of the network, as the paths to other portions of the network are always through the hub routers (head quarter routers). Additionally, the massive query-reply processes between the hub and spoke routers upon a loss route would affect the stability of the network.


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 are alternative paths through the spoke routers. 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:



Restricts an EIGRP stub router from advertising any route to other routers. This option will not allow other options to be specified 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.



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.



Allows an EIGRP stub router to advertise its static routes. The redistribute static router subcommand is required to redistribute static routes.



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.



Allows an EIGRP stub router to advertise external EIGRP routes learnt from other routing protocols or other EIGRP autonomous systems.


Note: Configuring EIGRP stub routing would teardown existing EIGRP neighbor relationships!


For you case, implement the EIGRP STUB (and not STUCK as in EIGRP Stuck in Active :)) on R4, R6, and R7. Just simply conf t, router eigrp, and the "eigrp stub".


After that, verify the stub configuration on R5 using the show ip eigrp neighbors detail EXEC command on R5. Below is the excerpt from my test lab.


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             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              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              Fa0/0             12 00:02:30  424  3816  0  25
  Version 12.3/1.2, Retrans: 1, Retries: 0

  • Upvote 1

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this