[nsp] always-compare-med

Kostas Anagnopoulos kostas.anagnopoulos at oteglobe.net
Tue Feb 18 16:35:45 EST 2003


Hi Dave,

Check the new bgp cost community feature.Perhaps it suits to your case.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guid
e09186a008012ee22.html

Regards
Kostas



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Dave Wilson
Sent: Tuesday, February 18, 2003 12:27 PM
To: cisco-nsp at puck.nether.net
Subject: [nsp] always-compare-med


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?

Thanks,
Dave

--
Native IPv6 peers: Internet 2 ---------------------------------------------
Native IPv6 customers: TCD                            dave.wilson at heanet.ie
Native IPv6 PoPs: Dublin, Citywest                    tel:  +353-1-660-9040
Tunnels: Géant, SURFnet, Esat, Eircom, UUnet          fax:  +353-1-660-3666

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list