[c-nsp] port channel numbering schemes

[chris stand]

Hello,

Anyone use clever port channel numbering schemes ?

We have a number of facilities that have access closets that connect
either directly to a 7K or the access closets connect to 5Ks which
then connect to the 7Ks.

I have co-workers who want to take a trunk that might be carrying vlan
1300,1302,1304 and make the port channel 1300.
The next closet might have vlan 1306,08,10,12.14,16 so its port channel is 1306
The next closet might have vlan 1318, 1320 so ... po 1318

While this seems to have some value in terms of identifying .something
... I don';t think I have ever encountered such a scheme that does not
seem to be flexible for moves/add/changes in terms of addressing.

I want to use po10, po11, po12, po13,po14 like we have on every other
device up until now and put the appropriate vlans in the correct port
channels.

thoughts/ideas/concerns

???

Thanks,
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Nick Hilliard]

Post by chris stand
thoughts/ideas/concerns

This works fine until you try it on smaller boxes and you find out that
they only support port-channel names up to 48 or whatever. Then you have a
moment of extreme facepalm and go back to Po1, Po2 and Po3.

Nick
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jared Mauch]

Post by Nick Hilliard

Post by chris stand
thoughts/ideas/concerns

This works fine until you try it on smaller boxes and you find out that
they only support port-channel names up to 48 or whatever. Then you have a
moment of extreme facepalm and go back to Po1, Po2 and Po3.

I've found 'show interface description' and a well thought out (and machine parseable) standard for naming works well.

This way you can just find what you want quickly. CDP and LLDP can also assist you in documenting ports as well, though some people don't like the information leakage.

- Jared
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[-Hammer-]

+1

We don't have a formal port channel naming schema. I usually use 1-10
for things like ISLs between core and stuff and then start with 11-XXX
for all the port channels to various downstream devices. That said, the
interface description is still the most important part of our gear.

Now on the interfaces, if it's just L2, I use something like:

interf gi0/1
desc hostname of device I'm connecting to (port I'm connecting to)

And then if it's L3
desc hostname of device I'm connecting to (IP of device)

Works for port channels too....

-Hammer-

"I was a normal American nerd"
-Jack Herer

Post by Jared Mauch

Post by Nick Hilliard

Post by chris stand
thoughts/ideas/concerns

This works fine until you try it on smaller boxes and you find out that
they only support port-channel names up to 48 or whatever. Then you have a
moment of extreme facepalm and go back to Po1, Po2 and Po3.

I've found 'show interface description' and a well thought out (and machine parseable) standard for naming works well.
This way you can just find what you want quickly. CDP and LLDP can also assist you in documenting ports as well, though some people don't like the information leakage.
- Jared
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mark Tinka]

Post by -Hammer-
+1
We don't have a formal port channel naming schema.

We just go serially.

Cisco's start at "1", Juniper's start at "0", so
documentation is useful, although interface descriptions on
both sides of the link help a lot too.

We try not to match interface numbers to VLAN ID's. That
works out alright when you're starting out, but as the
network grows, many face-palm and hair-pulling moments :-).

Mark.

[Phil Mayers]

Post by Mark Tinka
We try not to match interface numbers to VLAN ID's. That
works out alright when you're starting out, but as the
network grows, many face-palm and hair-pulling moments :-).

Agreed. "Clever" numbering schemes can just be misleading when they
don't "line up".
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Alan Buxey]

Hi,

Post by Phil Mayers

Post by Mark Tinka
We try not to match interface numbers to VLAN ID's. That
works out alright when you're starting out, but as the
network grows, many face-palm and hair-pulling moments :-).

Agreed. "Clever" numbering schemes can just be misleading when they
don't "line up".

another 'agreed' - however, we do try to use standard numbers for particular
types of port-channel - ie doing something like ensuring the po1 on
an aggregator switch is ALWAYS the link up to the core (and not a port-channel
to a stack of access switches or a workstation) - this simplifies a lot
of monitoring and sanity checking of configs/status of links etc.

alan
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mark Tinka]

Post by Alan Buxey
another 'agreed' - however, we do try to use standard
numbers for particular types of port-channel - ie doing
something like ensuring the po1 on an aggregator switch
is ALWAYS the link up to the core (and not a
port-channel to a stack of access switches or a
workstation) - this simplifies a lot of monitoring and
sanity checking of configs/status of links etc.

What happens when you introduce a new vendor that starts
numbering bundled interfaces with "0" :-)?

Or when a new BU in Cisco decide to do something different
with their bundle links that is quite different from the BU
whose systems you're currently using :-)?

Of course, maybe corner cases for most folk, but then again,
I realize that one can't possibly conceieve every possible
eventuality. Only time and joy/pain will truly determine
your thoughts on the matter.

Cheers,

Mark.

[Chuck Church]

We kind of grouped ours:

Small range dedicated to uplinks Maybe 1 through 5
Small range dedicated to cross links (VSS or VPC) Maybe 6 through 9
Large range dedicated to downlinks - Majority are here, 10 up to the max.

Works good for a normal 3 layer campus design. Since they're only locally
significant, we reuse them. So on any given access layer switch, we know
its uplink is a certain number assuming just one. I suppose you could break
up the downlinks to correspond to a floor number in a building maybe. 10 -
19 first floor, etc. Whatever you design, plan for growth.

