What I didn't expect was that the router continued to use the paths with the MED value of "4294967295" for a full 30 minutes before changing to paths which had lower MED values.
Q: Any idea which timer within BGP is responsible for this behavior?
This is in a lab environment which physical hardware, running c2800nm-adventerprisek9-mz.151-4.M7
R1 (AS100) - R2 (AS200)
R4 (AS400) - R3 (AS300)
Thanks for your help!
did 'show ip bgp' still show the paths with MED '4294967295' as the best ones until those 30 minutes passed?
If you issue "clear ip bgp * soft" on R1 after 'bgp bestpath med missing-as-worst' applied, does it still take 30 minutes to move to the paths with lower MED?
Yes, 'show ip bgp' continued to show the paths with the MED of '4294967295' as the best until the 30 minutes passed.
Soft clears (in and out) on R1 as well as it's peers (R2 and R4) didn't have any effect.
Only a hard reset via "clear ip bgp *" causes R1 to choose paths with a lower MED after the peerings re-established.
Yes all four routers in the topology support it and I tried it on R1 and its neighbors: R2 and R4.
IOS on the devices: c2800nm-adventerprisek9-mz.151-4.M7
Please review this excellent documentation on BGP convergence and it scanner process - Here
Try enabling bgp always-compare-med also and as suggested perform a soft reset
I will revisit the scenario and will report back.(soft resets on R1 and its peers without the "bgp always-compare-med" had no effect)
My main interest though is in which timer is at play here, possible that this can only be answered by a Cisco employee familiar with the inner workings of the IOS as I haven't been able to find any BGP related timer with a default value of 30 minutes/1800 seconds so far.
It might even be IOS version dependent. (will explore that as well)