cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10036
Views
0
Helpful
12
Replies

How to keep an Ethernet interface UP

aformisani
Level 1
Level 1

Hi

There is some way to increase the speed of changing the interface state from DOWN to UP when the cable is connected.

I need to configure a port of Cisco 4503 in a way that when a cable is connected the port goes immediatly UP.

A solution can be to keep Cisco interface always UP and I remember that with "no keepalive" command to the interface configuration it was possible.

But I tried and nothing happens.

Can someone halp me.

Thanks

12 Replies 12

Ton V Engelen
Level 3
Level 3

Hi, it might be that you mean spanning-tree portfast on access ports.

This would increase the speed of the interface coming up.

Hi

Thanks for your answer.

In fact the interface is already configured with portfast to change in forwarding state the interface immediately when it goes up.

But my problem is the time between when I insert a cable and the port goes phisically up and start to receive packets.

This time is to long compared to the devise connected so Cisco can't receive some important informations after reconnection.

For that reason I was trying to force the interface always UP even when no cable is connected. But I found that "no keepalive" have no effect.

Andrea,

On switches, the no keepalive has no effect on interface up or down state, and instead, it deactivates an important protection against self-looped ports. I suggest you put back the keepalive command on the ports where you have disabled it.

You are complaining about your ports requiring too much time after reconnect to become "up". How much time is that? Is it roughly in seconds? What would be an acceptable time for you?

Some delay may be caused by the port performing autonegotiation of speed and duplex with its connected peer. Configuring both speed and duplex statically (and identically, of course) on both devices can shave off some time to make the port come up. However, at the same time, this configuration is prone to duplex mismatches or no-link scenarios when two devices are not identically configured, so it limits your flexibility.

Best regards,

Peter

Hi Peter

The problem is that Cisco 4503 are connected with Moxa industrial switches.

Moxa switches are connected in chain between each other and to 2 Cisco 4503 in an other network with their 2 ends (called Head and Tail)

One end is blocked (Tail) by Moxa proprietary protocol (Turbo Chain)  and is used like backup link. When a faulty happens Moxa protocol immediately open that link.

In any failure everything is working very fast (time recovery 200 - 300 ms). The only problem found is for the link between Moxa end Cisco (the Head).

When failure happens is fine, but after reconnection  there is not recovery.

PS:Cisco interface set with portfast,

The reason why this issue happens, I suppose, is due to the behaviour of Cisco interface that goes up later than Moxa that has already sent all information after topology changed (eg Mac Address table)

I checked as you said the configuration of the ports but they are in fiber optic so I guess I can't configure speed and duplex. The strange think is that Moxa goes immediately up and operative while Cisco takes 1 or 2 seconds before the protocol (layer 2) goes up.

I hope I've been clear

Thanks

Andrea,

Can you post the complete configuration of one such port on your Cisco switch? It would certainly be helpful to see what configuration does the port use before drawing any conclusions.

Best regards,

Peter

