The patching method I use, and the process I use to deploy it.

I'm sure this question gets asked a lot. I myself have scoured the web in search of the "best" layout for patching cables from the panel into the switches without running into issues like a bunch of excess cable length, or vastly different cable lengths. Terminating custom cables I'm sure looks nice, but is a pain in the ass, takes time, and you don't get as good of a cable with a man-made cable as a pre-terminated cable. Also, using more than 2 different cable lengths is also a pain in the ass, so How do you get a nicely dressed, intuitively laid out patch schema, using pre-terminated cables of only one or two different lengths?

I've been using what I would call an "inside-out" method, where you patch the outside of the patch panel to the middle of the switch, and work your way across, maintaining row for row on the panel and switch.

Obviously it works best when you have the same number of patch panels as you do switches/copper cards. -Sometimes you have to get creative when you have more patch panel ports than switch cards.

Rule of thumb being to never cross the center line of the ports.

Example: Patch panel A-1 would (on a 48-port Cisco switch) be connected to g1/0/23. A-2 would be g1/0/21, A-3 would be 1/0/19 and so-on until you get to port A-13, which would go to G1/0/47.

Starting with A-25 in 1/0/24, you repeat the same process.

So far, in multi-switch or multi-card racks, I have been just going top patch panel to top switch, but I wonder if it would be better to go top panel to bottom switch and work inward panel to switch, so that bottom panel goes to top switch.

This has allowed me to use the same length patch cable all the way across the switch and not end up with too much extra length or come up short. Generally I use 5 foot cables.

Since I mostly have to deploy this method on existing cabinets, it requires a re-mapping of the interface configs to match where they will land with the new port matrix.

Usually I do pre-work to save time during the maintenance window, but you could theoretically do everything on the same day.

Here's my process:

Step 1: document your existing connections. This is arguably the worst part of the process. Generally you can't rely on old documentation, and you have to be 100% sure of all of the connections, because they're all going to be moved. This means hand-tracing each cable (which is uaually a spaghetti mess in my current environment.) It helps to have a buddy with a laptop to document what patch port goes to what switch port, so you can focus on tracing, and call out what goes where when you find it.

Step 2: lay out your exiting connections and plan your new matrix.

In a spreadsheet, I take a copy of my current network layout and transpose it into columns and turn it into a table so I can sort by patch letter, or by switch port. Now is a good time to highlight important things, and also to find ports that aren't being used that can be disconnected. Hopefully if you're doing this, it's because you're either replacing or adding equipment to your rack or whatever and can plan growth into your re-cabling effort. This was the case for me in the example below.

Example *disclaimer* I moved the green ports around to better distribute PoE load because they are AP's.

Step 3: map your ports to your new config:

Using excel, transposing your existing and planned port layouts can help you create tables so you can see what port configs need to be changed. I put two tables together showing the existing layout and the new plan, and then merge the patch panel port with its current and planned switch port. I then sort that list by the existing switch port number. This will show a sequential list of your existing switch ports and what new port that config will go on.

Step 4: build your config script.

Save your running config, and then copy out the interfaces portion.

Using the table, all you have to do is run down through the interfaces in the config document and change the interface number to the planned interface number.

(be sure to take out any ports that you skip from the config, so they don't overwrite the ones you change. Example: if your config changes port 1/0/1 to port 1/0/5, and you won't be using or moving g1/0/5 to a different port, make sure you remove port 1/0/5 from your config script, or it will be written back to g1/0/5 when you paste in the config script.)

Step 5: do the migration.

You can do this part in whatever order during your maintenance window, but you'll need to disconnect all of the old patch cables from the switches, patch in your new cables according to your planned matrix document, and default all of the interfaces to blank configs, and then paste in your new interface configs from your plan config script. I would only paste in a handful of new interface at a time, to be sure you don't overwhelm the buffer on the switch.

Then you can go back through and fill in any (intentionally) blank ports with a generic interface config.

It helps to have plenty of cable wrap / velcro tape, tak-ty whatever you use to manage your cables on hand during this step so you can dress in your cables as you go.

Step 6: test / check-out

Since you can't really roll back (I mean, you can... you have the documentation to) you need to do checks and test. The more complex your network (more vlans, deviated port configs) the more you want to check and re-check. A lot of this process relies on a lot of focus on very tedious tasks like tracing cables and documenting them correctly and changing interface configs. You need to take your time with that, and also with your check out. I usually break it out over three days. Day 1 (hopefully a maintenance window) go in and trace down the cables and document the current situation. Day 2, during the week I build my matrix and my config script for my interfaces. During production I like to take a ping sweep of the switch, get running configs, CDP neighbor lists, etc. Day 3 (maintenance window) is when I do the migration and the testing.

I hope this helps somebody.

I don't get on much, but if you have questions about my method, or have some advice for me on a better way, please leave a comment or send me a message.

I'm also looking for new ways to name network drop locations and access points. (currently using a column grid, but sometimes there are no columns, or the drops are at different elevations/ floors.) preferably a convention that will fit on a patch panel label.

Thank you.