Steve McIntyre | 7f14934 | 2015-08-06 15:08:27 +0100 | [diff] [blame] | 1 | Port numbering and naming in VLANd |
| 2 | ================================== |
| 3 | |
| 4 | This is a far more complex subject than it should be, and it may cause |
| 5 | problems for end users depending on their usage models. This is |
| 6 | particularly likely for those users with Cisco Catalyst 3750 switches |
| 7 | configured with extra internal modules for extra copper/fibre ports. |
| 8 | |
| 9 | Terminology |
| 10 | =========== |
| 11 | |
| 12 | For consistency, throughout this document and within VLANd two terms |
| 13 | are used to identify switch ports: |
| 14 | |
| 15 | * a PORT NAME is the (typically) alphanumeric identifier for a switch |
| 16 | port *in software*, i.e. when using the CLI to manage a |
| 17 | switch. Common naming styles vary significantly here; examples from |
| 18 | the VLANd test rack in Linaro's lab include "Gi1/0/6", "Gi1/1/4", |
| 19 | "Te1/1/2", "fa24", "gi3", "1/0/23" |
| 20 | |
| 21 | * a PORT NUMBER is the (typically) numeric identifier for a switch |
| 22 | port that is labelled visibly on the switch somewhere, typically |
| 23 | next to the port or a group of ports. Not all switches limit |
| 24 | themselves to numeric labels, though. The same examples from our |
| 25 | test rack are described as "6", "G4/Te2", "24", "G3", "23G", "23T" |
| 26 | |
| 27 | These example include some of the problems - try and match tnem up! |
| 28 | |
| 29 | The problem |
| 30 | =========== |
| 31 | |
| 32 | On all of the switch models that we currently support, there is a |
| 33 | disconnect between the port names and the associated port numbers. The |
| 34 | port names are not directly shown to the user on any of our switches, |
| 35 | which is not a good start. |
| 36 | |
| 37 | To a human operator, it is likely not very difficult to perform the |
| 38 | mapping from one scheme to the other in most cases. However, multiple |
| 39 | cases exist where it is difficult to map reliably from one identifier |
| 40 | to the other in software without needing extensive manual |
| 41 | configuration. For our VLAN control to be useful, we need to be able |
| 42 | to identify ports in a recognisable way for our users who have |
| 43 | connected devices to their network. |
| 44 | |
| 45 | In the examples above, I showed 6 identifiers in each list but they |
| 46 | only correspond to 5 physical ports on the switches! |
| 47 | |
| 48 | Problem 1: Disjoint port numbers |
| 49 | -------------------------------- |
| 50 | |
| 51 | On our Cisco SF300, there are two sets of ports: 48 10/100M RJ45 ports |
| 52 | and a further four 1G RJ45 ports. They're labelled externally as ports |
| 53 | 1-48 and G1-G4; internally the names are fa1-fa48 and |
| 54 | gi1-gi4. Thankfully, this particular case isn't too hard to deal |
| 55 | with. The SG300 we have (which works with the same driver) simply has |
| 56 | 52 ports labelled 1-52 and named gi1-gi52. |
| 57 | |
| 58 | Problem 2: Single physical ports with multiple possible port names |
| 59 | ------------------------------------------------------------------ |
| 60 | |
| 61 | On our Cisco Catalyst 3750-X 24P, most of this is easy. It has 24 1G |
| 62 | ports, labelled 1 to 24 on the front panel. The port name "Gi/1/0/6" |
| 63 | corresponds to "6". However, we also have an extra SFP module fitted |
| 64 | that exposes 4 extra 1G interfaces (labelled G1 to G4). However, |
| 65 | there's more complication yet: G2 and G4 are dual-personality ports |
| 66 | and can also work as 10G ports when appropriate SFP+ modules are |
| 67 | inserted. These 1G and 10G ports are named differently in software |
| 68 | depending on which speed is in use: |
| 69 | |
| 70 | G1 -> Gi1/1/1 |
| 71 | G2/Te1 -> Gi1/1/2 OR Te1/1/1 |
| 72 | G3 -> Gi1/1/3 |
| 73 | G4/Te2 -> Gi1/1/4 OR Te1/1/2 |
| 74 | |
| 75 | Our Catalyst 3750 also has an extra 10/100M port on the back as a |
| 76 | management port; VLANd explicitly ignores this port. Various other |
| 77 | models in the 3750 range can come in a whole range of different |
| 78 | configurations with 10/100M, 1G and 10G ports and it's very difficult |
| 79 | to identify naming and numbering schemes for all of these without |
| 80 | physical access to all of them. |
| 81 | |
| 82 | Problem 3: Multiple physical ports which map to the same port name |
| 83 | ------------------------------------------------------------------ |
| 84 | |
| 85 | Our Netgear M7300-24XF (aka XSM7224S) has 24 10G SFP+ ports and a |
| 86 | further 4 10G RJ45 ports. Those 4 copper ports replace the last 4 of |
| 87 | the SFP+ ports in a "combo" arrengement - if an SFP module is |
| 88 | inserted, the RJ45 port is disabled. Thus, on this switch we have the |
| 89 | following port numbers and port names: |
| 90 | |
| 91 | 1 -> 1/0/1 |
| 92 | ... |
| 93 | 20 -> 1/0/2 |
| 94 | 21F/21T -> 1/0/21 |
| 95 | ... |
| 96 | 24F/24T -> 1/0/24 |
| 97 | |
| 98 | This combo approach is also used on the TP-Link TL-SG2216; it has 16 |
| 99 | 1G RJ45 ports and 2 1G SFP ports which over-ride them: |
| 100 | |
| 101 | 1 -> Gi1/0/1 |
| 102 | ... |
| 103 | 14 -> Gi1/0/14 |
| 104 | 15/15F -> Gi1/0/15 |
| 105 | 16/16F -> Gi1/0/16 |
| 106 | |
| 107 | These show the opposite problem to the Catalyst 3750 - if a user |
| 108 | connects to port 16 on the TP-Link, that at least will show up as one |
| 109 | consistent name in the CLI. However, should we be looking for port |
| 110 | number 16 or 16F when talking to the user? |
| 111 | |
| 112 | A (partial) solution in VLANd 0.4 onwards |
| 113 | ========================================= |
| 114 | |
| 115 | Hopefully the above descriptions will make it clear that this is a |
| 116 | hard problem to solve 100% reliably. However, it's a problem that must |
| 117 | at least partially be solved as end-users supplying port numbers |
| 118 | cannot be expected to know the port names that are used internally by |
| 119 | the switches but not exposed externally. Yet port names must be used |
| 120 | internally for all the interactions with the switches directly - this |
| 121 | is the only way that the software can work. |
| 122 | |
| 123 | So, port numbers have been added as an extra column in the port |
| 124 | database. New APIs and methods have been added to do lookups by port |
| 125 | number as alternatives to lookups by port name, to make things easier |
| 126 | for end users. When adding ports using the admin interface, a port |
| 127 | number is now required too. |
| 128 | |
| 129 | The backend of the auto_import_switch admin command (the recommended |
| 130 | way to add switches) will attempt to automatically allocate sensible |
| 131 | port numbers as it probes switches and finds new ports. The algorithm |
| 132 | chosen here for assigning port numbers is the simplest one that might |
| 133 | work for most of the switches and configurations that we |
| 134 | have. *Numeric* port numbers (i.e. without any prefix or suffix |
| 135 | letters) will be assigned to port names simply in the order that the |
| 136 | port names are listed via a switch's CLI, starting with "1". For |
| 137 | almost all our supported switches, this should make sense for a user |
| 138 | when trying to supply port numbers. However, *BE AWARE* of the |
| 139 | possbility that your port numbers may not always match the port |
| 140 | numbers written on your switch in some cases (e.g. the Cisco Catalyst |
| 141 | 3750 as described above). |
| 142 | |
| 143 | If this port number to port name mapping algorithm proves not to be |
| 144 | sufficient, future releases of VLANd may include options in the config |
| 145 | file to provide exact mappings. We'd prefer not to have to do this due |
| 146 | to the admin overhead it will impose (and the attendant possibility of |
| 147 | errors). |