Showing results for 
Search instead for 
Did you mean: 

Dial backup for an ethernet trunk


We would like to implement an ISDN backup for an ethernet trunk (1 Gigabit) between two buildings, sharing several VLANs.

Apart from performance issues (1 Gigabit versus n*B ISDN channels) what is the best option and its requirements? L2TP between routers?

Thanks in advanced


Re: Dial backup for an ethernet trunk

Why do you want to implement a dial backup? Do you have resource limitations in getting a second fiber link through a diverse path between the buildings? I think a little more details on your setup will help us propose a better option. Also are your routers layer 2/3 switches or are you using pure routers?

Not applicable

Re: Dial backup for an ethernet trunk

The two buildings are separated about 20 kms. so we use a carrier fiber link. Considering a second fiber link using a redundancy path means a very expensive solution.

Regarding more details: we use L2&L3 switches (basically 2950 and 3550) but in both sites we have pure routers (2600 and 3620) for other purposes both of them with a primary ISDN (30 channels B)


Re: Dial backup for an ethernet trunk

Let me try to understand your situation a little better. You have a gigabit ethernet trunk between the two sites and in each site there is a router connected to the switch that terminates this gigabit ethernet connection between the sites? What you want to be able to do is to have have the ISDN link come up when the trunk fails and you want to be able to have the same VLAN extension over ISDN backup?

Not applicable

Re: Dial backup for an ethernet trunk

You are right:

- the gigabit link is terminated in L2 switches.

- I have a router in each site.

- I don't mind about an automatic backup or a manual process.

- There are some VLANs with ports in both sites. For example, some servers having a production interface and sharing an internal VLAN (in a different interface). These servers need connectivity in the internal VLAN between them to continue accepting connections in their production interface.

Any suggestion?


Re: Dial backup for an ethernet trunk

From your description, I assume the link between the two buildings is bridged rather than routed. While it is possible to set up dial backup for a bridged link, it is much more difficult (you either have to use integrated routing and bridging, and find some protocal which supports dial on demand routing to route across the link, or use SAA object tracking to detect link down). Realistically, once you get a dial backup link up, it will be an exercise in frustration if you actually plan to bridge production traffice over the dial backup link.

If you are routing across the link rather than bridging, your options are expanded and your chances of success are reasonable despite the vast disparity in bandwidth. A standard frame relay design using dialer watch or DDR would work fine as neither requires the Interface being backed up to go down at the link layer.

A routed connection does not need to support all the background noise broadcasts which are common on large LANs, and could even be filtered to only support the critical applications, allowing you to survive until the primary link returns, even if people can't surf the auction sites over lunch.

Good luck and have fun!

Vincent C Jones

Not applicable

Re: Dial backup for an ethernet trunk

Yes, tke link is bridged.

I am sure a routed connection will made it easier but the question is that we share VLANs in both sites so we have to discard this kind of solution, don't we?




Re: Dial backup for an ethernet trunk

I agree with Jones that a routed connection would have made things much simpler. A backup bridged or L2TPv3 encapsulated solution can be provided but since your primary link is a Gigabit trunk you will have to be very careful as to what you encapsulate or bridge and what you do not. The whole backup process can be automated using dialer watches specifically setup for this purpose by running L3 between the sites on a separate VLAN. I am just trying to imagine this solution working but trust me you will need a lot of testing before you deploy it. If the services are very critical i will still suggest convincing your management to opt for a diverse fiber route.

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards