[c-nsp] backup quandry

Sam Stickland sam_ml at spacething.org
Thu Oct 21 07:34:08 EDT 2004



On Wed, 20 Oct 2004, Charles Sprickman wrote:

> On Wed, 20 Oct 2004, Josh Duffek wrote:
>
>> http://www.cisco.com/en/US/customer/tech/tk364/tk871/technologies_config
>> uration_example09186a0080211f5c.shtml
>
> That looks interesting, but I won't be going to 12.3 anytime soon on our
> side...

It's in 12.3(4)T and 12.2(25)S

Sam

>>> -----Original Message-----
>>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>>> bounces at puck.nether.net] On Behalf Of Charles Sprickman
>>> Sent: Wednesday, October 20, 2004 3:49 PM
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] backup quandry
>>>
>>> Hello,
>>>
>>> I've been trying to come up with a decent plan to offer backup
>> circuits to
>>> customers that works well.  We have something of an odd environment
>> here
>>> and most of the solutions I've run through fall short in one way or
>>> another.
>>>
>>> This is a cheap-o backup solution.  The scenario is that the client
>> has a
>>> Covad "Telextend" T1 with the backup line being a Covad SDSL.  I'm
>> aware
>>> that this offers no protection against Covad going wonky.  We
>> generally
>>> see that most of our client outages are due to Verizon mucking about
>> with
>>> things, so it actually works quite well.
>>>
>>> On the client side we're using Netopia gear and it handles cutting
>> over
>>> the outbound traffic well.
>>>
>>> To handle routing the client LAN block to SDSL and ADSL circuits, I
>> enable
>>> OAM management on the pvcs and add two static routes to the interfaces
>>> (one with lower priority).  If one of the circuits fails, the route to
>>> that pvc gets yanked as OAM lets us get interface up/down status.
>>>
>>> The problem is with the "T1" circuits.  Covad brings these into T1
>> cards
>>> in their DSLAMs and the does a frame<->ATM translation there.  Sadly
>> they
>>> don't configure the DSLAM to handle any of the ATM OAM stuff for these
>>> circuits, so from my router I have no way of getting the status of the
>> T1
>>> circuit.
>>>
>>> First off, any suggestions for the above scenario?  I need some way to
>>> determine if the T1 is up or not, but since it's a virtual circuit and
>>> Covad does not support the standard signalling, I don't think there's
>>> anything I can do there.
>>>
>>> Second question, Covad has recently approved the Cisco 17xx series
>> routers
>>> for the Telextend service.  With one of those in place, I could run
>> OSPF
>>> over the T1 and put the SDSL router in bridge mode and also run OSPF
>> over
>>> that link.  The only problem there is that the T1 is a 1.5 Mb/s line
>> and
>>> the SDSL backup link is generally going to be a lower speed link so I
>>> don't want to "balance" the two lines, I want the SDSL to only be used
>> if
>>> the T1 is down.  What other options am I missing to make this happen?
>> I'm
>>> open to all sorts of nutty hackish ideas...
>>>
>>> Thanks,
>>>
>>> Charles
>>>
>>> --
>>> Charles Sprickman
>>> spork at inch.com
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list