[c-nsp] Dot1q Interface detect switchport failure

[Matthew Crocker]

Rodney,

  Thanks for passing on the info.   We use a Seranoa IPeX WANPort to 
terminate our DS-1 circuits from customers.  The Seranoa maps the HDLC 
frames to dot1q frames and sends them out a gigE port.  We use a 3550 
with a bunch of interface vlans to terminate the IP packets from the 
customer.  This setup works great with the only major problem being the 
3550 can't see the DS-1 and therefore doesn't know when the DS-1 is 
down.   We also provide DSL backup to our DS-1 customers.  We use a 
Cisco 1721 to  terminate the DS-1 & DSL (PPPoE) sessions at the 
customer end.  Customers that have DS-1 & DSL are mapped to a 7513 so 
we can use rtr/SSA to manage their routes.  It works like a charm.  rtr 
saves us from running OSPF with all of our customers.

Again,  thanks for the info,  eventually I'll have enough customers to 
melt the 3550 and will upgrade to a 7609 or 12k

-Matt


On Sep 1, 2004, at 5:57 PM, Rodney Dunn wrote:

> Matt,
>
> Sorry but I don't know the answer to that.
> I'm guessing it will be when the full rtr/SSA
> support is in a 12.2S based branch of code that
> the 3550 ships from.
>
> I'll pass the feedback along and let them know
> someone asked about the support though.
>
> This is an interesting feature that was just targeted
> towards dial backup and it's turned out to be used
> in a lot more scenarios than I imagined.
>
> Rodney
>
> On Wed, Sep 01, 2004 at 11:14:23AM -0400, Matthew Crocker wrote:
>>
>> Rodney,
>>
>>   We do the Object tracking stuff with our 7513,  works great.  We 
>> setup
>> an RTR to ping the customer IP and a task tied to the rtr to drop the
>> static route.  Our customers have DSL as backup which is announced via
>> OSPF.     Do you know when the full rtr command set will be supported
>> on the 3550 series?   Right now I can configure the rtr but I can't
>> configure the task.   We have the EMI feature set (I think).
>>
>> Thanks
>>
>> -Matt
>>
>> On Sep 1, 2004, at 9:24 AM, Rodney Dunn wrote:
>>
>>> The problem he is trying to solve is to know when the
>>> next hop is actually down.
>>>
>>> We developed something called object tracking and
>>> started hooking other protocols in to it.
>>> ie: PBR, static routes, etc.
>>> One of the main goals was to solve the DSL dial backup
>>> problem.  Since then it's been used in a lot of corner
>>> case scenarios.
>>>
>>> Go to CCO and search on "object tracking static route".
>>>
>>> http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5413/
>>> products_feature_guide09186a00801d862d.html
>>>
>>> It hasn't been ported to a code train that runs on the
>>> 76xx.  The feature was developed originally for lowend
>>> systems.
>>>
>>> There is no other way than a routing protocol to accomplish
>>> what you need.
>>>
>>> You would write an offline script that does it for you.
>>> Every 30 seconds telnet in and ping the next hop.
>>> If the next hop doesn't respond add the backup route.
>>> Repeat it and when the next hop comes back add the
>>> route back.
>>>
>>> Rodney
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Aug 31, 2004 at 09:56:40PM -0400, James Hampton wrote:
>>>> Try using a floating static route, basically you have two static
>>>> routes, one of them gets a slightly higher administrative distance
>>>> than the other. When the first route is not reachable and dropped 
>>>> from
>>>> the table, the second one, with the lower A.D. takes over.
>>>>
>>>> James
>>>>
>>>> On Wed, 1 Sep 2004 01:54:47 +0800, Tay Chee Yong 
>>>> <tcy at pacific.net.sg>
>>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> I have a 7600 connecting to a Catalyst 3550, via a GE Trunk.
>>>>>
>>>>> As i know that the sub-interface on any router will always be up,
>>>>> irregardless of the port status on the switch. I would like to find
>>>>> out if the dot1q interface on a 7600 is capable of detecting an
>>>>> outage on the switchport of the catalyst 3550, as i need fullfill
>>>>> some kind of backup routing using static routing, so that when the
>>>>> FE port on the switch is down, the router is capable of re-routing
>>>>> traffic to a secondary link. BGP is not an option here. My scenario
>>>>> doesn't allow me to connect the FE directly to the router also, due
>>>>> to the network setup.
>>>>>
>>>>> Any advise is greatly appreciated.
>>>>>
>>>>> Regards,
>>>>> Cheeyong
>>>>> _______________________________________________
>>>>> 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/
>>>
>