Twicking EIGRP metrics

September 2, 2008 at 5:35 pm | Posted in EIGRP, Routing | Leave a comment

What if I want to prefer one EIGRP path over the other? Changing metrics of course ;-)

R1 —- R3 —- R2

Both R1 and R2 advertized 100.0.0.0/8 toward R3, but R1 advertises a better metrics, hence a prefered path. I want to make R3 to chose path via R2 instead.

We can change bandwidth or delay on R3 interface. Note that EIGRP uses the minimum bandwidth of the path as one of the metrics (BW). So bumping up the BW for interface connecting to R3 might not actually doing me any good. If we check the show ip ei topo for the route, we might still see minimum bandwidth metric the unchanged for the path via Serial1/3. Instead

  • We can decrease bandwidth of Serial1/2 to let say 56K.
  • Alternatively, you can give Serial1/3 a very high delay.
  • Another option is to use offset-list

Here’s metric before the change

R3#sh ip ei topology 100.0.0.0/8
IP-EIGRP (AS 100): Topology entry for 100.0.0.0/8
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2244096
  Routing Descriptor Blocks:
  13.0.0.1 (Serial1/2), from 13.0.0.1, Send flag is 0x0
      Composite metric is (2244096/1732096), Route is External
      Vector metric:
        Minimum bandwidth is 1500 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 13.0.0.1 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)
  23.0.0.2 (Serial1/3), from 23.0.0.2, Send flag is 0x0
      Composite metric is (5537536/5025536), Route is External
      Vector metric:
        Minimum bandwidth is 512 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 23.0.0.2 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

R3#sh ip route ei
D EX 100.0.0.0/8 [170/2244096] via 13.0.0.1, 00:02:55, Serial1/2

Offset-list configuration

access-list 99 permit 100.0.0.0 0.255.255.255
router eigrp 100
 offset-list 99 in 5000000 Serial1/2
R3#sh ip eigrp topology 100.0.0.0/8
IP-EIGRP (AS 100): Topology entry for 100.0.0.0/8
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5537536
  Routing Descriptor Blocks:
  23.0.0.2 (Serial1/3), from 23.0.0.2, Send flag is 0x0
      Composite metric is (5537536/5025536), Route is External
      Vector metric:
        Minimum bandwidth is 512 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 23.0.0.2 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)
  13.0.0.1 (Serial1/2), from 13.0.0.1, Send flag is 0x0
      Composite metric is (7244096/6732096), Route is External
      Vector metric:
        Minimum bandwidth is 1500 Kbit
        Total delay is 216312 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 13.0.0.1 
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

R3#sh ip route ei
D EX 100.0.0.0/8 [170/5537536] via 23.0.0.2, 00:01:21, Serial1/3
Advertisements

Redistribution note – Lab 11 Task 3.9

August 10, 2008 at 3:15 pm | Posted in Blogroll, EIGRP, OSPF, Routing | Leave a comment

If an interface is redistributed into OSPF, then if we redistribute from OSPF -> EIGRP, then the interface is not automatically redistributed into EIGRP. We have to manually redistribute the connected interface into EIGRP.

RSRack1R5#srsr
router eigrp 10

redistribute ospf 1 metric 1 1 1 1 1 route-map OSPF_TO_EIGRP

router ospf 1
redistribute connected subnets route-map CONNECTED_TO_OSPF
redistribute eigrp 10 subnets route-map EIGRP_TO_OSPF

In this config, the CONNECTED_TO_EIGRP is missing. As the result, R6 will not see R5 Loop0. The R2 also learns an sub-optimal route of R5 loopback via R3 OSPF route, instead of from R5 directly.

EIGRP Maximum Delay pitfall

July 24, 2008 at 5:55 pm | Posted in EIGRP, Routing | Leave a comment

Setting interface delay to a maximum number will have undesired effect on the routing. You would normally expect that setting it to the max value, EIGRP will unfavor the path via  that link. It is not always the case. I think this is because when exceeding a certain integer number, the metric will be offset back to a small number, and is actually preferred.

Similar weid behavior is observed in OSPF virtual link path cost too. If you set the the “exiting” interface of the router with virtual link the to max of 65535, virtual link wont come up. However, it is OK to set ANY transit link to this maximum value, and the virtual link is fine. That weid things make IOS so beautifull, and attractive ;)

Here again is example of the weird EIGRP behaviour when setting the link delay to max.

IE WB – VOL1 – ver5, Task 5.14

