Can you have failover to ISDN in a bridging environment with a standalone ISDN box?

Consider this a question from a non-expert. Consider too that it may
be nearly idiotic. I am bridging from one office to another over 256K
synch into a multiplexer which then handles the comms up to the other
office. There is currently no backup. Changing from bridging to
routing would be a Big Deal because there are devices around the world
talking to my device with its present IP, so we don't want to upset
that.

I want to add ISDN backup, but I don't want to use ISDN in the bridge
(Cisco in bridging mode) because if the bridge dies completely, so
would the ISDN module and thus so would the backup. So, I would like
to have a standalone Cisco 801 ethernet ISDN unit to do this.

A single pc on my end uses ftp over the bridge to a specific address
on the destination end. In the back of my mind, I'm thinking there is
some kind of way to do this by manipulating the routing table on the
PC and messing with the metric value, but on the otherhand, I'm
thinking this may not be possible.

What I need is for the PC to realize that when it cannot get to the
ftp destination via the normal bridge, it will then go to the ISDN
bridge. Could this be done by messing with the bridge learning table
in the ISDN bridge and telling it there's a higher cost "route"
available? As I said, I'm not an expert, and this really does strike
me as not doable. Let me know, please what you think.

-Bob

 

I think it's a bad idea, but with enough effort, you should be able to
get it to work. Whether you could get it to work well enough to meet
your needs is another story. One approach would be to pick a routable
protocol which you do not need to bridge (such as IPX), and use it to
control up/down of the backup link. Spanning tree would then ensure
that only one or the other link is used at any one time for bridging.

Aside from the ugliness of the "solution" it could easily take one to
two minutes for a failure to be detected and the alternate link to
start carrying traffic. Plus what kind of performance to you expect
to get from a single B channel backup? Bridging is typically only
marginally useful with a full 256K.

Good luck and have fun!

 

Thanks, Vincent. I had my suspicions about my idea... but I still
wonder if there isn't some way to do this. If you're right about the
delay to come up and the other points, then I'll just have to go back
to the idea of having isdn in the router (bridge) do the the backup
and use a cold standby in case of hardware failure. Although I didn't
say it, I did mean for it to be 128k on the backup.

-B

 

Theoretically, there should not be any problem. You just place the
new bridges there, make sure the connection works, and STP is sorting
out the rest.

Practically, this is only useful in certain environments, as the ISDN
line would stay up all the time (STP hellos every two seconds, full
traffic flooding in one direction). So if the ISDN comes from an internal
PBX and doesn't cost you money, use that concept. Else we would need some
mechanism that keeps the remote bridge down as long as it is not needed.

Again in theory, this could be easily achieved: The 801s would see the
current topology as established by STP and could just freeze the dial
connection, spoofing STP. If they sense any change to the topology through
their ethernets, they would again dial into the remote side and run STP
until it has converged again. This is exactly the same thing as
"ip ospf demand-circuit", just on a spanning tree one layer down.
The problem is, I don't know whether you can do this with Ciscos, and
to be honest, I doubt it.

Bridges sort that out themselves using STP. That's how they work, and
you probably don't want to mess with that.

STP actually does establish path costs and this way, it decides
what port has to go blocking in order to prevent a loop. But such
port is not actually inactive, it just *ignores* packets it receives,
and it transmits nothing but BPDUs. STP doesn't disable a link, it
disables just the port at one side of the link. Now the remote bridge
consists of two half bridges and I'm not entirely sure how that makes
things different - but I expect it to be a challenge to get that ISDN
connection down during normal operation. Except if Cisco would have
something like the "STP spoofing" described above...