[c-nsp] mpls-te - dynamic latency?
Oliver Boehmer (oboehmer)
oboehmer at cisco.com
Thu Apr 6 11:26:14 EDT 2006
christian.macnevin at uk.bnpparibas.com
<mailto:christian.macnevin at uk.bnpparibas.com> wrote on Thursday, April
06, 2006 12:22 PM:
> Not dealt with african providers before have you? :) Unfortunately,
> VSAT is a fact of life for many, and the shortage
> of fat pipes in the big continent requires live/live configs. Much as
> I hated it at first, we gotta move on and find a way.
I know, I know, hence the ";-)" behind my comment..
> I've been looking at the MTR stuff, and frankly it looks like a dream
> come true. Chetan tells me we're looking at 2007 for
> the first release though, so we're going to need some black magic in
> the meantime.
sounds about right, and you need this on all platforms involved..
> Incidentally, I'd recommend a few
> people take a look at this, because others must be suffering some of
> the same pain we are, and if this looks like a solution
> to others as well, it'd be good if Cisco realised customers had
> interest in the availability of application-layer routing
> capabilities without the evil.
Ack, and this is where MFR could fit in (as far as I understood, don't
know too much about MTR)..
> Looking at OER, it seems like it'll still only work on destination
> prefix - ie: no layer 4 awareness. Not true?
Right, OER modifies the RIB, hence it operates on L3.
The question is whether you have any option moving this from L4 to L3 by
using distinct prefixes/addresses for your sensitive traffic. Then you
can use routing mechanisms to steer the traffic either way (I think I
made an error mentioning PBR with TE on a PE, don't think this will
work).
PE-PE TE tunnels with a modification of the BGP next-hop could do the
trick here. As a rough idea:
- create a new loopback address on each PE
- Full mesh of PE-PE TE-Tunnels with two path-options: #1 goes via
explit-path along the low-delay links, #2 uses any path in case #1 is
not available. no autoroute, no FA, enable LDP on the tunnel
- statically route the loopback to the tunnel
- set the BGP next-hop for the "voice" BGP prefixes to the new loopback
routed via the Tunnel. you could do this next-hop rewrite based on acl,
community, etc.. it could get more complicated if you have multi-homed
sites (you do) and you are using RRs as the new next-hop obviously
depends on which remote PE advertised the prefix..
oli
More information about the cisco-nsp
mailing list