Chuck

-----Original Message-----
From: cisco-nsp-***@puck.nether.net
[mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Mark Tinka
Sent: Thursday, March 08, 2012 6:33 AM
To: cisco-***@puck.nether.net
Subject: Re: [c-nsp] port channel numbering schemes

Post by -Hammer-
+1
We don't have a formal port channel naming schema.

We just go serially.

Cisco's start at "1", Juniper's start at "0", so documentation is useful,
although interface descriptions on both sides of the link help a lot too.

We try not to match interface numbers to VLAN ID's. That works out alright
when you're starting out, but as the network grows, many face-palm and
hair-pulling moments :-).

Mark.

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Keegan Holley]

Post by chris stand

Post by Nick Hilliard

Post by chris stand
thoughts/ideas/concerns

This works fine until you try it on smaller boxes and you find out that
they only support port-channel names up to 48 or whatever. Then you

have a

Post by Nick Hilliard
moment of extreme facepalm and go back to Po1, Po2 and Po3.

I've found 'show interface description' and a well thought out (and
machine parseable) standard for naming works well.
This way you can just find what you want quickly. CDP and LLDP can also
assist you in documenting ports as well, though some people don't like the
information leakage.

+1 interface descriptions are the way to go here. I try to stay away from
clever numbering. I find that it's hard for people other than the person
that thought of the scheme to remember it. Not only that what happens to
your numbering scheme if you need to move vlan1300 or add it to more than
one port channel. Numbers don't convey enough information to be used as
an inventory system.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Geoffrey Pendery]

I think there's definitely value in putting some thought into any
numbering/naming scheme you use anywhere, but the answer you come up
with will depend on your organization and the situation.

If you have excellent documentation systems which are quick and easy
to use and always kept up to date, then I would say just serialize
them (first port-channel you ever set up is 1, the 37th you set up is
37) then whenever someone is servicing or troubleshooting that
connection they can just plug it into the doc system and get whatever
information is useful about it (which closet it connects and which
VLANs it carries, in your case)

For those less fortunate with documentation, it might be helpful for
the name of the LAG to have some descriptive value. If you do not
have CDP enabled in most places, then troubleshooting a device with
LAG issues you might first want to know where that LAG goes, so you
could use a locally significant scheme like "Port1 is the primary
uplink to upstream device, Port2 is a secondary uplink where
applicable, Port 3 is always the sideways link between an A/B pair,
etc"

If you have CDP (or LLDP, or whatever) in place and identifying "where
does this port go" is not a regular issue, then it might be more
helpful to have the numbers be globally unique and identify it's place
or role in the network - say "Port 100-199 connects to closet 1, Port
200-299 connects to closet 2, Port X01 is the primary uplink, X02 is
the secondary" so when an alarm goes off for Port202, you immediately
recognize that's the secondary uplink from Closet 2.

Of course if your network is only 10 nodes, maybe it's a waste to
bother with the scheme at all, just pick something an everyone will
remember it.

Up to you what you choose, but I'd definitely put thought into any
naming scheme before you roll it out, as it will likely be with you
for a long time.

-Geoff

Post by chris stand
Hello,
 Anyone use clever port channel numbering schemes ?
We have a number of facilities that have access closets that connect
either directly to a 7K or the access closets connect to 5Ks which
then connect to the 7Ks.
I have co-workers who want to take a trunk that might be carrying vlan
1300,1302,1304 and make the port channel 1300.
The next closet might have vlan 1306,08,10,12.14,16 so its port channel is 1306
The next closet might have vlan 1318, 1320 so ... po 1318
While this seems to have some value in terms of identifying .something
... I don';t think I have ever encountered such a scheme that does not
seem to be flexible for moves/add/changes in terms of addressing.
I want to use po10, po11, po12, po13,po14 like we have on every other
device up until now and put the appropriate vlans in the correct port
channels.
thoughts/ideas/concerns
???
Thanks,
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Gert Doering]

Hi,

Post by chris stand
We have a number of facilities that have access closets that connect
either directly to a 7K or the access closets connect to 5Ks which
then connect to the 7Ks.
I have co-workers who want to take a trunk that might be carrying vlan
1300,1302,1304 and make the port channel 1300.
The next closet might have vlan 1306,08,10,12.14,16 so its port channel is 1306
The next closet might have vlan 1318, 1320 so ... po 1318

This is a particularily weird one :-) - what will your co-worker do
if vlan 1200 gets added to po1318? Renumber the port-channel?


We usually decide on a case-by-case basis how to number the port-channels,
and then it's usually something like:

- from distribution router (6500) to distribution switches (whatever)
port-channel 1, 2, 3, 4... to dist-switch 1, 2, 3, 4...

- from distribution router to core router
port-channel 100, 101, 102, ...

Post by chris stand
I want to use po10, po11, po12, po13,po14 like we have on every other
device up until now and put the appropriate vlans in the correct port
channels.

That's about what we use. Tacking port-channel numbers to vlans on the
channel will give you headaches some day - vlan distribution tends to
change all the time.

gert

[Alan Buxey]

As I said, we TRY . The vendors will do their best to scupper us, other things will come up to b0rk it. But as a rule of thumb its a starting point
(i'm more concerned that other things change such as the MIB value between different platforms)

alan


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/