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!