Default Interface Delay

Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 10 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256
Routing Descriptor Blocks:
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (128256/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1

EIGRP is well behaving when Interface Delay is set to 1sec.

Rack1SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1SW1(config)#int vlan 67
Rack1SW1(config-if)#delay ?
<1-16777215>  Throughput delay (tens of microseconds)

Rack1SW1(config-if)#delay 100000
Rack1SW1(config-if)#end
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
02:09:19: %SYS-5-CONFIG_I: Configured from console by console
Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 1000000 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 668160
Routing Descriptor Blocks:
155.1.37.3 (FastEthernet0/3), from 155.1.37.3, Send flag is 0x0
Composite metric is (668160/642560), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit

Total delay is 26100 microseconds ! via other path

Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (25728000/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 1005000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1
Rack1SW1#sir 150.1.6.6
Routing entry for 150.1.6.0/24
Known via “eigrp 100”, distance 90, metric 668160, type internal
Redistributing via eigrp 100
Last update from 155.1.37.3 on FastEthernet0/3, 00:00:52 ago
Routing Descriptor Blocks:
* 155.1.37.3, from 155.1.37.3, 00:00:52 ago, via FastEthernet0/3
Route metric is 668160, traffic share count is 1
Total delay is 26100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3

EIGRP (or IOS??) is a bad boy when Interface Delay is set to Maximum.


Rack1SW1#
Rack1SW1#
Rack1SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1SW1(config)#int vlan 67
Rack1SW1(config-if)#delay ?
<1-16777215>  Throughput delay (tens of microseconds)

Rack1SW1(config-if)#delay 16777215
Rack1SW1(config-if)#
Rack1SW1#conf t
02:10:40: %SYS-5-CONFIG_I: Configured from console by console
Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 167772150 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 127744
Routing Descriptor Blocks:
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (127744/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 4990 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1
Rack1SW1#sir 150.1.6.6
Routing entry for 150.1.6.0/24
Known via “eigrp 100”, distance 90, metric 127744, type internal
Redistributing via eigrp 100
Last update from 155.1.67.6 on Vlan67, 00:00:19 ago
Routing Descriptor Blocks:
* 155.1.67.6, from 155.1.67.6, 00:00:19 ago, via Vlan67
Route metric is 127744, traffic share count is 1
Total delay is 4990 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1504 bytes
Loading 1/255, Hops 1

Verifying EIGRP Weight Metric

July 24, 2008 at 5:14 pm | Posted in EIGRP, Routing | Leave a comment

By default K1 = K3 = 1. All others weight metric are 0. This means, only bandwidth and delays are used in the EIGRP metric equation.

The online IOS help does not provide much information as to what metric a certain K refers to (e.g. K1 refers to bandwidth whereas K3 refers to delay). The Doc CD command reference is the friend in the lab! Also, we can use the show ip protocol command to verify the weight setting.

Rack1R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R1(config)#router ei 100
Rack1R1(config-router)#metric weight ?
<0-8>  Type Of Service (Only TOS 0 supported)

Rack1R1(config-router)#metric weight 0 ?
<0-255>  K1

Rack1R1(config-router)#metric weight 0

Rack1R1#sh ip protocols
Routing Protocol is “eigrp 100”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
150.1.0.0
155.1.0.0
Routing Information Sources:
Gateway         Distance      Last Update
(this router)         90      00:10:59
155.1.146.4           90      00:05:07
155.1.146.6           90      00:05:07
155.1.13.3            90      00:05:07
155.1.0.5             90      00:05:07
Distance: internal 90 external 170

EIGRP summarization caveat

July 24, 2008 at 4:14 pm | Posted in EIGRP, Routing | Leave a comment

WB1-Ver5-Task 5.11

By default when advertizing a summary route in EIGRP (and also OSPF, and BGP), router automatically installs a route to Null0 to match the summary. This is to prevent the router from forwarding traffic for destination inside the summary that it does not have a longer match for.

However in certain design scenario this could be undesirable behavior. To resolve this, we can implemen one of these options:

    • Keep the default admin distance of 5 for summary route, but add another route with distance of 1-4, e.g. a static route, to override the route to null.
    • Change the default distance of 5 to 255, meaning the router will not install the route to null0

      This is difference from summarization in RIP. RIP does not installs a route to null, which may create a “route feedback”, which may make the network unstable (reachblility is on and off). More specifically, the router may receives a route from neighbor, without knowing that the orignator is itself. The router then advertize this “”new route” with a new RIP metric, creating a route-advertisment loop. The route eventually become a dead route, due to infinte metric, and is then removed from the routing table. When the original router removes it from the routing table, the cycle starts again with the summarize route being advertized with original metric of 1. To guard again this route feedback behaviour, we can implement one of the following options:

        • Set a static route, pointing to null on the router that originate default route.
        • Filter this route from being learnt from its neighbor, or
        • Advertize the summary route to ALL its neighbors.

          Protected: MPLS VPN – Customer & Backbone running EIGRP with different AS numbers

          February 12, 2007 at 6:55 am | Posted in Blogroll, EIGRP, MPLS, VPN | Enter your password to view comments.

          This content is password protected. To view it please enter your password below:

          Blog at WordPress.com.
          Entries and comments feeds.