MTU in EIGRP metric?

Hello everyone,
Many pages describing EIGRP say that one of used metrics is the interface MTU. However, the formula for calculating the composite metric does not take MTU into account so the MTU can not affect the composite metric of a route.
I would like to ask how exactly is the MTU used in the EIGRP, then. Thank your for any insights!
With best regards,
Peter

Peter
You ask a very good question and I believe that you are on the right track in trying to understand it. Your observation is correct that MTU is a required parameter in specifying EIGRP metric (for redistribution) and is one of the parameters that is advertised. You are also correct in observing that there is nothing in the EIGRP calculation that uses MTU. So the real answer is that the EIGRP specification included MTU but that it does not play any active role in the path selection done by EIGRP.
HTH
Rick

Similar Messages

Offset-list to change EIGRP Metrics

I've got a sup720 that I would like to control which routes in the eigrp topology database get injected into the routing table. There are about 20 entries in the topology database for a specific route all with the same composite metric.
Any suggestions on how to control which routes populate the routing table?
Will using the offset-list command and a acl do it? If you guys think that will work could you give me an example of what the acl would look like?
My network is running just one eigrp process, with no route distribution.
Thanks in advance!

Craig
What you are asking for can be done but it will be a bit tedious. You describe having 20 entries in the topology table and you want to control which one gets placed into the routing table. To do that you can either make the composite metric of the one entry more attractive or you can make the composite metric of the other 19 less attractive.
When you use an offset list you add to the metric of an entry. It will not make any entry be more attractive but it can make other entries less attractive. So you could configure an offset list identifying the route in question and apply some offset (100 should work for example). Then you would need to apply this offset to the 19 neighbors who are advertising the route.
HTH
Rick

EIGRP Metric and UCLB Doc

Team,
http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html
I somehow find the doc for EIGRP unequal cost load balancing a little bit misleading because it shows that the cost to reach network X is additive to demonstrate EIGRP variance. The only time that the cost will be additive is if only delay is used along the path to network X. However, there is no mention about delay solely being used as the metric in the doc which might lead one to think that the metric for a certain route is FD = cost to neighbor + neighbor's RD.
Thoughts please. Thanks.

Team,
http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13677-19.html
I somehow find the doc for EIGRP unequal cost load balancing a little bit misleading because it shows that the cost to reach network X is additive to demonstrate EIGRP variance. The only time that the cost will be additive is if only delay is used along the path to network X. However, there is no mention about delay solely being used as the metric in the doc which might lead one to think that the metric for a certain route is FD = cost to neighbor + neighbor's RD.
Thoughts please. Thanks.

Why EIGRP metric didn't change after add delay?

Here is the lay out:
--R2--
E1---R1---E2/ \E3
--R3--
I have added delay for R2's E2 interface, but when I check the EIGRP topology from R1 for E3, the metric didn't change and they are still the same for R2 and R3.
Do I miss anything?

You've discovered that ascii diargams don't work on the forum. :-)
Remember that EIGRP always takes its metric from the inbound interface. In this case, R2 and R3 take their "connected metric" to E3, and advertise it to R1. R1 takes its delay from E2, and adds it to the delay R2 and R3 advertised. R2's metrics on E2 have no bearing or impact on R1's metric for E3.
R2's metric on E2 will have an impact on R2's cost to reach E1, however.... Always consider the direction the update is going, and then add cost on the inbound side of one of the hops if you want to traffic engineer, rather than the outbound side.
Russ.W

GRE tunnel MTU and bandwidth

Hi Everyone.
GRE tunnel from Site A has
MTU 17916 bytes, BW 100 Kbit, DLY 50000 usec,
Site B has
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
I read that default BW for GRE is 9kbit but here 1 side has default and other side has 100.
One side has default MTU other side has 17916
so is this normal behaviour?
So need to know the purpose of using MTU 17916 and bandwidth of 100 on Site A?
Thanks
Mahesh

Hello Mahesh,
The bandwidth and Delay on the Tunnel interface is sometimes used to change the EIGRP metrics to influence routing table. For example if you have two equal cost paths to certain network in your routing table, you can increase the delay on one of the tunnels and make the other tunnel the preffered one. Not sure if this is the case with your setup.. it;s really hard to say without looking at the config.
As for the MTU, not sure why MTU size is 17916.. 1514 make sense but still too big for a GRE tunnel.. I think
Please rate this post if helpful.. THanks

EIGRP and Load Balacing Per Packet CEF required on both ends???

Here's what I have.
-2 T1's with same EIGRP metric
-CEF is enabled and load sharing currently
1 Link is being used more than the other due to nature of load sharing and not per packet using CEF.
I need per packet setup to see if this improves performance and distributes the usage over both links effectively.
If I enable per-packet on my remote office, do I also have to enable it on each PVC that connects back to my central office per PVC. Or can you enable per packet on the remote location only and be ok? I dont have control over central office router and need to justify if I need to enable that on the Central office or not.
Cisco docs I reviewed on this doesn't say both ends.

I agree with Sundar's point about needing to configure both ends if you want to use per packet in each direction. His point about the implications of forcing process switching and its impact on CPU utilization of the router is true but I am not sure that is what the original post was asking about. As I understood the original post he was asking about the per-packet option available with CEF switching which does not produce process switched packets.
I have one caution to offer about turning on the per-packet option with CEF. If you do that you will probably get better - but still not even - balancing of the serial links. But the performance may not improve. In fact it may degrade. This is because doing per packet balancing introduces the liklihood of out of order packets. The impact of out of order packets varies depending on the application being run and the impact of out of order packets. Many applications when they get an out of order packet will discard the packet and retransmit packets to get them in the correct order. I actually know of one customer site where they enabled per packet balancing and the performance of the application got worse. So I suggest that you evaluate carefully the implications of per packet balancing.
HTH
Rick

EIGRP (OTP)

Hi,
I am trying to do load sharing between tow link
first link connect through MPLS cloud
the EIGRP OTP working fine on it .
second link connect through P2P
also at P2P eigrp running
in my routing table only show me one valid route
is't possible to make load sharing thought 2 link

Hi Ehsan,
With EIGRP, you can achieve load sharing if both paths to the same destination have the same best metric (equal-cast load balancing), or if the worse paths go through feasible successors and you configure the variance command (unequal-cost load balancing). In general, this is not trivial to achieve and may require a fair share of smart metric tweaking.
So the first thing to check is the output of the show ip eigrp topology table on the router with the two links (MPLS and P2P) and verify whether all destinations you want to load-balance for have at least one successor and one feasible successor identified. If yes then doing the load balancing is just a matter of activating the variance with a sensible value. If, however, the destinations only have a single successor and no feasible successor identified in the topology table then you will first need to start modifying metrics so that the neighbors first pass the feasibility condition and only then you can ask for load sharing.
I understand that this answer is just a very rough indication of where to focus your efforts, and is not a clean list of commands to apply to make the magic work. Tuning EIGRP metrics is not a routine task and it depends very strongly on your topology. What could perhaps help us suggest the more precise way of modifying your EIGRP metrics would be a listing of your show ip eigrp topology focusing on one particular network for which you'd like to achieve the load balancing. In that case please post the output of show ip eigrp topology X.X.X.X/M output so that we can see the component metrics in detail.
Best regards,
Peter

Reliability 255/255, txload 1/255, rxload 1/255

I can't seem to find the meaning of the following parameters when the sh int command is performed: reliability 255/255, txload 1/255, rxload 1/255..
Can someone please shed the light on it?
Thanks.

It's kind of a rough scale of the condition of the interface.
Reliability 255/255= 100% up and reliable
128/255 = 50% up and not-so reliable
txload 1/255 = 0-4% of traffic is coming from transmitted info. 128/255 would mean 50%of traffic is coming from transmitted info.
rxload is the same as tx except it's received data.
These values are kind of a high level dashboard on what the intreface is doing in regards to traffic. EIGRP Metrics are designed to use the reliability information, but is rarely imlemented.
FROM CISCO
Reliability of the interface as a fraction of 255 (255/255 is 100 percent reliability), calculated as an exponential average over 5 minutes.
txload/rxload=Load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over 5 minutes.
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7edb.html#wp1229983

Routing loop concern

Hello all,
We have an MPLS setup with all remote sites connected to site X and site X is directly connected to site Y(datacenter). Note: site Y is not connected to MPLS cloud till now. All the traffic is passing from site X to site Y for accessing servers at datacenter. site X and site Y are connected to each other through Metro E. Now we have new circuit thats being provisioned for site Y(datacenter) that is going to be connected to MPLS cloud directly. We do bgp peering with ISP for MPLS connectivity and Internal routing protocol is Eigrp. We are doing mutual redistribution at each location for propogating routes at each site. Now the concern is when site Y is connected to MPLS and when I will do the route redistribution on site Y with MetroE connected to site X will there be a routing loop occurance or will there be a best path selection based on the metrics calculated and will choose the optimal path.
Need suggestions. Thanks in advance.

Okay no problem, it can be a little daunting when you haven't done it before :-)
1) No this isn't right.
When I refer to remote sites I mean sites other than X or Y.
So you must not allow either X or Y to redistribute any remote site networks into BGP.
There is no need because the remote site networks should never be advertised from X or Y and if you do allow it it will cause you problems.
So assuming you want X and Y to back each other up -
X redistributes it's own subnets from EIGRP into BGP and also Y's but no remote sites.
Y redistributes it's own subnets from EIGRP into BGP and also X's but again no remote sites.
If X and Y were not connected via a dedicated link this would not be an issue but because they are and they are exchanging EIGRP routes via that link they each receive EIGRP routes for the remote sites networks from each other as well as from their own MPLS router which is why you need to filter.
2) You can do the configuration on your CE routers.
MED or AS prepending are the tools you use.
So at X you advertise it's own subnets without any modification. You advertise Y's subnets but change one of the above BGP attributes.
At Y you advertise it's own subnets without any modification and X's subnets you need to modify the BGP attribute again.
This basically means that traffic will go direct to X or Y as long as their MPLS links are up.
Either should work although it may be worth having a quick chat with your provider and tell them what you are doing to make sure they are not doing anything that would override your settings.
Apart from that internally the L3 switches in X and Y should see their own MPLS routers as the best path to all remote sites because from your description the L3 switch is only one hop away from the MPLS router in X and Y whereas to go via the dedicated link would mean more hops.
I'm assuming it means more hops.
Quick way to check is do a traceroute from X L3 switch to it's MPLS router and then a traceroute from X L3 switch to Y MPLS router and hopefully there should be more hops going to Y.
Do the same from the Y L3 switch.
If it is the same number of hops then you may have to modify the EIGRP metrics.
All of the above about redistribution only applies to EIGRP to BGP.
There is nothing to do about the BGP to EIGRP redistribution.
Concentrate on the redistribution issue because that could seriously affect your network in terms of it working properly.
Regarding the second issue have a chat with your provider about the MED and AS prepending just to clear it with them.
It's not a given that traffic would go in the wrong site, it might, but it wouldn't be the end of the world if you got it wrong temporarily because traffic is doing exactly that to and from the DC at the moment ie. it goes into X and across to Y.
By all means come back if you need more help but like I say focus on the redistribution issue because that really does need addressing.
Jon

DMPVN Dual Hub Configuration

In the DMVPN design guide it is stated that in a dual hub configuration one hub should be set as the primary via EIGRP metrics. Is there a reason for this? Why can't both routes act as successors so that load-balancing can take place. The only thing I can think of is that it could cause problems with spoke-to-spoke communication.
Can someone shed some light on this?

In the DMVPN design guide it is stated that in a dual hub configuration one hub should be set as the primary via EIGRP metrics. Is there a reason for this? Why can't both routes act as successors so that load-balancing can take place. The only thing I can think of is that it could cause problems with spoke-to-spoke communication.
Can someone shed some light on this?

