Hi, I'm currently considering options to better monitor the MPLS bits of our network - specifically, make sure that MPLS *forwarding* works, without having to rely on end systems noticing EoMPLS links going "black hole" or L3 VRFs going down.
One of the reasons for MPLS forwarding to break could be "ethernet circuit
bought from $3rd_party, their equipment failing to properly forward all
different ethernet types -> IPv4 works, MPLS fails" - happened to a colleague
recently, which got me thinking...
The way I thought this could be done is to setup a MPLS tunnel with a
static path, crossing all "major" links (this is a small network, so the
tunnel just needs to go through 6 routers or so to visit all backbone
MPLS links), and then send ping probes down that tunnel. MPLS forwarding
breaks -> ping breaks -> operator goes investigating.
Now, the documentation that I found ties this to
"tunnel mode mpls traffic-eng"
and *this* seems to require OSPF or ISIS being used as an IGP - which
we don't have, right now.
(Platform is 6500/Sup720, IOS 12.2SXH/SXI)
So, Question #1:
- is there a way to setup a static MPLS tunnel/LSP "take *this* link and
then *that* link and then go *there*" without OSPF or ISIS?
Question #2:
- what is happening "behind the scenes" to make static(!) paths require
OSPF / ISIS? I can understand that auto-te needs the necessary metrics,
but "basic MPLS" works fine with just BGP/LDP/EIGRP...
(And yes, I could move everything over to OSPF, it's just that I want
to understand the reasons for it)
thanks,
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgpe3XDc2kcqA.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
