There are two main options for EIGRP to advertise default routes: to define a static default route and advertise it with EIGRP and to flag an existing route to be used also as a default route.
1. Advertising static default routes into EIGRP:
Step 1: Create a static route default route using the "ip route 0.0.0.0 0.0.0.0 outgoing-interface" command.
Step 2: Inject this route into the EIGRP topology database, either using the network 0.0.0.0 command or by redistributing the static route.
R7(config)#ip route 0.0.0.0 0.0.0.0 fastEthernet 0/1
R7(config)#do show ip route
...
S* 0.0.0.0/0 is directly connected, FastEthernet0/1
R7(config-router)#network 0.0.0.0
On R7: Gateway of last resort is 0.0.0.0 to network 0.0.0.0
R6#show ip route
...
Gateway of last resort is 172.16.0.10 to network 0.0.0.0
...
D* 0.0.0.0/0 [90/2195456] via 172.16.0.10, 00:00:34, Serial0/1
R5#show ip route
...
Gateway of last resort is 172.16.0.5 to network 0.0.0.0
...
D* 0.0.0.0/0 [90/2221056] via 172.16.0.5, 00:06:28, FastEthernet0/0
R4#show ip route
...
Gateway of last resort is 172.16.0.1 to network 0.0.0.0
...
D* 0.0.0.0/0 [90/2707456] via 172.16.0.1, 00:07:13, Serial0/0
or, using static redistribution:
R7(config)#ip route 0.0.0.0 0.0.0.0 fastEthernet 0/1
R7(config)#do show ip route
...
S* 0.0.0.0/0 is directly connected, FastEthernet0/1
R7(config)#router eigrp 1
R7(config-router)#redistribute static
R6#show ip route
...
Gateway of last resort is 172.16.0.10 to network 0.0.0.0
...
D*EX 0.0.0.0/0 [170/2195456] via 172.16.0.10, 00:00:11, Serial0/1
R5#show ip route
...
Gateway of last resort is 172.16.0.5 to network 0.0.0.0
...
D*EX 0.0.0.0/0 [170/2221056] via 172.16.0.5, 00:01:30, FastEthernet0/0
R4#show ip route
...
Gateway of last resort is 172.16.0.1 to network 0.0.0.0
...
D*EX 0.0.0.0/0 [170/2707456] via 172.16.0.1, 00:02:12, Serial0/0
2. Configuring a Default Network:
Step 1: On the router to which all traffic should be directed, identify a classful network that can be advertised into the EIGRP domain, and ensure that network is being advertised into EIGRP (typically using the EIGRP network command).
Step 2: Configure that network as a default network using the global command "ip default-network network-number".
By adding the ip default-network command to refer to one of these networks, EIGRP then flags this route as a candidate default route.
As a result, each EIGRP router treats their route for this particular network also as if it were a default route.
"Gateway of last resort" refers to the next-hop router of a router’s current default route.
R4#show ip protocols
Routing Protocol is "eigrp 1"
...
Routing for Networks:
172.16.0.2/32
172.16.0.12/30
192.168.44.0
R4(config)#ip default-network 192.168.44.0
R4#show ip route
...
Gateway of last resort is not set
...
C* 192.168.44.0/24 is directly connected, Loopback44
Although R4 flags the route as a candidate default route, R4 itself does not use that route as its default, because R4 is actually the original advertiser of the default.
R5#show ip route
...
Gateway of last resort is 172.16.0.13 to network 192.168.44.0
...
D* 192.168.44.0/24 [90/2297856] via 172.16.0.13, 00:03:56, Serial0/1
R6#show ip route
...
Gateway of last resort is 172.16.0.2 to network 192.168.44.0
...
D* 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:04:31, Serial0/0
R7#show ip route
...
Gateway of last resort is 172.16.0.9 to network 192.168.44.0
...
D* 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:05:08, Serial0/0
If a router knows of multiple candidate default routes, it chooses the best route based on administrative distance and then metric, and uses that route as the basis for the gateway of last resort.
Setting Loopback 55 on R5 with the ip default-network command, R6 and R7 now have 2 default-routes in the routing table, with equal AD (EIGRP 90), but different costs.
R6 and R7 choose their gateway of last resort from the 2 default-networks based on metric (R5 will be the next hop for traffic destined outside the EIGRP domain).
R6#show ip route
...
Gateway of last resort is 172.16.0.6 to network 192.168.55.0
...
D* 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:09:30, Serial0/0
D* 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:01:57, FastEthernet0/1
R7#show ip route
...
Gateway of last resort is 172.16.0.9 to network 192.168.55.0
...
D* 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:12:48, Serial0/0
D* 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:05:15, Serial0/0
Sunday, July 28, 2013
CCNP ROUTE: 13.EIGRP Summarization
-EIGRP supports summarization at any router, unlike OSPF (only at ABR/ASBR).
-When EIGRP advertises a summary route, the advertising router considers the summary route to be up and working unless all subordinate routes fail.
-Summarization reduces Query scope: EIGRP Query stops at a router that has a summary route that includes the subnet listed in the Query but not the specific route listed in the Query.
-The summary has the metric of the best of the subnets being summarized.
-When summarizing, the router adds a route to its own routing table, for the summary prefix/prefix-length, with an outgoing interface of null0 (discard route).
-When the summarizing router receives a packet within the summary route’s range:
If the packet matches a more specific route than the summary route, the packet is forwarded based on that route.
When the packet does not match a more specific route, it matches the summary route and is discarded.
-When using auto-summary: When a router has multiple working interfaces, and those interfaces use IP addresses in different classful networks,
the router advertises a summary route for each classful network on interfaces attached to a different classful network. (EIGRP summarizes at classful boundaries)
-The "no auto-summary" command affects the behavior of the router on which it is configured only and tells that router to not advertise a summary route for the entire classful network.
-Instead, that router advertises all the subnets, as if the auto-summary feature did not exist.
General syntax (configured per interface): ip summary-address eigrp asn prefix subnet-mask
First we add some loopback interfaces to R4 and add them into the EIGRP process:
R4#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
Serial0/0 172.16.0.2 YES NVRAM up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/1 192.168.0.14 YES NVRAM up up
Serial0/2 172.16.0.13 YES NVRAM up up
Serial0/3 unassigned YES NVRAM administratively down down
Loopback44 192.168.44.44 YES NVRAM up up
Loopback45 192.168.45.45 YES manual up up
Loopback46 192.168.46.46 YES manual up up
Loopback47 192.168.47.47 YES manual up up
Loopback48 192.168.48.48 YES manual up up
Loopback49 192.168.49.49 YES manual up up
Loopback50 192.168.50.50 YES manual up up
R4#show run | s eigrp
router eigrp 1
network 172.16.0.2 0.0.0.0
network 172.16.0.12 0.0.0.3
network 192.168.44.0
network 192.168.45.0
network 192.168.46.0
network 192.168.47.0
network 192.168.48.0
network 192.168.49.0
network 192.168.50.0
no auto-summary
The newly added networks are advertised by R4 to all neighbors:
R6#show ip route
...
D 192.168.46.0/24 [90/2297856] via 172.16.0.2, 00:02:50, Serial0/0
D 192.168.47.0/24 [90/2297856] via 172.16.0.2, 00:02:47, Serial0/0
D 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:36:14, Serial0/0
D 192.168.45.0/24 [90/2297856] via 172.16.0.2, 00:02:56, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:36:14, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:36:15, FastEthernet0/1
D 192.168.50.0/24 [90/2297856] via 172.16.0.2, 00:02:37, Serial0/0
D 192.168.49.0/24 [90/2297856] via 172.16.0.2, 00:02:42, Serial0/0
D 192.168.48.0/24 [90/2297856] via 172.16.0.2, 00:02:46, Serial0/0
Now we can manually summarize these networks into a summary (applied on the interfaces to R4's neighbors) which can be advertised by R4 to its neighbors:
R4(config)#interface serial 0/0
R4(config-if)#ip summary-address eigrp 1 192.168.32.0 255.255.224.0
*Mar 1 03:22:52.387: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is resync: summary configured
R4(config)#interface serial 0/2
R4(config-if)#ip summary-address eigrp 1 192.168.32.0 255.255.224.0
*Mar 1 03:22:52.387: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is resync: summary configured
Now verifying on R6 again:
*Mar 1 00:41:08.651: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is resync: peer graceful-restart
R6#show ip route
...
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:43:50, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:03:00, FastEthernet0/1
D 192.168.32.0/19 [90/2297856] via 172.16.0.2, 00:02:52, Serial0/0
R4 added the summary route to its routing table (also keeping the specific routes to each loopback), with an outgoing interface of Null0:
R4#show ip route
...
D 192.168.32.0/19 is a summary, 00:04:26, Null0
-When EIGRP advertises a summary route, the advertising router considers the summary route to be up and working unless all subordinate routes fail.
-Summarization reduces Query scope: EIGRP Query stops at a router that has a summary route that includes the subnet listed in the Query but not the specific route listed in the Query.
-The summary has the metric of the best of the subnets being summarized.
-When summarizing, the router adds a route to its own routing table, for the summary prefix/prefix-length, with an outgoing interface of null0 (discard route).
-When the summarizing router receives a packet within the summary route’s range:
If the packet matches a more specific route than the summary route, the packet is forwarded based on that route.
When the packet does not match a more specific route, it matches the summary route and is discarded.
-When using auto-summary: When a router has multiple working interfaces, and those interfaces use IP addresses in different classful networks,
the router advertises a summary route for each classful network on interfaces attached to a different classful network. (EIGRP summarizes at classful boundaries)
-The "no auto-summary" command affects the behavior of the router on which it is configured only and tells that router to not advertise a summary route for the entire classful network.
-Instead, that router advertises all the subnets, as if the auto-summary feature did not exist.
General syntax (configured per interface): ip summary-address eigrp asn prefix subnet-mask
First we add some loopback interfaces to R4 and add them into the EIGRP process:
R4#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
Serial0/0 172.16.0.2 YES NVRAM up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/1 192.168.0.14 YES NVRAM up up
Serial0/2 172.16.0.13 YES NVRAM up up
Serial0/3 unassigned YES NVRAM administratively down down
Loopback44 192.168.44.44 YES NVRAM up up
Loopback45 192.168.45.45 YES manual up up
Loopback46 192.168.46.46 YES manual up up
Loopback47 192.168.47.47 YES manual up up
Loopback48 192.168.48.48 YES manual up up
Loopback49 192.168.49.49 YES manual up up
Loopback50 192.168.50.50 YES manual up up
R4#show run | s eigrp
router eigrp 1
network 172.16.0.2 0.0.0.0
network 172.16.0.12 0.0.0.3
network 192.168.44.0
network 192.168.45.0
network 192.168.46.0
network 192.168.47.0
network 192.168.48.0
network 192.168.49.0
network 192.168.50.0
no auto-summary
The newly added networks are advertised by R4 to all neighbors:
R6#show ip route
...
D 192.168.46.0/24 [90/2297856] via 172.16.0.2, 00:02:50, Serial0/0
D 192.168.47.0/24 [90/2297856] via 172.16.0.2, 00:02:47, Serial0/0
D 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:36:14, Serial0/0
D 192.168.45.0/24 [90/2297856] via 172.16.0.2, 00:02:56, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:36:14, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:36:15, FastEthernet0/1
D 192.168.50.0/24 [90/2297856] via 172.16.0.2, 00:02:37, Serial0/0
D 192.168.49.0/24 [90/2297856] via 172.16.0.2, 00:02:42, Serial0/0
D 192.168.48.0/24 [90/2297856] via 172.16.0.2, 00:02:46, Serial0/0
Now we can manually summarize these networks into a summary (applied on the interfaces to R4's neighbors) which can be advertised by R4 to its neighbors:
R4(config)#interface serial 0/0
R4(config-if)#ip summary-address eigrp 1 192.168.32.0 255.255.224.0
*Mar 1 03:22:52.387: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is resync: summary configured
R4(config)#interface serial 0/2
R4(config-if)#ip summary-address eigrp 1 192.168.32.0 255.255.224.0
*Mar 1 03:22:52.387: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is resync: summary configured
Now verifying on R6 again:
*Mar 1 00:41:08.651: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is resync: peer graceful-restart
R6#show ip route
...
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:43:50, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:03:00, FastEthernet0/1
D 192.168.32.0/19 [90/2297856] via 172.16.0.2, 00:02:52, Serial0/0
R4 added the summary route to its routing table (also keeping the specific routes to each loopback), with an outgoing interface of Null0:
R4#show ip route
...
D 192.168.32.0/19 is a summary, 00:04:26, Null0
CCNP ROUTE: 12.EIGRP Route filtering: Distribute Lists with Route Maps
-The route map match command can reference an ACL or prefix list, but doing so does introduce the possibility of confusion.
-The confusing part is that the decision to filter a route or allow the route through is based on the deny or permit in the route-map command, and not the
deny or permit in the ACL or prefix list.
-When referencing an ACL or prefix list from a route map, the ACL or prefix list simply matches all routes permitted by the ACL or prefix list.
-Routes that are denied by the ACL or prefix list simply do not match that match command’s logic, making IOS then consider the next route-map command.
-The route-map command includes an implied deny all clause at the end; to configure a permit all, use the route-map command, with a permit action, but without a match command.
Filter routes received by R7 using distribute lists, prefix lists and route maps:
Objective 1: Router R7 should not learn by EIGRP any routes starting with 192.168.44 and 192.168.55 and prefixes greater than (and including) /24.
Objective 2: R7 should not learn any EIGRP routes to networks with /30 masks.
R7's initial routing table:
R7#sho ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:13:47, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:13:47, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:13:47, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:13:47, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:13:47, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:13:49, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:15, FastEthernet0/1
First we have to configure 2 prefix lists on R6, one for each objective (it can also be done using a single prefix list for both):
R6(config)#ip prefix-list 44-55-routes permit 192.168.44.0/23 ge 24 le 32 (we are using "permit" so the route map match statement will consider this prefix list line; the implicit deny has no impact on the route map)
R6(config)#ip prefix-list 44-55-routes permit 192.168.55.0/23 ge 24 le 32 (same as above)
R6(config)#ip prefix-list slash-30-mask permit 0.0.0.0/0 ge 30 le 30 (same as above)
Next we have to configure the route map:
R6(config)#route-map filter-44-55-slash30 deny 10 (deny what is matched by the prefix list with a permit clause)
R6(config-route-map)#match ip address prefix-list 44-55-routes
R6(config)#route-map filter-44-55-slash30 deny 15 (deny what is matched by the prefix list with a permit clause)
R6(config-route-map)#match ip address prefix-list slash-30-mask
R6(config)#route-map filter-44-55-slash30 permit 20 (permit all other routes; this is necessary because of the implicit deny at the end of every route map)
R6#show route-map
route-map filter-44-55-slash30, deny, sequence 10
Match clauses:
ip address prefix-lists: 44-55-routes
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map filter-44-55-slash30, deny, sequence 15
Match clauses:
ip address prefix-lists: slash-30-mask
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map filter-44-55-slash30, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Now we have to reference the route map from a distribute list and apply this list to the EIGRP process:
R6(config-router)#distribute-list route-map filter-44-55-slash30 out serial 0/1
*Mar 1 00:38:33.663: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Verify the routing table of R7 (all the routes referenced by the route map were not advertised by R6 to R7):
R7#show ip route
...
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:41:19, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:14, FastEthernet0/1
-The confusing part is that the decision to filter a route or allow the route through is based on the deny or permit in the route-map command, and not the
deny or permit in the ACL or prefix list.
-When referencing an ACL or prefix list from a route map, the ACL or prefix list simply matches all routes permitted by the ACL or prefix list.
-Routes that are denied by the ACL or prefix list simply do not match that match command’s logic, making IOS then consider the next route-map command.
-The route-map command includes an implied deny all clause at the end; to configure a permit all, use the route-map command, with a permit action, but without a match command.
Filter routes received by R7 using distribute lists, prefix lists and route maps:
Objective 1: Router R7 should not learn by EIGRP any routes starting with 192.168.44 and 192.168.55 and prefixes greater than (and including) /24.
Objective 2: R7 should not learn any EIGRP routes to networks with /30 masks.
R7's initial routing table:
R7#sho ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:13:47, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:13:47, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:13:47, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:13:47, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:13:47, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:13:49, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:15, FastEthernet0/1
First we have to configure 2 prefix lists on R6, one for each objective (it can also be done using a single prefix list for both):
R6(config)#ip prefix-list 44-55-routes permit 192.168.44.0/23 ge 24 le 32 (we are using "permit" so the route map match statement will consider this prefix list line; the implicit deny has no impact on the route map)
R6(config)#ip prefix-list 44-55-routes permit 192.168.55.0/23 ge 24 le 32 (same as above)
R6(config)#ip prefix-list slash-30-mask permit 0.0.0.0/0 ge 30 le 30 (same as above)
Next we have to configure the route map:
R6(config)#route-map filter-44-55-slash30 deny 10 (deny what is matched by the prefix list with a permit clause)
R6(config-route-map)#match ip address prefix-list 44-55-routes
R6(config)#route-map filter-44-55-slash30 deny 15 (deny what is matched by the prefix list with a permit clause)
R6(config-route-map)#match ip address prefix-list slash-30-mask
R6(config)#route-map filter-44-55-slash30 permit 20 (permit all other routes; this is necessary because of the implicit deny at the end of every route map)
R6#show route-map
route-map filter-44-55-slash30, deny, sequence 10
Match clauses:
ip address prefix-lists: 44-55-routes
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map filter-44-55-slash30, deny, sequence 15
Match clauses:
ip address prefix-lists: slash-30-mask
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map filter-44-55-slash30, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Now we have to reference the route map from a distribute list and apply this list to the EIGRP process:
R6(config-router)#distribute-list route-map filter-44-55-slash30 out serial 0/1
*Mar 1 00:38:33.663: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Verify the routing table of R7 (all the routes referenced by the route map were not advertised by R6 to R7):
R7#show ip route
...
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:41:19, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:14, FastEthernet0/1
CCNP ROUTE: 11.EIGRP Route filtering: Distribute Lists with Prefix Lists
To use the prefix-list, the configuration simply refers to the prefix-list with the same distribute-list command seen earlier.
The IP prefix list consists of one or more global configuration commands(like numbered ACLs), with commands using the same name being in the same list (like named ACLs).
Each command has a permit or deny action—but because it is used only for matching routes, and not for packet filtering, the permit or deny keyword just implies whether a route is matched (permit) or not (deny).
General syntax:
ip prefix-list list-name [seq seq-value] {deny | permit prefix/prefixlength}[ge ge-value] [le le-value]
Parameters (optional):
ge-value, which stand for greater-than-or-equal-to
le-value, which stand for less-than-or-equal-to
Rule: prefix-length < ge-value <= le-value
The matching of the prefix works much like the ACL matching logic. The configured prefix/prefix-length implies a range of IP addresses.
For example, an ip prefix-list barney deny 10.0.0.0/8... implies any number whose first 8 bits (per the /8) match 10.0.0.0–in other words, all IPv4 addresses that begin with 10. Any route whose prefix is in this range-for example, 10.0.0.0, 10.1.1.0, and 10.5.255.128-would be considered to match this part of the logic.
Objective 1: Router R7 should not learn by EIGRP any routes starting with 192.168.44 and prefixes greater than (and including) /24.
For this, we should configure a prefix list first, on R6:
Before configuring the distribute list/prefix list:
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:26:27, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:26:27, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:26:27, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:26:27, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:26:27, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:26:29, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:01, FastEthernet0/1
Now, the distribution list must be created and applied under the EIGRP process, in the outbound direction to R7:
R6(config)#ip prefix-list TEST1 deny 192.168.44.0/23 ge 24 le 32 (since we have to filter routes with masks > /24 and the rule states "prefix-length < ge-value <= le-value", then we can choose /23)
R6(config)#ip prefix-list TEST1 permit 0.0.0.0/0 le 32 (permit all other routes)
R6#show ip prefix-list
ip prefix-list TEST1: 2 entries
seq 5 deny 192.168.44.0/23 ge 24
seq 10 permit 0.0.0.0/0 le 32
R6(config)#router eigrp 1
R6(config-router)#distribute-list prefix TEST1 out serial 0/1
*Mar 1 00:28:32.875: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Verifying the routing table on R7 - route to 192.168.44.0/24 (and prefix lenghts above) are now filtered and do not reach R7:
R7#show ip route
...
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:03:38, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:03:38, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:03:38, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:03:38, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:03:38, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:06, FastEthernet0/1
Note: As with ACLs, prefix lists have an implicit deny at the end, so the "ip prefix-list TEST1 permit 0.0.0.0/0 le 32" is necessary after defining the desired routes to be filtered.
"0.0.0.0/0 le 32" means ALL prefix/mask pairs. If this statement is not configured in the prefix lists, then R6 would not advertise any routes to R7:
R6(config)#no ip prefix-list TEST1 seq 10 permit 0.0.0.0/0 le 32
R6(config)#
*Mar 1 00:47:27.731: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
R6#show ip prefix-list
ip prefix-list TEST1: 1 entries
seq 5 deny 192.168.44.0/23 ge 24
Now R7 does not have any EIGRP routes in the routing table, because all the routes it knew about came from R6:
R7#sho ip route
...
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.0.8 is directly connected, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:23, FastEthernet0/1
Objective 2: R7 should not learn any EIGRP routes to networks with /30 masks (prefix list TEST1 was deleted from R6):
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:00:50, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:00:50, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:00:50, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:00:50, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:00:50, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:00:52, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:17, FastEthernet0/1
On R6, configure a new prefix list and a distribution list which refers to the prefix list and apply it to the EIGRP process:
R6(config)#ip prefix-list TEST2 deny 0.0.0.0/0 ge 30 le 30 (any routes with a /30 mask)
R6(config)#ip prefix-list TEST2 permit 0.0.0.0/0 le 32 (permit all other routes)
R6(config)#router eigrp 1
R6(config-router)#distribute-list prefix TEST2 out serial 0/1
*Mar 1 00:54:32.995: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Verifying the routing table on R7 - EIGRP routes with a /30 mask have been filtered by R6 and did not reach R7 (the only /30 routes in the routing table are Connected):
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:09:57, Serial0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:09:57, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:09:57, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:03, FastEthernet0/1
The IP prefix list consists of one or more global configuration commands(like numbered ACLs), with commands using the same name being in the same list (like named ACLs).
Each command has a permit or deny action—but because it is used only for matching routes, and not for packet filtering, the permit or deny keyword just implies whether a route is matched (permit) or not (deny).
General syntax:
ip prefix-list list-name [seq seq-value] {deny | permit prefix/prefixlength}[ge ge-value] [le le-value]
Parameters (optional):
ge-value, which stand for greater-than-or-equal-to
le-value, which stand for less-than-or-equal-to
Rule: prefix-length < ge-value <= le-value
The matching of the prefix works much like the ACL matching logic. The configured prefix/prefix-length implies a range of IP addresses.
For example, an ip prefix-list barney deny 10.0.0.0/8... implies any number whose first 8 bits (per the /8) match 10.0.0.0–in other words, all IPv4 addresses that begin with 10. Any route whose prefix is in this range-for example, 10.0.0.0, 10.1.1.0, and 10.5.255.128-would be considered to match this part of the logic.
Objective 1: Router R7 should not learn by EIGRP any routes starting with 192.168.44 and prefixes greater than (and including) /24.
For this, we should configure a prefix list first, on R6:
Before configuring the distribute list/prefix list:
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:26:27, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:26:27, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:26:27, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:26:27, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:26:27, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:26:29, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:01, FastEthernet0/1
Now, the distribution list must be created and applied under the EIGRP process, in the outbound direction to R7:
R6(config)#ip prefix-list TEST1 deny 192.168.44.0/23 ge 24 le 32 (since we have to filter routes with masks > /24 and the rule states "prefix-length < ge-value <= le-value", then we can choose /23)
R6(config)#ip prefix-list TEST1 permit 0.0.0.0/0 le 32 (permit all other routes)
R6#show ip prefix-list
ip prefix-list TEST1: 2 entries
seq 5 deny 192.168.44.0/23 ge 24
seq 10 permit 0.0.0.0/0 le 32
R6(config)#router eigrp 1
R6(config-router)#distribute-list prefix TEST1 out serial 0/1
*Mar 1 00:28:32.875: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Verifying the routing table on R7 - route to 192.168.44.0/24 (and prefix lenghts above) are now filtered and do not reach R7:
R7#show ip route
...
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:03:38, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:03:38, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:03:38, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:03:38, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:03:38, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:06, FastEthernet0/1
Note: As with ACLs, prefix lists have an implicit deny at the end, so the "ip prefix-list TEST1 permit 0.0.0.0/0 le 32" is necessary after defining the desired routes to be filtered.
"0.0.0.0/0 le 32" means ALL prefix/mask pairs. If this statement is not configured in the prefix lists, then R6 would not advertise any routes to R7:
R6(config)#no ip prefix-list TEST1 seq 10 permit 0.0.0.0/0 le 32
R6(config)#
*Mar 1 00:47:27.731: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
R6#show ip prefix-list
ip prefix-list TEST1: 1 entries
seq 5 deny 192.168.44.0/23 ge 24
Now R7 does not have any EIGRP routes in the routing table, because all the routes it knew about came from R6:
R7#sho ip route
...
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.0.8 is directly connected, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:23, FastEthernet0/1
Objective 2: R7 should not learn any EIGRP routes to networks with /30 masks (prefix list TEST1 was deleted from R6):
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:00:50, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:00:50, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:00:50, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:00:50, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:00:50, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:00:52, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:17, FastEthernet0/1
On R6, configure a new prefix list and a distribution list which refers to the prefix list and apply it to the EIGRP process:
R6(config)#ip prefix-list TEST2 deny 0.0.0.0/0 ge 30 le 30 (any routes with a /30 mask)
R6(config)#ip prefix-list TEST2 permit 0.0.0.0/0 le 32 (permit all other routes)
R6(config)#router eigrp 1
R6(config-router)#distribute-list prefix TEST2 out serial 0/1
*Mar 1 00:54:32.995: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Verifying the routing table on R7 - EIGRP routes with a /30 mask have been filtered by R6 and did not reach R7 (the only /30 routes in the routing table are Connected):
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:09:57, Serial0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:09:57, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:09:57, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:03, FastEthernet0/1
CCNP ROUTE: 10.EIGRP Route filtering: Distribute Lists with ACL
-To filter EIGRP routes by matching them using ACLs, the ACL must match a route with a permit clause to then allow the route to be advertised,
and match the route with a deny clause to filter the route.
-When referenced by the distribute-list command for the purpose of EIGRP route filtering, EIGRP compares the standard ACL source-address field to the subnet
number (prefix) of each EIGRP route.
Note: To find the range of numbers matched by an ACL’s address and wildcard mask values, use the address field as the low end of the range, and simply add the address and wildcard mask to find the high end of the range.
Now, consider R7 should not know about the 172.16.0.12/30 network. R6 should not advertise this route to R7.
Before configuring the distribute list/ACL:
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:08:12, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:08:11, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:08:12, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:08:12, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:08:12, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:08:13, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:09, FastEthernet0/1
An ACL must be configured on R6 first, which denies the 172.16.0.12/30 network, but allows any other routes to be advertised:
R6(config)#ip access-list standard 99
R6(config-std-nacl)#deny 172.16.0.12 0.0.0.3
R6(config-std-nacl)#permit any
R6#show access-lists
Standard IP access list 99
10 deny 172.16.0.12, wildcard bits 0.0.0.3
20 permit any
Now, the distribution list must be created and applied under the EIGRP process, in the outbound direction to R7:
R6(config)#router eigrp 1
R6(config-router)#distribute-list 99 out serial 0/1
*Mar 1 00:18:51.091: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Note: If we would have configured the distribute list without specifying the exit interface, then the route matched by the ACL would not be advertised to any EIGRP neighbors.
Verifying the routing table on R7:
R7#
*Mar 1 00:18:49.667: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is resync: peer graceful-restart
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:20:52, Serial0/0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:20:52, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:20:52, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:20:52, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:20:51, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:02, FastEthernet0/1
If further more, we want R7 to not know also about the 172.16.0.0/30 and 172.16.0.4/30 networks, we should just add 2 deny statements to the same ACL:
R6(config)#ip access-list standard 99
R6(config-std-nacl)#11 deny 172.16.0.0 0.0.0.3
R6(config-std-nacl)#12 deny 172.16.0.4 0.0.0.3
R6#show access-lists
Standard IP access list 99
10 deny 172.16.0.12, wildcard bits 0.0.0.3 (3 matches)
11 deny 172.16.0.0, wildcard bits 0.0.0.3 (2 matches)
12 deny 172.16.0.4, wildcard bits 0.0.0.3
20 permit any (11 matches)
Resulting in:
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:25:20, Serial0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:25:21, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:25:19, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:15, FastEthernet0/1
and match the route with a deny clause to filter the route.
-When referenced by the distribute-list command for the purpose of EIGRP route filtering, EIGRP compares the standard ACL source-address field to the subnet
number (prefix) of each EIGRP route.
Note: To find the range of numbers matched by an ACL’s address and wildcard mask values, use the address field as the low end of the range, and simply add the address and wildcard mask to find the high end of the range.
Now, consider R7 should not know about the 172.16.0.12/30 network. R6 should not advertise this route to R7.
Before configuring the distribute list/ACL:
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:08:12, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2707456] via 172.16.0.9, 00:08:11, Serial0/0
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:08:12, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:08:12, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:08:12, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:08:13, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:09, FastEthernet0/1
An ACL must be configured on R6 first, which denies the 172.16.0.12/30 network, but allows any other routes to be advertised:
R6(config)#ip access-list standard 99
R6(config-std-nacl)#deny 172.16.0.12 0.0.0.3
R6(config-std-nacl)#permit any
R6#show access-lists
Standard IP access list 99
10 deny 172.16.0.12, wildcard bits 0.0.0.3
20 permit any
Now, the distribution list must be created and applied under the EIGRP process, in the outbound direction to R7:
R6(config)#router eigrp 1
R6(config-router)#distribute-list 99 out serial 0/1
*Mar 1 00:18:51.091: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is resync: route configuration changed
Note: If we would have configured the distribute list without specifying the exit interface, then the route matched by the ACL would not be advertised to any EIGRP neighbors.
Verifying the routing table on R7:
R7#
*Mar 1 00:18:49.667: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is resync: peer graceful-restart
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:20:52, Serial0/0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.0.4/30 [90/2195456] via 172.16.0.9, 00:20:52, Serial0/0
D 172.16.0.0/30 [90/2681856] via 172.16.0.9, 00:20:52, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:20:52, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:20:51, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:02, FastEthernet0/1
If further more, we want R7 to not know also about the 172.16.0.0/30 and 172.16.0.4/30 networks, we should just add 2 deny statements to the same ACL:
R6(config)#ip access-list standard 99
R6(config-std-nacl)#11 deny 172.16.0.0 0.0.0.3
R6(config-std-nacl)#12 deny 172.16.0.4 0.0.0.3
R6#show access-lists
Standard IP access list 99
10 deny 172.16.0.12, wildcard bits 0.0.0.3 (3 matches)
11 deny 172.16.0.0, wildcard bits 0.0.0.3 (2 matches)
12 deny 172.16.0.4, wildcard bits 0.0.0.3
20 permit any (11 matches)
Resulting in:
R7#show ip route
...
D 192.168.44.0/24 [90/2809856] via 172.16.0.9, 00:25:20, Serial0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.8/30 is directly connected, Serial0/0
D 172.16.111.0/24 [90/2297856] via 172.16.0.9, 00:25:21, Serial0/0
D 192.168.55.0/24 [90/2323456] via 172.16.0.9, 00:25:19, Serial0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/1
R 10.0.200.0/24 [120/1] via 10.0.0.1, 00:00:15, FastEthernet0/1
CCNP ROUTE: 9. EIGRP neighborship using authentication
For two routers to become EIGRP neighbors, the following parameters must match:
- IP addresses in the same subnet
- same AS number
- same K-values
- same PSK (pass router authentication)
-EIGRP authentication causes routers to authenticate every EIGRP message.
-To do so, the routers should use the same preshared key (PSK), generating an MD5 digest for each EIGRP message based on that shared PSK.
-The key chain configuration concept allows the engineer to migrate from one key value to another over time.
-Just like a real key chain that has multiple keys, the IOS key chain concept allows the configuration of multiple keys—each identified with a number.
-If no lifetime has been configured for a key, it is considered to be valid during all time frames.
-However, when a key has been defined with a lifetime, the key is valid only during the valid lifetime.
-The existence of multiple keys in a key chain, and the existence of valid lifetimes for each key, can cause some confusion about when the keys are used.
-The rules can be summarized as follows:
■ Sending EIGRP messages: Use the lowest key number among all currently valid keys.
■ Receiving EIGRP message: Check the MD5 digest using ALL currently valid keys.
First, consider routers R6 and R7 (currently being neighbors):
R6#clock set 10:42:20 7 July 2013
R7#clock set 10:42:20 7 July 2013
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.2 Se0/0 10 00:12:29 42 252 0 11
1 172.16.0.10 Se0/1 11 00:12:29 31 200 0 3
0 172.16.0.6 Fa0/1 10 00:12:29 797 4782 0 10
R6(config)#key chain R6R7
R6(config-keychain)#key 1
R6(config-keychain-key)#key-string test67
R6(config-keychain-key)#accept-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R6(config-keychain-key)#send-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R6(config-keychain-key)#exit
R6(config-keychain)#key 2
R6(config-keychain-key)#key-string abcd1234
R6(config-keychain-key)#accept-lifetime 20:00:00 8 July 2013 infinite
R6(config-keychain-key)#send-lifetime 20:00:00 8 July 2013 infinite
Note: The key chain name and key numbers do not have to match on the two routers, only the key-string MUST MATCH!
Now we have to apply the key chain to interface connecting to R7, thus bringing the neighborship down (until the same config is made on R7):
R6(config)#interface serial 0/1
R6(config-if)#ip authentication mode eigrp 1 md5
Jul 7 12:04:34.707: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: authentication mode changed
R6(config-if)#ip authentication key-chain eigrp 9 R6R7
R7(config)#key chain R7R6
R7(config-keychain)#key 3
R7(config-keychain-key)#key
R7(config-keychain-key)#key-string test67
R7(config-keychain-key)#accept-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R7(config-keychain-key)#send-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R7(config-keychain-key)#exit
R7(config-keychain)#key 4
R7(config-keychain-key)#key-string abcd1234
R7(config-keychain-key)#accept-lifetime 20:00:00 8 July 2013 infinite
R7(config-keychain-key)#send-lifetime 20:00:00 8 July 2013 infinite
R7(config-keychain-key)#
Jul 7 12:10:17.235: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is up: new adjacency
Apply the key chain to the interface connecting to R6:
R7(config)#interface serial 0/0
R7(config-if)#ip authentication mode eigrp 1 md5
R7(config-if)#
Jul 7 12:27:05.267: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is down: authentication mode changed
Jul 7 12:27:08.539: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is up: new adjacency
R7(config-if)#ip authentication key-chain eigrp 1 R7R6
R7(config-if)#
Jul 7 12:27:34.603: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is down: keychain changed
Jul 7 12:27:35.823: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is up: new adjacency
Now the neighborship is up again:
R7#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.0.9 Se0/0 10 00:03:53 51 306 0 26
If disabling authentication on R7's Serial0/0 interface, then the neighborship fails (missing authentication):
R7(config)#interface serial 0/0
R7(config-if)#no ip authentication mode eigrp 1 md5
R6#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R6#
Jul 7 12:35:41.003: EIGRP: Serial0/1: ignored packet from 172.16.0.10, opcode = 5 (missing authentication)
Jul 7 12:35:41.007: EIGRP: Dropping peer, invalid authentication
Jul 7 12:35:41.011: EIGRP: Sending HELLO on Serial0/1
Jul 7 12:35:41.011: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Jul 7 12:35:41.015: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: Auth failure
If changing the key-string in the key chain configured on R7, then the neighborship fails (invalid authentication):
R6#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R6#
Jul 7 12:41:52.967: EIGRP: received packet with MD5 authentication, key id = 1
Jul 7 12:41:57.519: EIGRP: pkt key id = 1, authentication mismatch
Jul 7 12:41:57.523: EIGRP: Serial0/1: ignored packet from 172.16.0.10, opcode = 5 (invalid authentication)
Jul 7 12:41:57.523: EIGRP: Dropping peer, invalid authentication
Jul 7 12:41:57.527: EIGRP: Sending HELLO on Serial0/1
Jul 7 12:41:57.527: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Jul 7 12:41:57.539: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: Auth failure
- IP addresses in the same subnet
- same AS number
- same K-values
- same PSK (pass router authentication)
-EIGRP authentication causes routers to authenticate every EIGRP message.
-To do so, the routers should use the same preshared key (PSK), generating an MD5 digest for each EIGRP message based on that shared PSK.
-The key chain configuration concept allows the engineer to migrate from one key value to another over time.
-Just like a real key chain that has multiple keys, the IOS key chain concept allows the configuration of multiple keys—each identified with a number.
-If no lifetime has been configured for a key, it is considered to be valid during all time frames.
-However, when a key has been defined with a lifetime, the key is valid only during the valid lifetime.
-The existence of multiple keys in a key chain, and the existence of valid lifetimes for each key, can cause some confusion about when the keys are used.
-The rules can be summarized as follows:
■ Sending EIGRP messages: Use the lowest key number among all currently valid keys.
■ Receiving EIGRP message: Check the MD5 digest using ALL currently valid keys.
First, consider routers R6 and R7 (currently being neighbors):
R6#clock set 10:42:20 7 July 2013
R7#clock set 10:42:20 7 July 2013
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.2 Se0/0 10 00:12:29 42 252 0 11
1 172.16.0.10 Se0/1 11 00:12:29 31 200 0 3
0 172.16.0.6 Fa0/1 10 00:12:29 797 4782 0 10
R6(config)#key chain R6R7
R6(config-keychain)#key 1
R6(config-keychain-key)#key-string test67
R6(config-keychain-key)#accept-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R6(config-keychain-key)#send-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R6(config-keychain-key)#exit
R6(config-keychain)#key 2
R6(config-keychain-key)#key-string abcd1234
R6(config-keychain-key)#accept-lifetime 20:00:00 8 July 2013 infinite
R6(config-keychain-key)#send-lifetime 20:00:00 8 July 2013 infinite
Note: The key chain name and key numbers do not have to match on the two routers, only the key-string MUST MATCH!
Now we have to apply the key chain to interface connecting to R7, thus bringing the neighborship down (until the same config is made on R7):
R6(config)#interface serial 0/1
R6(config-if)#ip authentication mode eigrp 1 md5
Jul 7 12:04:34.707: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: authentication mode changed
R6(config-if)#ip authentication key-chain eigrp 9 R6R7
R7(config)#key chain R7R6
R7(config-keychain)#key 3
R7(config-keychain-key)#key
R7(config-keychain-key)#key-string test67
R7(config-keychain-key)#accept-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R7(config-keychain-key)#send-lifetime 11:55:55 7 July 2013 20:00:00 8 July 2013
R7(config-keychain-key)#exit
R7(config-keychain)#key 4
R7(config-keychain-key)#key-string abcd1234
R7(config-keychain-key)#accept-lifetime 20:00:00 8 July 2013 infinite
R7(config-keychain-key)#send-lifetime 20:00:00 8 July 2013 infinite
R7(config-keychain-key)#
Jul 7 12:10:17.235: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is up: new adjacency
Apply the key chain to the interface connecting to R6:
R7(config)#interface serial 0/0
R7(config-if)#ip authentication mode eigrp 1 md5
R7(config-if)#
Jul 7 12:27:05.267: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is down: authentication mode changed
Jul 7 12:27:08.539: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is up: new adjacency
R7(config-if)#ip authentication key-chain eigrp 1 R7R6
R7(config-if)#
Jul 7 12:27:34.603: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is down: keychain changed
Jul 7 12:27:35.823: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.9 (Serial0/0) is up: new adjacency
Now the neighborship is up again:
R7#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.0.9 Se0/0 10 00:03:53 51 306 0 26
If disabling authentication on R7's Serial0/0 interface, then the neighborship fails (missing authentication):
R7(config)#interface serial 0/0
R7(config-if)#no ip authentication mode eigrp 1 md5
R6#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R6#
Jul 7 12:35:41.003: EIGRP: Serial0/1: ignored packet from 172.16.0.10, opcode = 5 (missing authentication)
Jul 7 12:35:41.007: EIGRP: Dropping peer, invalid authentication
Jul 7 12:35:41.011: EIGRP: Sending HELLO on Serial0/1
Jul 7 12:35:41.011: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Jul 7 12:35:41.015: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: Auth failure
If changing the key-string in the key chain configured on R7, then the neighborship fails (invalid authentication):
R6#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R6#
Jul 7 12:41:52.967: EIGRP: received packet with MD5 authentication, key id = 1
Jul 7 12:41:57.519: EIGRP: pkt key id = 1, authentication mismatch
Jul 7 12:41:57.523: EIGRP: Serial0/1: ignored packet from 172.16.0.10, opcode = 5 (invalid authentication)
Jul 7 12:41:57.523: EIGRP: Dropping peer, invalid authentication
Jul 7 12:41:57.527: EIGRP: Sending HELLO on Serial0/1
Jul 7 12:41:57.527: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Jul 7 12:41:57.539: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: Auth failure
CCNP ROUTE: 8. EIGRP Unequal Load Balancing
It's used for traffic balancing and instant convergence, since the "backup" route is already in the routing table.
For configuring load balancing, we must use two commands: maximum-paths and variance.
"maximum paths" - defines the maximum allowed number of routes in the routing table for each destination network (default 4)
"variance" - tell IOS that the EIGRP metrics can be close in value and still be considered worthy of being added to the routing table (default 1)
The router multiplies the variance (1-128) times the successor route's FD (best metric route to reach the destination).
Any feasible successor (FS) routes whose metric is less than the product of variance times the FD are considered to be equal routes and may be placed into the routing table.
Rule: IF (FS < variance*FD) THEN place in the routing table
Consider R4's routes to the 172.16.0.4 network:
R4#show ip eigrp topology
...
P 172.16.0.4/30, 2 successors, FD is 2195456
via 172.16.0.1 (2195456/281600), Serial0/0
via 172.16.0.14 (2195456/281600), Serial0/2
R4#show ip route
...
D 172.16.0.4/30 [90/2195456] via 172.16.0.14, 00:19:37, Serial0/2
[90/2195456] via 172.16.0.1, 00:19:37, Serial0/0
Having the default variance of 1 and equal cost paths to 172.16.0.4/30, R4 added both routes in the routing table.
Consider R4's unequal cost routes to the 172.16.0.8 network:
R4#show ip eigrp topology
...
P 172.16.0.8/30, 1 successors, FD is 2681856
via 172.16.0.1 (2681856/2169856), Serial0/0
via 172.16.0.14 (2707456/2195456), Serial0/2
R4#show ip route
...
D 172.16.0.8/30 [90/2681856] via 172.16.0.1, 00:19:36, Serial0/0
For having both routes in the routing table, we must configure the variance parameter on R4:
R4(config)#router eigrp 1
R4(config-router)#variance 2
R4#show ip route
...
D 172.16.0.8/30 [90/2707456] via 172.16.0.14, 00:00:07, Serial0/2
[90/2681856] via 172.16.0.1, 00:00:07, Serial0/0
The result of the EIGRP calculation is obvious: 2707456 < 2*2681856.
For configuring load balancing, we must use two commands: maximum-paths and variance.
"maximum paths" - defines the maximum allowed number of routes in the routing table for each destination network (default 4)
"variance" - tell IOS that the EIGRP metrics can be close in value and still be considered worthy of being added to the routing table (default 1)
The router multiplies the variance (1-128) times the successor route's FD (best metric route to reach the destination).
Any feasible successor (FS) routes whose metric is less than the product of variance times the FD are considered to be equal routes and may be placed into the routing table.
Rule: IF (FS < variance*FD) THEN place in the routing table
Consider R4's routes to the 172.16.0.4 network:
R4#show ip eigrp topology
...
P 172.16.0.4/30, 2 successors, FD is 2195456
via 172.16.0.1 (2195456/281600), Serial0/0
via 172.16.0.14 (2195456/281600), Serial0/2
R4#show ip route
...
D 172.16.0.4/30 [90/2195456] via 172.16.0.14, 00:19:37, Serial0/2
[90/2195456] via 172.16.0.1, 00:19:37, Serial0/0
Having the default variance of 1 and equal cost paths to 172.16.0.4/30, R4 added both routes in the routing table.
Consider R4's unequal cost routes to the 172.16.0.8 network:
R4#show ip eigrp topology
...
P 172.16.0.8/30, 1 successors, FD is 2681856
via 172.16.0.1 (2681856/2169856), Serial0/0
via 172.16.0.14 (2707456/2195456), Serial0/2
R4#show ip route
...
D 172.16.0.8/30 [90/2681856] via 172.16.0.1, 00:19:36, Serial0/0
For having both routes in the routing table, we must configure the variance parameter on R4:
R4(config)#router eigrp 1
R4(config-router)#variance 2
R4#show ip route
...
D 172.16.0.8/30 [90/2707456] via 172.16.0.14, 00:00:07, Serial0/2
[90/2681856] via 172.16.0.1, 00:00:07, Serial0/0
The result of the EIGRP calculation is obvious: 2707456 < 2*2681856.
CCNP ROUTE: 7. EIGRP Stub routers
Stub router: A router that should not forward traffic between two remote EIGRP-learned subnets.
The stub router simply performs less work and reduces the Query Scope because neighbors will not send these routers any Query messages.
Stub routers still form neighborships, even in receive-only mode.
The "eigrp stub" command has several options. When issued simply as eigrp stub, the router uses default parameters, which are the connected and summary options.
Other options are: Static, Redistributed and Receive-only (does not advertise any routes).
The Query scope is limited using stub routers, thus reducing the EIGRP message traffic in a large network.
R4(config)#router eigrp 1
R4(config-router)#eigrp stub receive-only
R4(config-router)#
*Mar 1 00:05:26.579: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is down: peer info changed
*Mar 1 00:05:26.607: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.14 (Serial0/2) is down: peer info changed
*Mar 1 00:05:26.923: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is up: new adjacency
*Mar 1 00:05:30.335: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.14 (Serial0/2) is up: new adjacency
To demonstrate that a stub router does not receive any Query messages and, if configured with receive-only, will not advertise any routes, consider the following:
R4 is configured as stub receive-only. We can verify this on R4 and R6:
R4#show ip protocols
Routing Protocol is "eigrp 1"
...
EIGRP stub, receive-only
R6#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.0.2 Se0/0 11 00:01:49 43 387 0 12
Version 12.4/1.2, Retrans: 1, Retries: 0
Receive-Only Peer Advertising ( No ) Routes
Suppressing queries
2 172.16.0.10 Se0/1 11 00:07:01 162 972 0 7
Version 12.4/1.2, Retrans: 1, Retries: 0
1 172.16.0.6 Fa0/1 12 00:07:01 551 3306 0 12
Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 2
On R7, we can shutdown Serial0/0 so R6 (having no feasible successor to R7) would send Queries to its neighbors (R4 and R5).
But R6 knows that R4 is a stub router, so it doesn't send any Query messages out Serial0/1. R6 sends a Query only to R5 (out Fa0/1):
R6#debug eigrp packets query
EIGRP Packets debugging is on
(QUERY)
R6#
*Mar 1 00:16:30.475: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: holding time expired
R6#
*Mar 1 00:16:45.083: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down
*Mar 1 00:16:45.107: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 12-12
*Mar 1 00:16:45.111: EIGRP: Enqueueing QUERY on Serial0/0 nbr 172.16.0.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 12-12
*Mar 1 00:16:45.119: EIGRP: Enqueueing QUERY on FastEthernet0/1 iidbQ un/rely 0/1 serno 12-12
*Mar 1 00:16:45.123: EIGRP: Enqueueing QUERY on FastEthernet0/1 nbr 172.16.0.6 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 12-12
*Mar 1 00:16:45.127: EIGRP: Sending QUERY on FastEthernet0/1
*Mar 1 00:16:45.131: AS 1, Flags 0x0, Seq 23/0 idbQ 0/0 iidbQ un/rely 0/0 serno 12-12
*Mar 1 00:16:45.215: EIGRP: Received QUERY on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 00:16:45.215: AS 1, Flags 0x0, Seq 17/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:16:45.383: EIGRP: Received QUERY on Serial0/0 nbr 172.16.0.2
*Mar 1 00:16:45.383: AS 1, Flags 0x0, Seq 19/26 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
R6#
Also, regarding the routing process, R4, being a receive-only router, does not advertise the networks he knows of anymore (in this case: 192.168.44.0/24):
Before setting R4 as eigrp stub receive-only:
R6#show ip route
...
D 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:03:42, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:03:42, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:03:42, FastEthernet0/1
After setting R4 as eigrp stub receive-only (route to 192.168.44.0/24 is not in R6's routing table anymore - same on R5):
R6#show ip route
...
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:12:46, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:12:46, FastEthernet0/1
Although R4 is an eigrp stub receive-only, R6 maintains the neighborship with all the routers:
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.10 Se0/1 13 00:00:10 204 1224 0 10
0 172.16.0.2 Se0/0 12 00:40:48 58 348 0 19
1 172.16.0.6 Fa0/1 10 00:46:00 274 1644 0 23
The stub router simply performs less work and reduces the Query Scope because neighbors will not send these routers any Query messages.
Stub routers still form neighborships, even in receive-only mode.
The "eigrp stub" command has several options. When issued simply as eigrp stub, the router uses default parameters, which are the connected and summary options.
Other options are: Static, Redistributed and Receive-only (does not advertise any routes).
The Query scope is limited using stub routers, thus reducing the EIGRP message traffic in a large network.
R4(config)#router eigrp 1
R4(config-router)#eigrp stub receive-only
R4(config-router)#
*Mar 1 00:05:26.579: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is down: peer info changed
*Mar 1 00:05:26.607: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.14 (Serial0/2) is down: peer info changed
*Mar 1 00:05:26.923: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.1 (Serial0/0) is up: new adjacency
*Mar 1 00:05:30.335: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.14 (Serial0/2) is up: new adjacency
To demonstrate that a stub router does not receive any Query messages and, if configured with receive-only, will not advertise any routes, consider the following:
R4 is configured as stub receive-only. We can verify this on R4 and R6:
R4#show ip protocols
Routing Protocol is "eigrp 1"
...
EIGRP stub, receive-only
R6#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.0.2 Se0/0 11 00:01:49 43 387 0 12
Version 12.4/1.2, Retrans: 1, Retries: 0
Receive-Only Peer Advertising ( No ) Routes
Suppressing queries
2 172.16.0.10 Se0/1 11 00:07:01 162 972 0 7
Version 12.4/1.2, Retrans: 1, Retries: 0
1 172.16.0.6 Fa0/1 12 00:07:01 551 3306 0 12
Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 2
On R7, we can shutdown Serial0/0 so R6 (having no feasible successor to R7) would send Queries to its neighbors (R4 and R5).
But R6 knows that R4 is a stub router, so it doesn't send any Query messages out Serial0/1. R6 sends a Query only to R5 (out Fa0/1):
R6#debug eigrp packets query
EIGRP Packets debugging is on
(QUERY)
R6#
*Mar 1 00:16:30.475: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: holding time expired
R6#
*Mar 1 00:16:45.083: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down
*Mar 1 00:16:45.107: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 12-12
*Mar 1 00:16:45.111: EIGRP: Enqueueing QUERY on Serial0/0 nbr 172.16.0.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 12-12
*Mar 1 00:16:45.119: EIGRP: Enqueueing QUERY on FastEthernet0/1 iidbQ un/rely 0/1 serno 12-12
*Mar 1 00:16:45.123: EIGRP: Enqueueing QUERY on FastEthernet0/1 nbr 172.16.0.6 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 12-12
*Mar 1 00:16:45.127: EIGRP: Sending QUERY on FastEthernet0/1
*Mar 1 00:16:45.131: AS 1, Flags 0x0, Seq 23/0 idbQ 0/0 iidbQ un/rely 0/0 serno 12-12
*Mar 1 00:16:45.215: EIGRP: Received QUERY on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 00:16:45.215: AS 1, Flags 0x0, Seq 17/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:16:45.383: EIGRP: Received QUERY on Serial0/0 nbr 172.16.0.2
*Mar 1 00:16:45.383: AS 1, Flags 0x0, Seq 19/26 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
R6#
Also, regarding the routing process, R4, being a receive-only router, does not advertise the networks he knows of anymore (in this case: 192.168.44.0/24):
Before setting R4 as eigrp stub receive-only:
R6#show ip route
...
D 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:03:42, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:03:42, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:03:42, FastEthernet0/1
After setting R4 as eigrp stub receive-only (route to 192.168.44.0/24 is not in R6's routing table anymore - same on R5):
R6#show ip route
...
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:12:46, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:12:46, FastEthernet0/1
Although R4 is an eigrp stub receive-only, R6 maintains the neighborship with all the routers:
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.10 Se0/1 13 00:00:10 204 1224 0 10
0 172.16.0.2 Se0/0 12 00:40:48 58 348 0 19
1 172.16.0.6 Fa0/1 10 00:46:00 274 1644 0 23
CCNP ROUTE: 6. EIGRP Going Active state - Query/Reply messages
When EIGRP removes a successor route and no FS route exists, the router begins a process by which the router discovers if any loop-free alternative routes each reach that prefix.
This process is called going active on a route.
Routes for which the router has a successor route, and no failure has yet occurred, remain in a passive state.
Routes for which the successor route fails, with no feasible successor routes, move to an active state.
The router sends EIGRP Query messages to every neighbor except the neighbor in the failed route.
The Query asks a neighbor whether that neighbor has a loop-free route for the listed prefix/length.
The neighbor considers itself to have a loop-free route if that neighbor is passive for that prefix/length. If so, the neighbor 1) sends an EIGRP Reply message, telling the
original router that it does indeed have a loop-free route and 2) does not forward the Query.
If the neighbor itself is active on this route, that neighbor 1) floods EIGRP Query messages to its neighbors and 2) does not immediately send an EIGRP Reply back to the original router–instead waiting on replies to its own set of Query messages.
In the figure, we will shut down R7's interface to R6, so R6 would search for an alternate route using Query/Reply messages with its neighbors, R4 and R5.
R6 has no feasible successor for the network to R7:
R6#show ip eigrp topology
...
P 172.16.0.8/30, 1 successors, FD is 2169856
via Connected, Serial0/1
R7(config)#interface serial 0/0
R7(config-if)#shutdown
R6#debug eigrp packets query reply ack
R5#debug eigrp packets query reply ack
R4#debug eigrp packets query reply ack
R6#
*Mar 1 00:17:57.891: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: holding time expired
*Mar 1 00:18:14.575: EIGRP: Enqueueing QUERY on FastEthernet0/1 iidbQ un/rely 0/1 serno 13-13
*Mar 1 00:18:14.579: EIGRP: Enqueueing QUERY on FastEthernet0/1 nbr 172.16.0.6 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 13-13
*Mar 1 00:18:14.583: EIGRP: Sending QUERY on FastEthernet0/1
*Mar 1 00:18:14.587: AS 1, Flags 0x0, Seq 22/0 idbQ 0/0 iidbQ un/rely 0/0 serno 13-13
*Mar 1 00:18:14.591: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 13-13
*Mar 1 00:18:14.595: EIGRP: Enqueueing QUERY on Serial0/0 nbr 172.16.0.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 13-13
*Mar 1 00:18:14.603: EIGRP: Sending QUERY on Serial0/0 nbr 172.16.0.2
*Mar 1 00:18:14.603: AS 1, Flags 0x0, Seq 23/17 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 13-13
*Mar 1 00:18:14.647: EIGRP: Received ACK on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 00:18:14.647: AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar 1 00:18:14.655: EIGRP: Received ACK on Serial0/0 nbr 172.16.0.2
*Mar 1 00:18:14.655: AS 1, Flags 0x0, Seq 0/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar 1 00:18:14.659: EIGRP: Received REPLY on Serial0/0 nbr 172.16.0.2
*Mar 1 00:18:14.663: AS 1, Flags 0x0, Seq 18/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:18:16.243: EIGRP: Received REPLY on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 00:18:16.247: AS 1, Flags 0x0, Seq 20/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Until all Reply messages are received from the neighbors, the route is marked as Active (A), the Query is marked as sent (Q) and the R6 waits for Reply messages (r) from its two neighbors:
R6#show ip eigrp topology
...
A 172.16.0.8/30, 1 successors, FD is Inaccessible, Q
2 replies, active never, query-origin: Local origin
Remaining replies:
via 172.16.0.2, r, Serial0/0
via 172.16.0.6, r, FastEthernet0/1
Having no feasible successor for 172.16.0.8/30, R6 sends Query messages to its neighbors asking for a loop-free route to this network.
None of the neighbors has any route to 172.16.0.8/30, so they both send Query messages further (in this case - to each other), waiting for a Reply to their own Queries before replying to R6.
We can see this on R5, which further sends Query messages to R4.
R5 receives the Query from R6 on Fa0/0, asking for a backup to 172.16.0.8/30:
R5#
*Mar 1 00:18:15.931: EIGRP: Received QUERY on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:15.931: AS 1, Flags 0x0, Seq 22/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:18:15.931: EIGRP: Enqueueing ACK on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:15.931: Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar 1 00:18:15.935: EIGRP: Sending ACK on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:15.939: AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
R5 does not immediately send a Reply to R6, instead it asks his neighbor, R4, about that network, using Serial0/1 to R4:
*Mar 1 00:18:15.943: EIGRP: Enqueueing QUERY on Serial0/1 iidbQ un/rely 0/1 serno 15-15
*Mar 1 00:18:15.947: EIGRP: Enqueueing QUERY on Serial0/1 nbr 172.16.0.13 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 15-15
*Mar 1 00:18:15.955: EIGRP: Sending QUERY on Serial0/1 nbr 172.16.0.13
*Mar 1 00:18:15.955: AS 1, Flags 0x0, Seq 17/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 15-15
R5 receives a Reply from R4, in which R4 says it has no routes to 172.16.0.8/30:
*Mar 1 00:18:16.159: EIGRP: Received REPLY on Serial0/1 nbr 172.16.0.13
*Mar 1 00:18:16.159: AS 1, Flags 0x0, Seq 22/19 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:18:16.159: EIGRP: Enqueueing ACK on Serial0/1 nbr 172.16.0.13
*Mar 1 00:18:16.159: Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar 1 00:18:16.171: EIGRP: Sending ACK on Serial0/1 nbr 172.16.0.13
Having an answer to all Query messages sent (in this case only to R4), R5 replies to R6 saying it has no route to 172.16.0.8/30:
*Mar 1 00:18:16.179: EIGRP: Enqueueing REPLY on FastEthernet0/0 nbr 172.16.0.5 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 17-17
*Mar 1 00:18:17.527: EIGRP: Sending REPLY on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:17.531: AS 1, Flags 0x0, Seq 20/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 17-17
*Mar 1 00:18:17.587: EIGRP: Received ACK on FastEthernet0/0 nbr 172.16.0.5
Same process runs on R4. All Query/Reply packets between the three routers are acknowledged with an ACK packet. Reliable Transport Protocol (RTP) is used.
The IOS sets a time limit in which the router expects replies to all the queries it has sent (by default 3 mins). Routes for which a router does not receive a Reply within the defined timer are called Stuck-in-Active (SIA) routes.
Beginning with IOS version 12.2, the router sends a SIA-Query message to each neighbor who did not yet replied to the Query, after half of the configured timer expired (90 seconds).
If the neighbor sends back a SIA-Reply, this means that he is still waiting for replies to his own Query messages, so the neighborship is kept.
If the neighbor does not respond to the SIA-Query, then the neighborship fails.
This process is called going active on a route.
Routes for which the router has a successor route, and no failure has yet occurred, remain in a passive state.
Routes for which the successor route fails, with no feasible successor routes, move to an active state.
The router sends EIGRP Query messages to every neighbor except the neighbor in the failed route.
The Query asks a neighbor whether that neighbor has a loop-free route for the listed prefix/length.
The neighbor considers itself to have a loop-free route if that neighbor is passive for that prefix/length. If so, the neighbor 1) sends an EIGRP Reply message, telling the
original router that it does indeed have a loop-free route and 2) does not forward the Query.
If the neighbor itself is active on this route, that neighbor 1) floods EIGRP Query messages to its neighbors and 2) does not immediately send an EIGRP Reply back to the original router–instead waiting on replies to its own set of Query messages.
In the figure, we will shut down R7's interface to R6, so R6 would search for an alternate route using Query/Reply messages with its neighbors, R4 and R5.
R6 has no feasible successor for the network to R7:
R6#show ip eigrp topology
...
P 172.16.0.8/30, 1 successors, FD is 2169856
via Connected, Serial0/1
R7(config)#interface serial 0/0
R7(config-if)#shutdown
R6#debug eigrp packets query reply ack
R5#debug eigrp packets query reply ack
R4#debug eigrp packets query reply ack
R6#
*Mar 1 00:17:57.891: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: holding time expired
*Mar 1 00:18:14.575: EIGRP: Enqueueing QUERY on FastEthernet0/1 iidbQ un/rely 0/1 serno 13-13
*Mar 1 00:18:14.579: EIGRP: Enqueueing QUERY on FastEthernet0/1 nbr 172.16.0.6 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 13-13
*Mar 1 00:18:14.583: EIGRP: Sending QUERY on FastEthernet0/1
*Mar 1 00:18:14.587: AS 1, Flags 0x0, Seq 22/0 idbQ 0/0 iidbQ un/rely 0/0 serno 13-13
*Mar 1 00:18:14.591: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 13-13
*Mar 1 00:18:14.595: EIGRP: Enqueueing QUERY on Serial0/0 nbr 172.16.0.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 13-13
*Mar 1 00:18:14.603: EIGRP: Sending QUERY on Serial0/0 nbr 172.16.0.2
*Mar 1 00:18:14.603: AS 1, Flags 0x0, Seq 23/17 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 13-13
*Mar 1 00:18:14.647: EIGRP: Received ACK on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 00:18:14.647: AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar 1 00:18:14.655: EIGRP: Received ACK on Serial0/0 nbr 172.16.0.2
*Mar 1 00:18:14.655: AS 1, Flags 0x0, Seq 0/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar 1 00:18:14.659: EIGRP: Received REPLY on Serial0/0 nbr 172.16.0.2
*Mar 1 00:18:14.663: AS 1, Flags 0x0, Seq 18/23 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:18:16.243: EIGRP: Received REPLY on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 00:18:16.247: AS 1, Flags 0x0, Seq 20/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Until all Reply messages are received from the neighbors, the route is marked as Active (A), the Query is marked as sent (Q) and the R6 waits for Reply messages (r) from its two neighbors:
R6#show ip eigrp topology
...
A 172.16.0.8/30, 1 successors, FD is Inaccessible, Q
2 replies, active never, query-origin: Local origin
Remaining replies:
via 172.16.0.2, r, Serial0/0
via 172.16.0.6, r, FastEthernet0/1
Having no feasible successor for 172.16.0.8/30, R6 sends Query messages to its neighbors asking for a loop-free route to this network.
None of the neighbors has any route to 172.16.0.8/30, so they both send Query messages further (in this case - to each other), waiting for a Reply to their own Queries before replying to R6.
We can see this on R5, which further sends Query messages to R4.
R5 receives the Query from R6 on Fa0/0, asking for a backup to 172.16.0.8/30:
R5#
*Mar 1 00:18:15.931: EIGRP: Received QUERY on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:15.931: AS 1, Flags 0x0, Seq 22/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:18:15.931: EIGRP: Enqueueing ACK on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:15.931: Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar 1 00:18:15.935: EIGRP: Sending ACK on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:15.939: AS 1, Flags 0x0, Seq 0/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
R5 does not immediately send a Reply to R6, instead it asks his neighbor, R4, about that network, using Serial0/1 to R4:
*Mar 1 00:18:15.943: EIGRP: Enqueueing QUERY on Serial0/1 iidbQ un/rely 0/1 serno 15-15
*Mar 1 00:18:15.947: EIGRP: Enqueueing QUERY on Serial0/1 nbr 172.16.0.13 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 15-15
*Mar 1 00:18:15.955: EIGRP: Sending QUERY on Serial0/1 nbr 172.16.0.13
*Mar 1 00:18:15.955: AS 1, Flags 0x0, Seq 17/16 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 15-15
R5 receives a Reply from R4, in which R4 says it has no routes to 172.16.0.8/30:
*Mar 1 00:18:16.159: EIGRP: Received REPLY on Serial0/1 nbr 172.16.0.13
*Mar 1 00:18:16.159: AS 1, Flags 0x0, Seq 22/19 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:18:16.159: EIGRP: Enqueueing ACK on Serial0/1 nbr 172.16.0.13
*Mar 1 00:18:16.159: Ack seq 22 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar 1 00:18:16.171: EIGRP: Sending ACK on Serial0/1 nbr 172.16.0.13
Having an answer to all Query messages sent (in this case only to R4), R5 replies to R6 saying it has no route to 172.16.0.8/30:
*Mar 1 00:18:16.179: EIGRP: Enqueueing REPLY on FastEthernet0/0 nbr 172.16.0.5 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 17-17
*Mar 1 00:18:17.527: EIGRP: Sending REPLY on FastEthernet0/0 nbr 172.16.0.5
*Mar 1 00:18:17.531: AS 1, Flags 0x0, Seq 20/22 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 17-17
*Mar 1 00:18:17.587: EIGRP: Received ACK on FastEthernet0/0 nbr 172.16.0.5
Same process runs on R4. All Query/Reply packets between the three routers are acknowledged with an ACK packet. Reliable Transport Protocol (RTP) is used.
The IOS sets a time limit in which the router expects replies to all the queries it has sent (by default 3 mins). Routes for which a router does not receive a Reply within the defined timer are called Stuck-in-Active (SIA) routes.
Beginning with IOS version 12.2, the router sends a SIA-Query message to each neighbor who did not yet replied to the Query, after half of the configured timer expired (90 seconds).
If the neighbor sends back a SIA-Reply, this means that he is still waiting for replies to his own Query messages, so the neighborship is kept.
If the neighbor does not respond to the SIA-Query, then the neighborship fails.
CCNP ROUTE: 5. EIGRP Metric tuning: Offset Lists
-Offset Lists allow adding a value (an offset) to the calculated metric (FD and AD) for a destination network.
-The syntax for creating an offset list is: offset-list {access-list-number | access-list-name} {in | out} offset [interface-type interface-number]
-Offset Lists match prefixes/prefix lengths using an IP ACL, so that the offset is applied only to routes matched by the ACL with a permit clause.
Consider the same destination network as in previous examples, with its R6's two possible routes to it:
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
Now, let's say we want traffic from R6 to 172.16.0.12/30 to be routed through 172.16.0.2 (R4), instead of 172.16.0.6 (R5), without manually changing any metrics on R6.
For this, we should configure on R6 an offset list which adds a value to the metric of the 172.16.0.12/30 route received from R5, so that R5's route metric will be larger than R6's route metric for the same destination.
This way, R4 will be preferred as the next-hop for 172.16.0.12/30 network.
The offset list will be configured inbound on the port facing R5.
First, we should configure an ACL which matches the destination network with a permit clause.
To match the exact prefix and prefix length, use an extended ACL. When doing so, use the destination address field to match the prefix length.
R6(config)#access-list 100 permit ip host 172.16.0.12 host 0.0.0.3
R6#show access-lists
Extended IP access list 100
10 permit ip host 172.16.0.12 host 0.0.0.3
Then, configure the offset list on FastEthernet0/1 and add a value so that R5's route metric will be larger than R6's route metric for the same destination:
2681856 - 2195456 = 486400 (so let's add a rounded 500000 to the metric through R5)
R6(config)#router eigrp 1
R6(config-router)#offset-list 100 in 500000 fastEthernet 0/1
*Mar 1 00:39:57.163: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is resync: route configuration changed
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.2 (2681856/2169856), Serial0/0
R6#show ip route
...
D 172.16.0.12/30 [90/2681856] via 172.16.0.2, 00:04:05, Serial0/0
Now we see that R4 is indeed preferred to reach 172.16.0.12/30.
Also, we notice that no feasible successor exists anymore for this destination.
The reason is that when the offset list added the value of 500000 to the FD, it also added it to the AD, making the AD larger than the successor's FD, thus not satisfying the feasibility condition.
The former successor is still visible, confirming that the offset list added the configured value to both FD and AD:
R6#show ip eigrp topology all-links
...
P 172.16.0.12/30, 1 successors, FD is 2195456, serno 11
via 172.16.0.2 (2681856/2169856), Serial0/0
via 172.16.0.6 (2695456/2669856), FastEthernet0/1
Extracting 500000 from the current metric values (2695456/2669856) of the second route results in the initial values of this route (2195456/2169856).
Now, R6 will choose the path to R4 on Serial0/0 to reach 172.16.0.12/30.
-The syntax for creating an offset list is: offset-list {access-list-number | access-list-name} {in | out} offset [interface-type interface-number]
-Offset Lists match prefixes/prefix lengths using an IP ACL, so that the offset is applied only to routes matched by the ACL with a permit clause.
Consider the same destination network as in previous examples, with its R6's two possible routes to it:
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
Now, let's say we want traffic from R6 to 172.16.0.12/30 to be routed through 172.16.0.2 (R4), instead of 172.16.0.6 (R5), without manually changing any metrics on R6.
For this, we should configure on R6 an offset list which adds a value to the metric of the 172.16.0.12/30 route received from R5, so that R5's route metric will be larger than R6's route metric for the same destination.
This way, R4 will be preferred as the next-hop for 172.16.0.12/30 network.
The offset list will be configured inbound on the port facing R5.
First, we should configure an ACL which matches the destination network with a permit clause.
To match the exact prefix and prefix length, use an extended ACL. When doing so, use the destination address field to match the prefix length.
R6(config)#access-list 100 permit ip host 172.16.0.12 host 0.0.0.3
R6#show access-lists
Extended IP access list 100
10 permit ip host 172.16.0.12 host 0.0.0.3
Then, configure the offset list on FastEthernet0/1 and add a value so that R5's route metric will be larger than R6's route metric for the same destination:
2681856 - 2195456 = 486400 (so let's add a rounded 500000 to the metric through R5)
R6(config)#router eigrp 1
R6(config-router)#offset-list 100 in 500000 fastEthernet 0/1
*Mar 1 00:39:57.163: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is resync: route configuration changed
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.2 (2681856/2169856), Serial0/0
R6#show ip route
...
D 172.16.0.12/30 [90/2681856] via 172.16.0.2, 00:04:05, Serial0/0
Now we see that R4 is indeed preferred to reach 172.16.0.12/30.
Also, we notice that no feasible successor exists anymore for this destination.
The reason is that when the offset list added the value of 500000 to the FD, it also added it to the AD, making the AD larger than the successor's FD, thus not satisfying the feasibility condition.
The former successor is still visible, confirming that the offset list added the configured value to both FD and AD:
R6#show ip eigrp topology all-links
...
P 172.16.0.12/30, 1 successors, FD is 2195456, serno 11
via 172.16.0.2 (2681856/2169856), Serial0/0
via 172.16.0.6 (2695456/2669856), FastEthernet0/1
Extracting 500000 from the current metric values (2695456/2669856) of the second route results in the initial values of this route (2195456/2169856).
Now, R6 will choose the path to R4 on Serial0/0 to reach 172.16.0.12/30.
CCNP ROUTE: 4. EIGRP Metric tuning: Configuring the Metric Weights (K-values)
Rule: EIGRP requires that two routers’ k-values match before those routers can become neighbors.
-The k-values are multipliers used in calculating the extended formula of EIGRP metric: Metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]
-If at the end of calculating the EIGRP metric for 2 routes the metrics tie, then the route with the largest MTU is chosen. (Default MTU = 1500 bytes)
The default k-values of EIGRP are:
R6#show ip protocols
Routing Protocol is "eigrp 1"
...
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
R6(config-router)#metric weights ?
<0-8> Type Of Service (Only TOS 0 supported)
R6(config-router)#metric weights 0 ?
<0-255> K1
R6(config-router)#metric weights 0 1 ?
<0-255> K2
R6(config-router)#metric weights 0 1 1 ?
<0-255> K3
R6(config-router)#metric weights 0 1 1 1 ?
<0-255> K4
R6(config-router)#metric weights 0 1 1 1 1 ?
<0-255> K5
R6(config-router)#metric weights 0 1 1 1 1 1 ?
<cr>
If setting all k-values to 1, R6 will not be able to maintain the neighborship with R4 and R5, who both have the default k-values (1 0 1 0 0)
R6(config-router)#metric weights 0 1 1 1 1 1
R6(config-router)#
*Mar 1 06:33:04.578: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is down: metric changed
*Mar 1 06:33:04.598: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is down: metric changed
*Mar 1 06:33:04.618: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: metric changed
*Mar 1 06:33:05.314: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is down: K-value mismatch
*Mar 1 06:33:06.690: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is down: K-value mismatch
*Mar 1 06:33:07.118: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: K-value mismatch
*Mar 1 06:33:09.718: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is down: Interface Goodbye received
*Mar 1 06:33:11.226: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is down: Interface Goodbye received
*Mar 1 06:33:11.590: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: Interface Goodbye received
After reconfiguring R6 with the default values the neighborships are restored:
R6(config-router)#metric weights 0 1 0 1 0 0
R6(config-router)#
*Mar 1 06:33:59.630: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is up: new adjacency
*Mar 1 06:34:00.354: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is up: new adjacency
*Mar 1 06:34:01.406: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is up: new adjacency
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.2 Se0/0 12 00:02:43 50 300 0 37
1 172.16.0.10 Se0/1 14 00:02:44 57 342 0 15
0 172.16.0.6 Fa0/1 11 00:02:45 87 522 0 28
-Cisco recommends again using k-values k2, k4, and k5, because a nonzero value for these parameters causes the metric calculation to include interface load and reliability.
-The load and reliability change over time, which causes EIGRP to reflood topology data, and may cause routers to continually choose different routes (route flapping).
-The k-values are multipliers used in calculating the extended formula of EIGRP metric: Metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]
-If at the end of calculating the EIGRP metric for 2 routes the metrics tie, then the route with the largest MTU is chosen. (Default MTU = 1500 bytes)
The default k-values of EIGRP are:
R6#show ip protocols
Routing Protocol is "eigrp 1"
...
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
R6(config-router)#metric weights ?
<0-8> Type Of Service (Only TOS 0 supported)
R6(config-router)#metric weights 0 ?
<0-255> K1
R6(config-router)#metric weights 0 1 ?
<0-255> K2
R6(config-router)#metric weights 0 1 1 ?
<0-255> K3
R6(config-router)#metric weights 0 1 1 1 ?
<0-255> K4
R6(config-router)#metric weights 0 1 1 1 1 ?
<0-255> K5
R6(config-router)#metric weights 0 1 1 1 1 1 ?
<cr>
If setting all k-values to 1, R6 will not be able to maintain the neighborship with R4 and R5, who both have the default k-values (1 0 1 0 0)
R6(config-router)#metric weights 0 1 1 1 1 1
R6(config-router)#
*Mar 1 06:33:04.578: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is down: metric changed
*Mar 1 06:33:04.598: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is down: metric changed
*Mar 1 06:33:04.618: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: metric changed
*Mar 1 06:33:05.314: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is down: K-value mismatch
*Mar 1 06:33:06.690: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is down: K-value mismatch
*Mar 1 06:33:07.118: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: K-value mismatch
*Mar 1 06:33:09.718: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is down: Interface Goodbye received
*Mar 1 06:33:11.226: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is down: Interface Goodbye received
*Mar 1 06:33:11.590: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: Interface Goodbye received
After reconfiguring R6 with the default values the neighborships are restored:
R6(config-router)#metric weights 0 1 0 1 0 0
R6(config-router)#
*Mar 1 06:33:59.630: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.6 (FastEthernet0/1) is up: new adjacency
*Mar 1 06:34:00.354: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is up: new adjacency
*Mar 1 06:34:01.406: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.2 (Serial0/0) is up: new adjacency
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.2 Se0/0 12 00:02:43 50 300 0 37
1 172.16.0.10 Se0/1 14 00:02:44 57 342 0 15
0 172.16.0.6 Fa0/1 11 00:02:45 87 522 0 28
-Cisco recommends again using k-values k2, k4, and k5, because a nonzero value for these parameters causes the metric calculation to include interface load and reliability.
-The load and reliability change over time, which causes EIGRP to reflood topology data, and may cause routers to continually choose different routes (route flapping).
CCNP ROUTE: 3. EIGRP Metric tuning: Configuring Bandwidth and Delay
The simplified formula for EIGRP metric is: Metric = 256 * ((10*7 / slowest-bandwidth) + cumulative-delay)
The better choice is to modify the Delay value, since Bandwidth is also used in several other network services like QoS and SNMP.
Let's consider the same route as above on R6:
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
R6#show interfaces fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is c003.2cd4.0001 (bia c003.2cd4.0001)
Internet address is 172.16.0.5/30
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
R6#show interfaces serial 0/0
Serial0/0 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 172.16.0.1/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
For the route through 172.16.0.6, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 2100) = 256 * 8576 = 2195456
For the route through 172.16.0.2, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 4000) = 256 * 10476 = 2681856
(decimals will be rounded DOWN to the nearest whole number)
If we want the route through 172.16.0.2 to be installed in the routing table and to be used to reach the 172.16.0.12/30 network, then modifying the Delay parameter is both easyer and recommended:
Before modification:
R6#show interfaces fastEthernet 0/1
...
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
R6#show ip route
...
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 05:30:57, FastEthernet0/1
To set bandwidth or delay, simply use the "bandwidth value" or "delay value" commands in interface configuration mode.
R6(config)#interface fastEthernet 0/1
R6(config-if)#delay ?
<1-16777215> Throughput delay (tens of microseconds)
R6(config-if)#delay 2001
After modification, the route through 172.16.0.2 is preferred due to a (slightly) lower metric (FD):
R6#show interfaces fastEthernet 0/1
...
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 20010 usec
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.2 (2681856/2169856), Serial0/0
via 172.16.0.6 (2682112/2169856), FastEthernet0/1
R6#sho ip route
...
D 172.16.0.12/30 [90/2681856] via 172.16.0.2, 00:00:27, Serial0/0
This time, for the route through 172.16.0.6, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 4001) = 256 * 10477 = 2682112
This time, for the route through 172.16.0.2, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 4000) = 256 * 10476 = 2681856
These calculations use the lowest bandwidth value (1544 Kbps) and the cumulative delay of each link from R6 to either R5 or R4 and the delay of R5's or R4's interface to the 172.16.0.12/30 network.
The AD of both routes in the EIGRP topology table is calculated as: AD = 256 * ((10*7 / 1544) + 2000) = 256 * 8476 = 2169856
The better choice is to modify the Delay value, since Bandwidth is also used in several other network services like QoS and SNMP.
Let's consider the same route as above on R6:
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
R6#show interfaces fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is c003.2cd4.0001 (bia c003.2cd4.0001)
Internet address is 172.16.0.5/30
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
R6#show interfaces serial 0/0
Serial0/0 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 172.16.0.1/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
For the route through 172.16.0.6, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 2100) = 256 * 8576 = 2195456
For the route through 172.16.0.2, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 4000) = 256 * 10476 = 2681856
(decimals will be rounded DOWN to the nearest whole number)
If we want the route through 172.16.0.2 to be installed in the routing table and to be used to reach the 172.16.0.12/30 network, then modifying the Delay parameter is both easyer and recommended:
Before modification:
R6#show interfaces fastEthernet 0/1
...
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
R6#show ip route
...
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 05:30:57, FastEthernet0/1
To set bandwidth or delay, simply use the "bandwidth value" or "delay value" commands in interface configuration mode.
R6(config)#interface fastEthernet 0/1
R6(config-if)#delay ?
<1-16777215> Throughput delay (tens of microseconds)
R6(config-if)#delay 2001
After modification, the route through 172.16.0.2 is preferred due to a (slightly) lower metric (FD):
R6#show interfaces fastEthernet 0/1
...
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 20010 usec
R6#show ip eigrp topology
...
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.2 (2681856/2169856), Serial0/0
via 172.16.0.6 (2682112/2169856), FastEthernet0/1
R6#sho ip route
...
D 172.16.0.12/30 [90/2681856] via 172.16.0.2, 00:00:27, Serial0/0
This time, for the route through 172.16.0.6, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 4001) = 256 * 10477 = 2682112
This time, for the route through 172.16.0.2, the metric calculation is: Metric = 256 * ((10*7 / 1544) + 4000) = 256 * 10476 = 2681856
These calculations use the lowest bandwidth value (1544 Kbps) and the cumulative delay of each link from R6 to either R5 or R4 and the delay of R5's or R4's interface to the 172.16.0.12/30 network.
The AD of both routes in the EIGRP topology table is calculated as: AD = 256 * ((10*7 / 1544) + 2000) = 256 * 8476 = 2169856
Saturday, July 27, 2013
CCNP ROUTE: 2. EIGRP Successor and Feasible Successor
Studying the EIGRP Successor and Feasible Successor concepts (on R6):
R6#sho ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.111.111)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.44.0/24, 1 successors, FD is 2297856
via 172.16.0.2 (2297856/128256), Serial0/0
P 192.168.55.0/24, 1 successors, FD is 409600
via 172.16.0.6 (409600/128256), FastEthernet0/1
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
P 172.16.0.8/30, 1 successors, FD is 2169856
via Connected, Serial0/1
P 172.16.0.4/30, 1 successors, FD is 281600
via Connected, FastEthernet0/1
P 172.16.0.0/30, 1 successors, FD is 2169856
via Connected, Serial0/0
P 172.16.111.0/24, 1 successors, FD is 128256
via Connected, Loopback111
Feasible Distance (FD): Integer metric for the route, from the local router’s pespective, used by the local router to choose the best route for that prefix. It is the distance from the local router to the destination network.
Reported Distance (RD): Integer metric for the route, from the neighboring router’s perspective (the neighbor that told the local router about the route). It is the distance from the neighboring router to the destination network, advertised to the local router. (aka AD - Advertised Distance)
-R6 has 2 possible ways to get to the network between R4 and R5 (172.16.0.12/30), as seen above.
-R6 installs both routes in the topology table, but only the Successor (172.16.0.6) in the routing table, for its best metric (FD): 2195456<2681856.
-The Feasible Successor is there as a backup in case the Successor fails and it will be installed in the routing table instantly after the Successor route fails, without any additional calculations.
-The FD to the destination network is 2195456. The AD from the neighbor to the destination is 2169856.
Feasibility condition: If a non-successor route’s RD is less than the FD, the route is a feasible successor route.
In this case, 2169856 is less than 2195456, so 172.16.0.2 is considered as a Feasible Successor.
As a result, only 172.16.0.6 will be installed in the routing table as a next-hop for 172.16.0.12/30:
R6#show ip route
...
D 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:24:24, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:24:24, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:24:24, FastEthernet0/1
R6#sho ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.111.111)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.44.0/24, 1 successors, FD is 2297856
via 172.16.0.2 (2297856/128256), Serial0/0
P 192.168.55.0/24, 1 successors, FD is 409600
via 172.16.0.6 (409600/128256), FastEthernet0/1
P 172.16.0.12/30, 1 successors, FD is 2195456
via 172.16.0.6 (2195456/2169856), FastEthernet0/1
via 172.16.0.2 (2681856/2169856), Serial0/0
P 172.16.0.8/30, 1 successors, FD is 2169856
via Connected, Serial0/1
P 172.16.0.4/30, 1 successors, FD is 281600
via Connected, FastEthernet0/1
P 172.16.0.0/30, 1 successors, FD is 2169856
via Connected, Serial0/0
P 172.16.111.0/24, 1 successors, FD is 128256
via Connected, Loopback111
Feasible Distance (FD): Integer metric for the route, from the local router’s pespective, used by the local router to choose the best route for that prefix. It is the distance from the local router to the destination network.
Reported Distance (RD): Integer metric for the route, from the neighboring router’s perspective (the neighbor that told the local router about the route). It is the distance from the neighboring router to the destination network, advertised to the local router. (aka AD - Advertised Distance)
-R6 has 2 possible ways to get to the network between R4 and R5 (172.16.0.12/30), as seen above.
-R6 installs both routes in the topology table, but only the Successor (172.16.0.6) in the routing table, for its best metric (FD): 2195456<2681856.
-The Feasible Successor is there as a backup in case the Successor fails and it will be installed in the routing table instantly after the Successor route fails, without any additional calculations.
-The FD to the destination network is 2195456. The AD from the neighbor to the destination is 2169856.
Feasibility condition: If a non-successor route’s RD is less than the FD, the route is a feasible successor route.
In this case, 2169856 is less than 2195456, so 172.16.0.2 is considered as a Feasible Successor.
As a result, only 172.16.0.6 will be installed in the routing table as a next-hop for 172.16.0.12/30:
R6#show ip route
...
D 192.168.44.0/24 [90/2297856] via 172.16.0.2, 00:24:24, Serial0/0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.12/30 [90/2195456] via 172.16.0.6, 00:24:24, FastEthernet0/1
C 172.16.0.8/30 is directly connected, Serial0/1
C 172.16.0.4/30 is directly connected, FastEthernet0/1
C 172.16.0.0/30 is directly connected, Serial0/0
C 172.16.111.0/24 is directly connected, Loopback111
D 192.168.55.0/24 [90/409600] via 172.16.0.6, 00:24:24, FastEthernet0/1
CCNP ROUTE: 1. EIGRP Protocol messages
Displaying EIGRP protocol messages on R6:
The EIGRP packets are: HELLO, UPDATE, QUERY, REPLY, ACK
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.10 Se0/1 12 01:13:21 145 870 0 3
1 172.16.0.2 Se0/0 10 01:13:24 186 1674 0 3
0 172.16.0.6 Fa0/1 13 01:13:24 757 4542 0 4
R6#debug eigrp packets
Normal operation:
*Mar 1 01:16:09.303: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:16:09.307: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:16:09.759: EIGRP: Received HELLO on Serial0/1 nbr 172.16.0.10
*Mar 1 01:16:09.759: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 01:16:10.099: EIGRP: Sending HELLO on Serial0/0
*Mar 1 01:16:10.099: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:16:10.243: EIGRP: Received HELLO on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 01:16:10.243: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 01:16:11.167: EIGRP: Sending HELLO on FastEthernet0/1
*Mar 1 01:16:11.167: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:16:11.655: EIGRP: Received HELLO on Serial0/0 nbr 172.16.0.2
*Mar 1 01:16:11.655: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Neighbor 172.16.0.10 (R7) goes down (after 15 seconds the Holdtime expires. Hello interval is 5 seconds. If the router does not receive a Hello from a neighbor for an entire Holdtime, then the neighbor is considered dead):
*Mar 1 01:16:44.027: EIGRP: Holdtime expired
*Mar 1 01:16:44.027: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: holding time expired
*Mar 1 01:16:44.035: Going down: Peer 172.16.0.10 total=2 stub 0 template=2, iidb-stub=0 iid-all=0
*Mar 1 01:16:44.043: EIGRP: Neighbor 172.16.0.10 went down on Serial0/1
Neighbor 172.16.0.10 (R7) comes back up (as soon as a Hello is received from R7 on Serial0/1, the adjacency is formed again and Update/ACK messages are flowing between the routers in order to exchange topology data):
*Mar 1 01:36:05.367: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:36:05.371: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:36:05.423: EIGRP: Received HELLO on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.423: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar 1 01:36:05.427: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is up: new adjacency
*Mar 1 01:36:05.431: EIGRP: Enqueueing UPDATE on Serial0/1 nbr 172.16.0.10 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar 1 01:36:05.435: EIGRP: Received UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.439: AS 1, Flags 0x1, Seq 5/0 idbQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar 1 01:36:05.443: EIGRP: Requeued unicast on Serial0/1
*Mar 1 01:36:05.443: EIGRP: Sending UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.447: AS 1, Flags 0x1, Seq 14/5 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar 1 01:36:05.447: EIGRP: Enqueueing UPDATE on Serial0/1 iidbQ un/rely 0/1 serno 1-6
*Mar 1 01:36:05.447: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:36:05.447: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/1
*Mar 1 01:36:05.451: EIGRP: Enqueueing UPDATE on Serial0/1 nbr 172.16.0.10 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
*Mar 1 01:36:05.455: EIGRP: Received UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.455: AS 1, Flags 0x8, Seq 6/14 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
*Mar 1 01:36:05.455: EIGRP: Enqueueing ACK on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.455: Ack seq 6 iidbQ un/rely 0/1 peerQ un/rely 1/1
*Mar 1 01:36:05.459: EIGRP: Suppressed ACK 6 to 172.16.0.10 on Serial0/1
*Mar 1 01:36:05.463: EIGRP: Sending UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.467: AS 1, Flags 0x8, Seq 15/6 idbQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 1-6
*Mar 1 01:36:05.475: EIGRP: Requeued unicast on Serial0/1
*Mar 1 01:36:05.519: EIGRP: Received UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.523: AS 1, Flags 0x8, Seq 7/15 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
This was a brief review of the EIGRP types of messages (except for QUERY and REPLY, which are covered in another lab exercise).
The EIGRP packets are: HELLO, UPDATE, QUERY, REPLY, ACK
R6#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.0.10 Se0/1 12 01:13:21 145 870 0 3
1 172.16.0.2 Se0/0 10 01:13:24 186 1674 0 3
0 172.16.0.6 Fa0/1 13 01:13:24 757 4542 0 4
R6#debug eigrp packets
Normal operation:
*Mar 1 01:16:09.303: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:16:09.307: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:16:09.759: EIGRP: Received HELLO on Serial0/1 nbr 172.16.0.10
*Mar 1 01:16:09.759: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 01:16:10.099: EIGRP: Sending HELLO on Serial0/0
*Mar 1 01:16:10.099: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:16:10.243: EIGRP: Received HELLO on FastEthernet0/1 nbr 172.16.0.6
*Mar 1 01:16:10.243: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 01:16:11.167: EIGRP: Sending HELLO on FastEthernet0/1
*Mar 1 01:16:11.167: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:16:11.655: EIGRP: Received HELLO on Serial0/0 nbr 172.16.0.2
*Mar 1 01:16:11.655: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Neighbor 172.16.0.10 (R7) goes down (after 15 seconds the Holdtime expires. Hello interval is 5 seconds. If the router does not receive a Hello from a neighbor for an entire Holdtime, then the neighbor is considered dead):
*Mar 1 01:16:44.027: EIGRP: Holdtime expired
*Mar 1 01:16:44.027: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is down: holding time expired
*Mar 1 01:16:44.035: Going down: Peer 172.16.0.10 total=2 stub 0 template=2, iidb-stub=0 iid-all=0
*Mar 1 01:16:44.043: EIGRP: Neighbor 172.16.0.10 went down on Serial0/1
Neighbor 172.16.0.10 (R7) comes back up (as soon as a Hello is received from R7 on Serial0/1, the adjacency is formed again and Update/ACK messages are flowing between the routers in order to exchange topology data):
*Mar 1 01:36:05.367: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:36:05.371: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:36:05.423: EIGRP: Received HELLO on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.423: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar 1 01:36:05.427: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.0.10 (Serial0/1) is up: new adjacency
*Mar 1 01:36:05.431: EIGRP: Enqueueing UPDATE on Serial0/1 nbr 172.16.0.10 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar 1 01:36:05.435: EIGRP: Received UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.439: AS 1, Flags 0x1, Seq 5/0 idbQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar 1 01:36:05.443: EIGRP: Requeued unicast on Serial0/1
*Mar 1 01:36:05.443: EIGRP: Sending UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.447: AS 1, Flags 0x1, Seq 14/5 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Mar 1 01:36:05.447: EIGRP: Enqueueing UPDATE on Serial0/1 iidbQ un/rely 0/1 serno 1-6
*Mar 1 01:36:05.447: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:36:05.447: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/1
*Mar 1 01:36:05.451: EIGRP: Enqueueing UPDATE on Serial0/1 nbr 172.16.0.10 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
*Mar 1 01:36:05.455: EIGRP: Received UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.455: AS 1, Flags 0x8, Seq 6/14 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
*Mar 1 01:36:05.455: EIGRP: Enqueueing ACK on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.455: Ack seq 6 iidbQ un/rely 0/1 peerQ un/rely 1/1
*Mar 1 01:36:05.459: EIGRP: Suppressed ACK 6 to 172.16.0.10 on Serial0/1
*Mar 1 01:36:05.463: EIGRP: Sending UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.467: AS 1, Flags 0x8, Seq 15/6 idbQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/1 serno 1-6
*Mar 1 01:36:05.475: EIGRP: Requeued unicast on Serial0/1
*Mar 1 01:36:05.519: EIGRP: Received UPDATE on Serial0/1 nbr 172.16.0.10
*Mar 1 01:36:05.523: AS 1, Flags 0x8, Seq 7/15 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
This was a brief review of the EIGRP types of messages (except for QUERY and REPLY, which are covered in another lab exercise).
CCNP ROUTE: Lab setup for EIGRP, OSPF, Path control
The above diagram will be used for studying all EIGRP, OSPF and Path control concepts in the CCNP ROUTE 642-902 curriculum.
This topology includes multi-area OSPF with Area 0 as the HQ backbone for the enterprise network and other OSPF areas or RIP/EIGRP domains acting like remote branches, partners or newly added companies.
Graphical Network Simulator (GNS3 0.8.3) has been used to build this topology. All routers are Cisco 2691 series, running the c2691-adventerprisek9-mz.124-25c image.
You can download this entire GNS3 CCNP lab (including the topology and configuration files for all routers) from HERE.
All 13 routers in the topology are configured with IP addresses and are running routing protocols specific to their position in the diagram. All lab exercises will be based on these configurations, with a general reloading process after each excercise, so the settings made in one lab will not interact with those made in the next one. After each router reloading, all IP addresses and basic routing protocol settings will be automatically restored from the configuration files saved in the CCNP_ROUTE_lab folder. The Frame Relay switch is configured with the correct DLCI/port mappings so R9 can communicate with R10 and R11 if other problems do not exist in the topology. The Ethernet switches are using default VLAN 1.
Note 1: Loopback interfaces are by default advertised with a /32 mask. You can advertise them as usual networks by configuring each interface as a point-to-point link.
Note 2: The direct link between R4 and R5 belongs to the EIGRP domain.
Note 3: Do not forget to recalculate the IdlePC value for the routers once you start this lab in GNS3!
Note 4: Do not forget to edit the topology file (using a text editor) and modify the IOS path or other parameters according to your operating system and file locations!
Note 5: This topology and its related configuration can be improved in many ways, but since it is 100% functional and all the theoretical concepts are applied within the exercises with the expected results, it may be considered a good practice for the CCNP ROUTE exam.
Note 6: For any GNS3 errors when opening/using the topology please refer to http://forum.gns3.net/.
Note 7: If you see the below error when loading the GNS3 topology, check the project's "config" folder to see if the router config files have the .cfg extension, and not .cfg.txt or any other extension.
Local configuration configs\Rx.cfg cannot be found for router Rx, use default base config instead.
Most of the theory in the following labs comes from CCNP ROUTE 642-902 Official Certification Guide, Wendell Odom, Cisco Press, which is a great source of information for the ROUTE exam.
Note 6: For any GNS3 errors when opening/using the topology please refer to http://forum.gns3.net/.
Note 7: If you see the below error when loading the GNS3 topology, check the project's "config" folder to see if the router config files have the .cfg extension, and not .cfg.txt or any other extension.
Local configuration configs\Rx.cfg cannot be found for router Rx, use default base config instead.
Most of the theory in the following labs comes from CCNP ROUTE 642-902 Official Certification Guide, Wendell Odom, Cisco Press, which is a great source of information for the ROUTE exam.
1. Configuring OSPF on R1:
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 192.168.0.0 0.0.0.7 area 0
network 192.168.0.12 0.0.0.3 area 0
network 192.168.0.16 0.0.0.3 area 0
network 192.168.0.20 0.0.0.3 area 0
network 192.168.100.0 0.0.0.255 area 0
2. Configuring OSPF on R2:
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
area 1 stub
network 192.168.0.0 0.0.0.7 area 0
network 192.168.168.0 0.0.0.3 area 1
3. Configuring OSPF on R3:
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 192.168.0.0 0.0.0.7 area 0
network 192.168.13.0 0.0.0.255 area 0
4. Configuring OSPF/EIGRP on R4:
router ospf 1
router-id 4.4.4.4
log-adjacency-changes
network 192.168.0.12 0.0.0.3 area 0
router eigrp 1
network 172.16.0.2 0.0.0.0
network 172.16.0.12 0.0.0.3
network 192.168.44.0
no auto-summary
5. Configuring OSPF/EIGRP on R5:
router ospf 1
router-id 5.5.5.5
log-adjacency-changes
network 192.168.0.16 0.0.0.3 area 0
router eigrp 1
network 172.16.0.6 0.0.0.0
network 172.16.0.12 0.0.0.3
network 192.168.55.0
no auto-summary
6. Configuring EIGRP on R6:
router eigrp 1
passive-interface Loopback111 (does NOT SEND or RECEIVE Hello messages on that interface)
network 172.16.0.0
no auto-summary
7. Configuring EIGRP/RIP on R7:
router eigrp 1
network 172.16.0.10 0.0.0.0
no auto-summary
router rip
version 2
network 10.0.0.0
8. Configuring RIP on R8:
router rip
version 2
passive-interface Loopback200 (accepts RIP updates, but does NOT send RIP updates on that int)
network 10.0.0.0
no auto-summary
9. Configuring OSPF multiarea, Frame Relay maps & OSPF over Frame Relay point-to-multipoint non-broadcast on R9, R10, R11:
R9#show run | s interface Serial0/1.1
interface Serial0/1.1 multipoint
ip address 10.0.1.1 255.255.255.248
ip ospf network point-to-multipoint non-broadcast
frame-relay map ip 10.0.1.2 102
frame-relay map ip 10.0.1.3 103
R9#show run | s ospf
ip ospf network point-to-multipoint non-broadcast
router ospf 1
router-id 9.9.9.9
log-adjacency-changes
area 3 nssa
network 10.0.1.0 0.0.0.255 area 2
network 192.168.0.20 0.0.0.3 area 0
network 192.168.3.0 0.0.0.3 area 3
neighbor 10.0.1.3
neighbor 10.0.1.2
R10#show run | s interface Serial0/0.1
interface Serial0/0.1 multipoint
ip address 10.0.1.2 255.255.255.248
ip ospf network point-to-multipoint non-broadcast
frame-relay map ip 10.0.1.1 201
frame-relay map ip 10.0.1.3 201
R10#show run | s ospf
ip ospf network point-to-multipoint non-broadcast
router ospf 1
router-id 10.10.10.10
log-adjacency-changes
network 10.0.1.0 0.0.0.255 area 2
network 10.0.10.0 0.0.0.255 area 2
neighbor 10.0.1.1
R11#show run | s interface Serial0/0.1
interface Serial0/0.1 multipoint
ip address 10.0.1.3 255.255.255.248
ip ospf network point-to-multipoint non-broadcast
frame-relay map ip 10.0.1.1 301
frame-relay map ip 10.0.1.2 301
R11#show run | s ospf
ip ospf network point-to-multipoint non-broadcast
router ospf 1
router-id 11.11.11.11
log-adjacency-changes
network 10.0.1.0 0.0.0.255 area 2
network 10.0.11.0 0.0.0.255 area 2
neighbor 10.0.1.1
10. Configuring OSPF/RIP on R12:
router ospf 1
router-id 12.12.12.12
log-adjacency-changes
area 3 nssa
network 192.168.3.0 0.0.0.3 area 3
network 192.168.33.0 0.0.0.255 area 3
router rip
version 2
passive-interface Loopback22
passive-interface Loopback33
network 192.168.22.0
no auto-summary
11. Configuring OSPF on R13:
router ospf 1
router-id 13.13.13.13
log-adjacency-changes
area 1 stub
network 192.168.168.0 0.0.0.3 area 1
network 192.168.169.0 0.0.0.255 area 1
Subscribe to:
Posts (Atom)