EIGRP Wide-metric support

It appears EIGRP only sends the classic-scale-metrics while operating in non-named configuration mode (E.G. router eigrp # ) AND Always sends the wide-metric format while operating in Named Configuration mode (E.G. router eigrp ROCKS) regardless of the 15.2 IOS version.
When my router is running in Named config mode, sh eigrp protocols reveals K6=0,
when I remove the Named config and use the legacy router eigrp # config mode, the same sh eigrp protocols does not list the K6=0 value (only K1 - K5).
The reason I ask is the Cisco white paper (EIGRP Wide Metrics) dated Nov 2012, states if a legacy EIGRP peer is interfacing with a new EIGRP peer, the new EIGRP peer will send both formats. - Is this doc outdated by a newer doc?
Thanks
Frank

Update- The original title should be referred to as EIGRP Virtual-Instance (that does support the legacy 32-bit metric and just might also support the 64-bit wide metrics; depending on your configuration).
Viewing the show command (Show command 1) based on EXAMPLE CONFIG 1 below, it's clear the K6 value is not used; only the K1 - K5 values.
If address-family vrf was implemented, as shown in EXAMPLE 2, it's clear the new wide-metric is in effect.
The question still remains, how does an EIGRP peer configured to recognize link speeds greater than 10Gbps interact with EIGRP peers that are not operating in 64-bit mode? What do the configurations look like for each of the peers?
ANYONE know?
Thanks
Frank
EXAMPLE CONFIG 1:
router eigrp TEN-GIG
address-family ipv4 unicast autonomous-system 200
topology base
exit-af-topology
network 192.168.1.1 0.0.0.255
exit-address-family
service-family ipv4 autonomous-system 200
sf-interface GigabitEthernet0/1
   authentication mode md5
   authentication key-chain MD5-PASS
exit-sf-interface
topology base
exit-sf-topology
exit-service-family
SHOW COMMAND 1:
R40#sh eigrp protocols
EIGRP-IPv4 VR(TEN-GIG) Address-Family Protocol for AS(200)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.74.10.5
Topology : 0 (base)
    Active Timer: 3 min
    Distance: internal 90 external 170
    Maximum path: 4
    Maximum hopcount 100
    Maximum metric variance 1
    Total Prefix Count: 6
    Total Redist Count: 0
EIGRP-SFv4 VR(TEN-GIG) Service-Family Protocol for AS(200)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.74.10.5
Topology : 0 (base)
    Active Timer: 3 min
    Distance: internal 90 external 170
    Maximum path: 1
    Maximum hopcount 100
    Maximum metric variance 1
    Total Prefix Count: 0
    Total Redist Count: 0
EXAMPLE 2:
R-64-bit#sh ip eigrp vrf DMZ topology 192.168.1.0 255.255.255.0
EIGRP-IPv4 VR(DMZ) Topology Entry for AS(200)/ID(10.74.10.5)
Topology(base) TID(0) VRF(DMZ)
EIGRP-IPv4(200): Topology base(0) entry for 192.168.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1310720, RIB is 10240
Descriptor Blocks:
192.168.1.1 (GigabitEthernet0/1), from 192.168.1.2, Send flag is 0x0
      Composite metric is (1310720/65536), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 10000000 picoseconds
        Reliability is 0/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

Metric mismatch in Eigrp

Please someone help me to calculate metric in Eigrp. Please find below Bandwidth and Delay.
R2#sh int s0/1
Serial0/1 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 20.1.1.2/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
CRC checking enabled
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     1183 packets input, 77832 bytes, 0 no buffer
     Received 425 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1158 packets output, 76032 bytes, 0 underruns
     0 output errors, 0 collisions, 6 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up DSR=up DTR=up RTS=up CTS=up
R2#sh ip route | in 2.2.2.0
D       2.2.2.0 [90/2297856] via 20.1.1.1, 00:59:26, Serial0/1
Metric calculation of EIGRP:
[(10,000,000 / 1544) +2000 ] * 256 =(6476+2000)*256=8476*256=2169856
This value is mismathed with EIGRP calculated metric(i.e 2297856). Please someone figerout if some thing I have missed during calculation.

HI Sanjib,
Metric = 256*[10^7/BW(min)] + [sum of delay]/10
Metric = 256*[10^7/1544] + (20000+5000)/10]
Metric = 256*[6476+2500]
Metric = 2297856
We see the minumum bandwidth to reach the destination is 1544Kbps
Default delay on the link to reach the destination (serial link) is 20000 microseconds.
Default delay of the loopback interface is 5000 microseconds.
Regards
Dont forget to rate helpful posts.

Metrics when redistributing a static default route into EIGRP?

I saw a network working with EIGRP and resdistributing a static default route into it. I did not find the "default metrics" to redistribute into EIGRP but the static default route works and is redistributed. My understanding was that everytime you redistribute into EIGRP you needed to specify the metrics. How come this network is working? Can someone explain or point to a cisco document what explains it?
Sample of the config:
router eigrp 1
redistribute static
no autosummary
network Y.Y.Y.Y
ip route 0.0.0.0 0.0.0.0 X.X.X.X
Thank you,

It's just one of those specific things about EIGRP and IOS, maybe a design choice. If they do use the interface as the seed metric then that would help explain why it's that way.
Weirdly if you are using EIGRP VRF address family configuration on IOS and you redistribute statics you do need a metric.
And I believe NXOS running on Nexus switches also needs a metric defined.
Just one of those things you have to remember but it would be good if it was consistent.
Jon

EIGRP MTU Size Causing Neighbor Flap - Pls help!

I've been reading the post here which is quite good but, I have some outstanding questions I hope someone can help me with?
https://learningnetwork.cisco.com/thread/43100#233367
Essentially, we have a DCI which is an evpl link - layer 2. The evpl connection is terminated with a Cisco 3925 at each location (once it comes out of the provider's Ciena box). It is a dot1g tagged trunk - L2 connection. We are running EIGRP between the two. Before setting up OTV, all link sizes were 1500 MTU...which obviously will not work with OTV....and it didnt!. OTV is running on 7Ks a few hops away from each 3925. So, I went on each and every link - (pain stakingly) and configured MTU size for 9216 - enabling jumboframes at the system level too where applicable. What do you know, OTV started working and i could ping to at least up to 2000 bytes with DF-bit set too! (I didn't try any higher).
Last night, our provider did some 'maintenance' without telling us - which brought the link down. The link was 'down' even after the maintenace was completed. After looking in the logs and seeing this, I suspected it had to do with MTU sizes after quickly googling around.
May 13 12:33:13.698: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
May 13 12:33:13.976: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
May 13 12:33:24.266: %SYS-5-CONFIG_I: Configured from console by izzi on vty0 (10.241.6.12)
May 13 12:34:00.286: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
May 13 12:34:00.616: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
May 13 12:34:46.922: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
May 13 12:34:47.280: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
May 13 12:35:37.364: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: holding time expired
May 13 12:37:29.725: %SYS-5-CONFIG_I: Configured from console by izzi on vty0 (10.241.6.12)
May 13 12:37:47.430: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
May 13 12:39:01.508: %SYS-5-CONFIG_I: Configured from console by izzi on vty0 (10.241.6.12)
May 13 12:39:11.943: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
May 13 12:39:13.973: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
So, I reduced the MTU size back to 1500 and low and behold, adjacency stayed. Let me also say that there weren't any errors on the links too. So, I decided to try and increase the MTU back up to 9216 - OTV started working again and adjancey held - it didnt flap. I thought for a second and decided to bounce the link. Once i did this, EIGRP started flapping again with the same exact behavior. After calling the provider, they claim that their max MTU is only 1522 for our EVPL link. I don't see this being possible since I was able to ping DF-BIT set way above 1522. Maybe I'm missing something. We are going to coordinate with them to increase the MTU size on the link. But why/how did it work to begin with - especially since OTV doesn't support fragmenation....I understand that OTV adjacency can still form since ISIS only needs 14xx something...but I wasn't able to get certain protocals/services like esxi host management to work via OTV until i increased MTU size.
Also, after reading the above article it sounds like EIGRP will 'peer' or decide on MTU of it's update packets? If that's the case, maybe the bouncing of the link allowed EIGRP to negotiate it's packet sizes to above 1500 and that's why if I change the MTU size to above 1500 everything works fine - OTV/2000 byte bf-bit set ping, until I bounce the link? If this is the case, is there anyway to 'force' EIGRP to use 1500 for it's packets for its protocol traffic and allow everything else to use the MTU set on the link?
I would appreciate any help explaining this - hopefully you're not as confused as I was after reading it again!

Did you ever find the root cause and this solution for this? We are experiencing the same issues with our 2 4500 Catalyst and a couple of routers on our inter routing VLAN that we use for only the 2 chassis and a couple of router. MTU is already set at 1500 on the 2 chassis.
005326: Jan 19 11:30:02: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is down: Peer goodbye received
005327: Jan 19 11:30:05: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.1 (Vlan990) is up: new adjacency
005328: Jan 19 11:30:05: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is up: new adjacency
005329: Jan 19 11:30:07: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.12 (Vlan990) is down: holding time expired
005330: Jan 19 11:30:27: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is down: Peer goodbye received
005331: Jan 19 11:30:28: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.11 (Vlan990) is down: Peer goodbye received
005332: Jan 19 11:30:28: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.1 (Vlan990) is down: Peer goodbye received
005333: Jan 19 11:30:30: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.12 (Vlan990) is up: new adjacency
005334: Jan 19 11:30:30: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.11 (Vlan990) is up: new adjacency
005335: Jan 19 11:30:30: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.1 (Vlan990) is up: new adjacency
005336: Jan 19 11:30:32: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is up: new adjacency

DMVPN With EIGRP - MTU adaptation

Hi all,
I am managing a Hub and Spoke network with more than 1000 Spokes. The initial MTU of the tunnel interface we've configured is 1400 (on both hubs and Spokes).
I am facing now some issue with customers that have a WAN line with a lower MTU: ping [tunnel_IP] size 1400 doesn't give any reply.
The problem is that:Two routers with MTU of 1400, but in the path between them there is apparently a hop with a smaller MTU. Hello and neighbor-ship is working (I assume that Hello are smaller than 1400)
Route from Spoke are received on Hub (displayed in sh ip route ei) but the route from Hubs are not received by the Spoke. I assume that's due to the fact that there are not a lot of route advertised by the spoke (so packet size lower) and more advertised by the hub reaching MTU size....
I did some tests with these customer Spokes connecting them to another hub router used for R&D, adapting the MTU on both size to a lower value: working !
I have now 2 solutions
- Ask all my concerned customers to contact their ISP to check if they can increase MTU or find another gateway for my router... Most of my customer doesn't have any IT people and won't understand at all what I want...
- Modify MTU on my router: modify in on the Spoke... but do I need to reconfigure it on the hub to avoid neighbor flapping... So I need to reconfigure all my 1000+ Spokes
So my question is: is there a way to adapt MTU size of the tunnel interface depending on the destination.
I tried to find a solution like a route map that will modify MTU when matching an ACL that contains my impacted Spokes but it's not possible to adapt MTU with a set in a route-map...
Any idea on your side ? workaround ?
Best regards !

Great! I got this working. Not sure what the issue was. The thing is, I was using GNS3 and I had a router with a switch card acting as both SP clouds. When I tried configuring the route tracking, it wasn't behaving. I since switched it from the router-switch to a router connected to 2 of the dumb switches and route tracking started behaving properly. The failover and everything works perfectly now.
I also cleaned up some of the tunnel config so I don't know if that's actually what fixed it.
One more question though. I just discovered that the customer has no data license so there's no clean automatic failover using floating static routes. Can I get this clean failover using VRFs without route tracking or will I still need it?

MTU in EIGRP metric?

Similar Messages

Maybe you are looking for