Problems with achieving link redundancy to a Cisco 3550 switch

Discussion in 'Cisco' started by Garrick Ransome, Oct 13, 2003.

  1. Hi

    I'm encountering a problem with a cisco 3550 switch as described below, and
    am hoping that somebody could give me some insight as to why I should have
    such problems and perhaps give me some pointers as to getting my system to

    I have a node with two gigabit ethernet ports. All traffic received on
    either port is forwarded to the other port except for unicast frames
    destined for that node. Therefore, the traffic that is forwarded includes
    broadcasts, multicasts, unicasts for other nodes, loopback frames(0x9000
    ethernet type), and also spanning-tree BPDUs. Traffic originating from the
    node is sent out of both ports. This effectively allows me to create a
    daisy-chain of nodes.

    I am attempting to attach both interfaces directly to a Cisco 3550 switch,
    to effectively use the second link for redundancy as follows:

    | Node |
    | __ __ |
    | | A | | B | |
    | |
    | |
    | 0/4 0/5 |
    | Cisco 3550 |

    Both Cisco ports are configured for spanning tree, with portfast mode
    disabled. Theoretically (or in my version of theory at least), both ports
    will start in the BLOCKED state. After forwarding and listening to spanning
    tree BPDUs, the port with a higher priority (port 0/4) should become the
    designated port and progress to FORWARDING state, and the other port (0/5)
    should become an alternate port and remain in the BLOCKED state. In the
    diagram, all packets sent to port A of the node will get forwarded out of
    port B, but discarded by the switch interface 0/5, which is in the BLOCKED
    state. Packets sent from the node will be sent from both ports but only
    those that are received on 0/4 of the switch will get forwarded to the
    network. Thus the node will have full connectivity to the network provided
    by the switch, and the second link provides redundancy to the first link.

    In reality, this does not seem to be the case. When connecting the node to
    the switch in the above configuration, both the ports on the switch seem to
    block all traffic bi-directionally. Here are some of my observations:
    - The "show spanning-tree detail" command shows that port 0/4 is forwarding
    and port 0/5 is blocking, and that the designated port for the two switch
    ports is 0/4. The BPDUs sent count for 0/4 increments at the same rate as
    the BPDUs received count for 0/5. This is exactly what is expected.
    - If I do a SPAN monitoring session of port 0/4, I see that packets sent
    from the node are received on the port, but these must be discarded as they
    are not forwarded or handled in any way.
    - If I display the mac-address-table using the "show mac-address-table"
    command, no port 0/4 dynamic entry exists with the node's mac address as
    would be expected. However, a port 0/4 dynamic mac-address entry exists
    with port 0/5's mac address, this I suspect a result of the loopback (type
    0x9000) ethernet frames continuously sent out of each port. Adding a static
    entry for the node to the mac-address-table makes the entry appear in the
    table but does not resolve the issue.
    - The 'no dest' counters displayed by "show contro eth gi0/4" increments for
    each frame that I send to the port, including broadcasts.

    I regain connectivity to the network when I remove one of the two links to
    only have a single link between the node and the switch, but only after I
    enforce a link status change on the remaining link.

    The Cisco IOS and product versions I am using are as follows:
    IOS (tm) C3550 Software (C3550-I5Q3L2-M), Version 12.1(9)EA1c, RELEASE
    SOFTWARE (fc1)
    cisco WS-C3550-12T (PowerPC) processor (revision H0)

    My configuration script is very basic and not much different to the default.
    If this is required, please let me know.

    Please help if you have an answer to my problem, or some suggestions
    regarding the issue and its resolution. I've been battling away at this to
    no avail.

    Thanks in advance.

    Garrick Ransome
    Software Engineer
    Garrick Ransome, Oct 13, 2003
    1. Advertisements

  2. wtown46333


    Oct 27, 2006
    I believe this problem is due to the switch having only one mac address. According to cisco this switch with the ios that you're running only supports one mac address even though it will appear to take the command. I think a solution would be to hook your node up to two separate switches or get a switch that supports mac addresses per each SVI such as 2970 or the 3750 switches.

    Cisco knows about these problems and doesn't allow you to assign per port mac addresses in the current release of the ios(
    12.1(14)EA )

    Here is a link to where I found this information.

    Good luck!!

    Wayne Townsend
    Last edited: Oct 27, 2006
    wtown46333, Oct 27, 2006
    1. Advertisements

  3. prelius


    Nov 3, 2006
    Not sure if this suggestion fits your requirements, but you could use ethernet bonding on the node which should take care of the mac address problem... Depending on your need, you can configure bonding of the two interfaces as aggregation (mode 0), active/backup (mode 1), or balancing (mode 2).
    Hope it helps....
    prelius, Nov 3, 2006
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. desdronox
    Terry Baranski
    Jul 10, 2003
  2. Vishnu
  3. Rob Slade, doting grandpa of Ryan and Trevor

    REVIEW: "Achieving Software Quality Through Teamwork", Isabel Evans

    Rob Slade, doting grandpa of Ryan and Trevor, Jul 15, 2004, in forum: Computer Security
    Rob Slade, doting grandpa of Ryan and Trevor
    Jul 15, 2004
  4. Replies:
  5. =?Utf-8?B?TWlra2Vs?=

    Achieving 54mbps

    =?Utf-8?B?TWlra2Vs?=, Jun 6, 2007, in forum: Wireless Networking
    Jun 6, 2007

Share This Page