cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
487
Views
4
Helpful
7
Replies

Port-channel question

william.briere
Level 1
Level 1

Hello,

I am setting up some port-channels and want to know how each end should be setup...

I created this on each end...

interface port-channel 2

switchport

switchport trunk encapsulation dot1q

switch mode trunk

no ip address

Then this on each of the two interfaces at each end that were added...

switchport

switchport trunk encapsulation dot1q

switch mode trunk

no ip address

channel-group 2 mode on

The question is should both ends of the channel-group say "mode on". Is this the right way to do this?

1 Accepted Solution

Accepted Solutions
7 Replies 7

Edison Ortiz
Hall of Fame
Hall of Fame

If you follow the SRND Best Practise guidelines you should hard-code the Port-Channels (and VLAN trunks) as this decreases the time it takes for the interfaces to come up and converge:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns656/c649/cdccont_0900aecd804ab67d.pdf

It is quite significant as well - hard-coded Trunks gain you 2-seconds or so, hard-coded EtherChannels gain you as much as 7-seconds.

All the design guidelines are at the SRND site:

http://www.cisco.com/go/srnd/

HTH

Andy

Andy,

That's one of those religious battles that I don't want to get into :)

Page 40 describes the topic at hand. Notice how the comparison is done with 'PAgP mismatch'. It never said 'not' to use PAgP.

There are a lot of features that you gain by using PAgP (I discussed this in the other thread) vs using ON.

Hi, Yes I have been through this before. I remember older best practise documents stating to use Desirable/Desirable etc, and I have put in networks using this. However I have done some testing in the lab and hard-coding trunks & channels does improve convergence time slightly. I also think it is good administrative practise to ensure all ports are configured specifically for their purpose and unused ports are shutdown and placed into a 'null' VLAN.

This all obviously goes wrong if someone decides to do some re-cabling but it would do either way anyway :o)

Andy

The option depends on the customer.

If they want the faster convergence time, the ON (as you stated) will provide that but it has a risk of going into etherchannel mode without checking the link partner.

Not sure if I want to implement a network where it doesn't have some kind of intelligence built-in.

I rather sacrifice the 1 or 2 seconds convergence time (BTW, I will have to check that with new IOS codes) vs misconfigured link-partners.

During my CCIE Lab preparation, I often used the 3 options and found no delay in convergence time...

For testing in the lab we used just two switches at Layer-2 and used HrPing utility on a PC. This was to verify the layer-2 link had come up and converged. Obviously in a structured network there are more elements to be considered like STP & routing protocols but for pure link up times it did improve with hard-coding things (trunks & channels).

I understand the potential issues that would arise if one end was accidentally reconfigured or a cable was re-patched incorrectly. This is all part of the administrative procedures though.

Andy

I myself don't like hardcoding them as more than once we have seen where if you hardcode a trunk really all it needs to see is a physical connection and it can say it is trunking when it really is not , if you let them negotiate the trunks and etherchannels we have not seen this problem .

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: