Lots of background as to why, but simple question.... during simple lab testing I didn't see any problems, but I don't fully understand all of the considerations involved.
Question: What mechanism protects against "route oscillation" in the configuration example below?
B) the lab did not have the full table; in the real-world, could this be more problematic?
C) would adding a third transit provider (ISP 3) in the mix change the behavior?
# LAB CONFIG
Lab, 3 routers (I will install a 4th, as I am curious)...
router 1: "customer" AS65099
router 2: "ISP 1" AS65001
router 3: "ISP 2" AS65002
The ISP routers simulate Tier 1 transit providers, where they set LP86 for other peers, and 100 for customers.
If I send a BGP community to both ISP's to set LP80, I was expecting some instability. I didn't see it, just a race condition in whichever AS sent the route to the other first won. That part makes sense (I understand loop prevention based on AS path), mostly... even though the BGP neighbors came up about 500ms apart, what stopped both from sending their learnt route from AS65099 to the other peers, which they see as LP86 - causing each to install that, causing an update of the prefix with AS path change (they see the loop, drop that update) ... and a repeat - the oscillation I thought may happen?
Maybe something like this did happen... I didn't (yet) do a debug of the exchange... but when both were set to LP80, the losing (ISP) router appeared to take a lot longer to install the route than if both were default LP (no BGP community to set LP80). Is there some backoff timer involved?
Could I create instability with aggressive timers? (modify update, delay, restart, suppress timers?)
Maybe this question ... I always wanted to know, how granular are the BGP route age timer?
... how many bits, is it to the second? (I ask because it's before lowest router ID and lowest IP of neighbor tie-breakers ... so... because I've seen lowest IP win, that means the timer was "the same"?)
## Excessive background (context) ...
Coming from a provider background, I normally preferred using LP (local-pref), and not AS prepend. But for my needs here, I am thinking of only doing AS prepend, using 2x prepend on the backup paths. Is there anything I should look for with this config (traffic not taking the intended path)?
Our company had a /20 allocation. We sold half of the business, and based on how the IP's were utilized, the equipment sold, etc... we split the IP space 50/50, using even and odds... yeah, I know... a mess, and not helping the global table in any way. We used to advertise a /23 (or two) per metro (we had 6 metros). But now all we have are /24's, and 3 metro's. The old model was very simple... /20 over all transit links, and /23 (more specific) over the local metro we preferred.
I think the new model will just be /24 as normal in preferred metro, and prepend 2x (or 3x, if we find we need it -- some people seem to like to prepend) in all other sites.