Andrea, I agree with Peter (for what it's worth) that a port config needs to be seen; also, you say that you have two 4503s that these connect into, are these 4503s linked at all (i.e. is there a possibility of a loop)?  Is there anything in the logs of the 4503 that would indicate why it's taking so long for that port to come up?  On a fiber connection the protocol should come up almost as quick as the physical (unles it's in a port channel that needs to negotiate).

It sounds like a spanning-tree issue, not a portfast issue.  Do you have Rapid Spanning-Tree enabled?

I'm guessing at your topology, but it sounds like spanning-tree has to re-converge.  This can take some time.

Rapid spanning-tree is monumentally faster and can also be deployed on a per-vlan basis if need be.

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml

Ven

Ven Taylor

Hi Ven,

Let's wait for Andrea to kindly show us some exact data from his switch I am also thinking about issues with carrier-delay, STP or similar. Just one comment:

Rapid spanning-tree is monumentally faster and can also be deployed on a per-vlan basis if need be.

Configure on a per-VLAN basis: yes. Deployed on a per-VLAN basis: no. The entire switch runs either STP or RSTP for all VLANs.

Best regards,

Peter

Peter:

You're right.  That's what I meant, but bad choice of words.

Ven

Ven Taylor

Hi

the configuration of the Cisco Port is :

interface GigabitEthernet2/3

description "Ring 1 - Switch HEAD"

switchport trunk allowed vlan 5-10,21

switchport mode trunk

logging event link-status

spanning-tree portfast trunk

show int gig2/3:

GigabitEthernet2/3 is up, line protocol is up (connected)

  Hardware is Gigabit Ethernet Port, address is e05f.b97f.6022 (bia e05f.b97f.6022)

  Description: "Ring 1 - Switch HEAD"

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLH

  input flow-control is off, output flow-control is off

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:00:17, output never, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 2000 bits/sec, 5 packets/sec

     958 packets input, 84633 bytes, 0 no buffer

     Received 498 broadcasts (469 multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 input packets with dribble condition detected

     10699 packets output, 868705 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier

     0 output buffer failures, 0 output buffers swapped out

and all capabilities:

GigabitEthernet2/3

  Model:                      WS-X4448-GB-SFP-Gbic

  Type:                            1000BaseLH

  Speed:                          1000

  Duplex:                          full

  Auto-MDIX:                     no

  Trunk encap. type:          802.1Q

  Trunk mode:                   on,off,desirable,nonegotiate

  Channel:                        yes

  Broadcast suppression:  percentage(0-100), hw

  Multicast suppression:   percentage(0-100), hw

  Flowcontrol:                  rx-(off,on,desired),tx-(off,on,desired)

  VLAN Membership:       static, dynamic

  Fast Start:                    yes

  CoS rewrite:                 yes

  ToS rewrite:                  yes

  Inline power:                 no

  SPAN:                         source/destination

  UDLD:                         yes

  Link Debounce:            no

  Link Debounce Time:    no

  Port Security:              yes

  Dot1x:                         yes

  Maximum MTU:           1552 bytes (Baby Giants)

  Multiple Media Types:  no

  Diagnostic Monitoring: N/A

  Queuing:                    rx-(N/A), tx-(1p7q1t)

In the other side the configuration of Moxa Switch is  very simple. The port connected to Cisco is the 4-1 and the only  parameter I can change is enable and disable the flow control. PS: it's  possible to change just parameters in bracket

Port Enable Description                     Speed       FDX Flow Ctrl MDI/MDIX

3-1  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

3-2  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

3-3  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

3-4  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

3-5  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

3-6  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

3-7  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

3-8  [Yes]  100TX,RJ45.                     [Auto     ] [Disable]     [Auto]

4-1  [Yes]  SFP-1GLXLC                       1G-Full    [Disable]      Auto

4-2  [Yes]  SFP-1GLXLC                       1G-Full    [Disable]      Auto

Moxa Switches are connected in Chain with ends connected to an other ring composed by 6 Cisco.

In Cisco Ring is running MST with just an Instance (instance 0). So it is like a normal RSTP.

Configuring  Cisco port in Portfast, 4503 doesn't wait any time to go in forwarding  state while if no portfast is configured the interface goes throgh  blocking, learning and forwarding mode but acting like normal STP and  take about 34 Sec to recover but this is normal I guess when a port is  communicating with a device running an other protocol.

I  guess the problem is not in Spanning tree but in the communication  between Cisco and Moxa protocol and as I said before the issue happens  just when I reconnect the cable between Cisco and Moxa.

Thanks everybody

I am no expert on Moxa, but I have a question:  You have configured portfast on the Cisco 4503.  What about the Moxa?

Hi

Moxa is running a proprietary protocol (Turbo Chain) where the only possible setting for the port involved to the chain is defining the type (Member, Head or Tail). The Head and Tail are the ends port of the chain. Head is the primary and Tail is the redundant link and is blocked by the protocol.

So the port connected to one Cisco is configured in Head mode and in the other side of the chain in Tail mode.

The issue is in the primary connection (Head) with Cisco in case I reconnect a cable after a failure.

In fact after reconnection Moxa protocol blocks immediately the Tail port that it was forwarding packets and send the informations (eg Mac Address Table) to Cisco through the restablished link (Head). But Cisco port is still down (at least the protocol) and I think it loses all informations.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: