[nsp] always-compare-med

Danny McPherson danny at tcb.net
Tue Feb 18 13:57:22 EST 2003


So long as you're setting MED explicitly on ingress for ALL
EBGP peers then you should be OK enabling always-compare-med. 

Alternatively, you could probably even munge Origin Code or 
the like to do this.

I wouldn't recommend the cost community stuff unless you really 
need it.  Of course, it can help fix things like route oscillation
or Route Reflection induced forwarding loops, etc..

-danny

> We're deploying a backup transit service from one of our upstreams, and we 
> hit an unexpected issue when trying to use MEDs to choose between the paths.
> 
> We have two STM-16 links (capped to STM-4) to upstream A, and a single STM-1 
> to upstream B. We only want one of the links to A in use at any time, but 
> we'd like to take advantage of B throughout. Inbound traffic is not a problem.
> 
> For outbound traffic, we apply identical localpreferences to prefixes 
> received from each link, allow AS path length to take its course (which 
> distributes traffic evenly between A and B), and set metrics on the prefixes 
> we receive from A - 0 on the primary link, and 40 on the backup. However, 
> this last step doesn't work, because each prefix is also received via B.
> 
> According to the best path selection algorithm, the comparison of MEDs is 
> ignored in this circumstance. It looks like we have to turn on 
> always-compare-med. As far as I can tell, this won't significantly affect 
> traffic to our other peers, because localpref and AS path length are 
> evaluated before MEDs are used. Do others on this list use it, and has it 
> caused problems?
> 
> Also, is there another way to implement the above? It doesn't suffice to 
> give ISP B a lower localpref, because its line would remain empty except 
> during an outage. We can't give the backup line to A a lower localpref, 
> because during failure of the primary line, all traffic would divert to B 
> (which is much lower bandwidth). I've thought about doing as-path stuffing 
> on *received* routes. It works in the test lab, but is it against the rules 
> in real life?




More information about the cisco-nsp mailing list