Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

redundancy and load balancing between catalyst 3524-XL and catalyst 3548-XL

0 views
Skip to first unread message

jan.p...@gmail.com

unread,
May 12, 2008, 11:44:13 AM5/12/08
to
the current situation is that we have 2 sites connected with 2
microwave links. the links are of different brand and can not be
redundant by them self. if one link fails i am currently shutting down
that interface and bring up the interface for the spare link on the
catalyst. here the current interface config:

3548-XL
interface FastEthernet0/43
description ll02
duplex full
speed 100
switchport trunk encapsulation dot1q
switchport mode trunk
........
interface FastEthernet0/48
description ll01
shutdown
duplex full
speed 100
switchport trunk encapsulation dot1q
switchport mode trunk

and the other side the 3524-XL
interface FastEthernet0/19
description ll02
duplex full
speed 100
switchport trunk encapsulation dot1q
switchport mode trunk
........
interface FastEthernet0/23
description ll01
duplex full
speed 100
switchport trunk encapsulation dot1q
switchport mode trunk

fe0/43 - fe0/19 are one link and fe0/48 - fe0/23 are one link.

i have read about port group and have tried to configure that today, i
can issue the commands and the config does show the ports in the port
group but i cant pass any traffic. i had all 4 interfaces in port
group 1. is port group the wrong thing to do for what i try to
achieve ?

any advice is very welcome.

regards
Jan

Trendkill

unread,
May 13, 2008, 2:13:27 PM5/13/08
to

Do you have to trunk? Why not turn up a diff subnet on the remote
side and turn up layer 3 routing between sites via both links? If one
drops, routing will failover to the second link since the adjacency
will drop. If you can't do this, I'm not sure why a link failure
wouldn't failover with your configuration anyway. If you have two
trunks, only one is being used at any given time (to avoid a loop),
and if it fails, spanning-tree should run and it should go forwarding
on the other trunk. What am I missing?

Trendkill

unread,
May 13, 2008, 2:16:04 PM5/13/08
to

If you want to load share, and presuming both links are equal
bandwidth and go between the same two switches, have you tried
etherchannel? If its just a layer 2 connection at each switch, they
most likely have no idea that there is a microwave between them, and
etherchannel would allow both ports to belong in the same channel
unless one went down. Else the layer 3 suggestion from my previous
post will work fine, as long as both links are equal bandwidth, any
decent routing protocol should load share the paths presuming its the
same end points on both sides.

jan.p...@gmail.com

unread,
May 14, 2008, 2:18:52 AM5/14/08
to
routing is not possible, for "historic" reasons i have to stick to the
current setup. the microwave links behaving transparent to the
switches and the switches "believe" there is a cable between them. yes
both links have the same capabilities, 34mbit/s. i had tried just to
enable all for interfaces and leave spanning tree do the job. i
noticed it takes about 5 minutes for traffic to pass if the currently
active link fails. so i was looking for something which will fail over
within seconds. i believe port group is etherchannel on cisco
switches, if not please elaborate, i try in the meanwhile to find some
documentation on the web.

thanks to both of you.

Jan

Bo...@hotmail.co.uk

unread,
May 14, 2008, 3:47:58 AM5/14/08
to

I think that the key here is 'how realistic a wire
does the microwave link provide'.

If it really does look like a wire to the switch and
the port goes DOWN iif the link does then I think
that you could use etherchannel. This uses
port groups in its confguration statements.

If on the other hand it is not such a good simulation
of a wire you will I think have to use Spanning tree.
You can do a form of load balancing with STP if you have
more than one VLAN in use by having some VLANS use
one link by preference and some VLANs using the other.

By defaut STP takes 30 (35?) seconds I seem to recall
to transition to forwarding in the event of a link failure
in your topology. Thre is now RSTP but maybe
your old switched do not do it.

The timers are tunable to make convergence faster.
Thing is you say that yours is taking 5 mins.

Unless your timers have been changed the other way then
something else is causing the delay.

If you post the whole config maybe someone will have a look?


0 new messages