[c-nsp] Reliable static routes and 12.2S

[Andre Beck]

Hi Saku,

On Tue, Dec 21, 2004 at 03:05:23PM +0200, Saku Ytti wrote:
> On (2004-12-21 09:48 +0100), cisco-nsp at ibh.net wrote:
> 
> (private reply for email in cisco-nsp mailing list)

I'd allowed myself to Cc that back to the list as the explanation
below might help others  understand why OAM is no option for me.
Hope that's Ok.

> > the 12.3T train finally got a long missed feature: static routes that
> > go down when a track object (for instance a SAA ping) goes down. That
> > makes life a lot easier on RBE CPEs when it comes to establishing some
> > kind of backup (typically dial backup).
> 
>  What kind of RBE setup do you mean,

The one where the ISP's ATM PVC is terminated by a CPE DSL "Modem"
which actually is a ATM SNAP to Ethernet Bridge. That modem is supplied
by the carrier and cannot be managed (by a third party). We use RBE to
connect a 1712 or thelike to the modem's Ethernet and route over that
bridged link using a transit net.

> you should be able to run OAM cells
> on point-to-point PVC and it will go down when OAM cells go down.

We are doing that of course, but in the above situation, it will
only sense failure of the ATM end 2 end VC, which ends at the
carrier modem. If the link to the CPE router fails, this is likely
to be unsensed at the CO (the PVC will stay up and will get OAMs
reflected) and may be unsensed at the CPE (depends on whether the
link goes down or not, question of how the modem is actually
connected).

I'd rather use a router that terminates the DSL either directly or
via ATM25, we have used both a lot with ADSL and the 1401 or 826
series. In these setups, OAM is end to end and completely sufficient
and RBE is superfluous as well (we use point to point routing over
"aal5mux ip" there, also saves us from SNAP overhead).

But we now deploy SDSL and neither does Cisco have a CPE device for
that (no, it's not G.SHDSL) nor is the carrier willing to provide it
by means of ATM25 (even though they install modems which could). We
are required to use the Ethernet termination, which forces us to
RBE, SNAP and kills OAMs end to end use. Thus my begging for SAA
tracked routes...

>  Having said that, I do fully agree with you that SAA tracked static
> routes are nice thing, I just see the benefits somewhere else.

Well, supervising reachability on top of VPNs and PPPoE clouds is
the real intention, but in practice, every simple Ethernet broadcast
domain with a gateway in there is able to blackhole you. I'd rather
like an alternate style of L2 reachability supervision on top of
Ethernet, a special non-ARP point to point over Ethernet that
constantly watches the availability of the peer MAC and would let
the interface go line protocol down if it cannot be established. But
there is no such thing that I knew of, so rtr/track is the next best
solution, even if it involves ugly policy routing.

Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-