> @alan - carrier-delay msec 0 did not seem to make any difference, I still
lost 5 pings. I simply turned it on the single interface I am testing with
and assumed it will kick in.
Doesn't the carrier-delay msec 0 affect only the down events if "up|down"
knob is supported by any chance?
Have you t
Fiber is not an option for the customer at the moment. So they will have to
live with about 5 seconds of loss.
@alan - carrier-delay msec 0 did not seem to make any difference, I still
lost 5 pings. I simply turned it on the single interface I am testing with
and assumed it will kick in.
On Wed,
Hi,
> > * I am definitely not disabling spanning-tree. I have enabled 'portfast
> > trunk' on the port which reduced the port uptime significantly.
> > * Disabling a lot of negotiation protocols improves port initialization
> > time as well
spanning-tree portfast trunk
switchport nonegotiate
(tha
Hi,
On Wed, Jul 17, 2013 at 11:23:37AM +1000, Shanawaz Batcha wrote:
> Is this as good as it gets or is there a trick to perhaps get this time
> further down?
fiber is faster than copper in this regard.
gert
--
USENET is *not* the non-clickable part of WWW!
On Wed, Jul 17, 2013 at 11:23 AM, Shanawaz Batcha wrote:
> Is this as good as it gets or is there a trick to perhaps get this time
> further down?
>
>
Have you tried moving to fibre rather than copper?
___
cisco-nsp mailing list cisco-nsp@puck.nether.ne
From: Tóth András
>> Date: 07/12/2013 6:00 PM (GMT-05:00)
>> To: Tom Storey
>> Cc: Shanawaz Batcha ,cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] Cisco trunk port startup delay
>>
>>
>> I would not encourage disabling STP at all, "portfast trunk
>
>
>
> Original message
> From: Tóth András
> Date: 07/12/2013 6:00 PM (GMT-05:00)
> To: Tom Storey
> Cc: Shanawaz Batcha ,cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Cisco trunk port startup delay
>
>
> I would not encourage disabling ST
Subject: Re: [c-nsp] Cisco trunk port startup delay
I would not encourage disabling STP at all, "portfast trunk" already
increases the chances of creating a loop, on the other hand it does allow
the port to transition to STP forwarding state immediately, so it should
have the same effe
I would not encourage disabling STP at all, "portfast trunk" already
increases the chances of creating a loop, on the other hand it does allow
the port to transition to STP forwarding state immediately, so it should
have the same effect.
Given that the delay is due to the actual link down and like
If they are connecting to servers, do you really need spanning tree?
I assume that spanning tree is blocking for x period of time, where x is
long or short depending on whether portfast is enabled.
If you remove spanning tree then there is no blocking, and it should come
up and be able to pass tr
Hi Guys,
Question for you is how soon can we get a cisco trunk port (connecting to
some enterprise servers) to initialize and pass traffic.
From
interface GigabitEthernet4/40
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 104
switchport mode trunk
spanning-tree
Hi Guys,
Question for you is how soon can we get a cisco trunk port (connecting to
some enterprise servers) to initialize and pass traffic.
From
interface GigabitEthernet4/40
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 104
switchport mode trunk
spanning-tree
12 matches
Mail list logo