{"id":1547,"date":"2014-07-30T12:03:57","date_gmt":"2014-07-30T11:03:57","guid":{"rendered":"http:\/\/blogs-new.it.ox.ac.uk\/networks\/?p=1547"},"modified":"2014-07-30T12:03:57","modified_gmt":"2014-07-30T11:03:57","slug":"configuring-cisco-ethernet-management-interfaces","status":"publish","type":"post","link":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/2014\/07\/30\/configuring-cisco-ethernet-management-interfaces\/","title":{"rendered":"Configuring Cisco Ethernet management interfaces"},"content":{"rendered":"<p>Following on from recent posts where I have covered our use of the Cisco Catalyst 4500-X platform for the eduroam networking infrastructure upgrade project, I thought it would be good to cover the Ethernet management interface in more detail. Why, I hear you ask? Well, whilst the topic in itself probably seems very trivial (and a bit dull frankly), configuring this and getting it to <em>actually<\/em> work proved trickier than I initially expected!<\/p>\n<p>Having spent some time researching the topic online after hitting a few snags, I wasn\u2019t able to find one single resource that answered all my questions.<\/p>\n<p>Therefore my hope is that this post may prove a useful time-saver to those who find themselves with a Cisco switch or router with an ethernet management interface they wish to use for management and monitoring systems.<\/p>\n<h2>Why should you use the management interface at all?<\/h2>\n<p>This is a valid question. In some scenarios you may decide you don\u2019t wish to. Certainly with the majority of our Cisco switching estate, we choose not to either. In cases where we *must* have Out-Of-Band (OOB) access to a device in the event of a major outage (thankfully we don\u2019t see many of those), we often instead favour the use of the console port connected with terminal servers which we can connect to over an alternative IP network. For other cases, we often use one of the standard base T ports VLAN\u2019d off onto a separate Lights Out Management (LOM) network.<\/p>\n<p>However using this dedicated management interface can be of benefit for many reasons depending on the scenario you\u2019re working with. Here are few of the main ones that influenced our decision in the case of the 4500-X platform:<\/p>\n<ul>\n<li>It isolates management traffic away from the global routing table in a dedicated VRF;<\/li>\n<li>It avoids having to use \u2018front-facing\u2019 interfaces;<\/li>\n<li>It avoids the expense of having to procure extra base T transceivers if you\u2019re working with an all SFP\/SFP+ platform.<\/li>\n<\/ul>\n<p>I\u2019m sure there are other benefits too of course, though being that the 4500-X is an all SFP platform with no other built-in base T ports, this seemed like a very sensible way to go.<\/p>\n<h2>Overview of management configuration \u2013 things to note<\/h2>\n<p>So, when I initially found myself sat at a terminal attempting an initial configuration of one of these switches, I quickly realised that our standard configuration template wasn\u2019t going to cut the mustard. I found some caveats with how you might normally expect to configure features, even the basic things.<\/p>\n<p>Here\u2019s a summary of what I found. I\u2019ll expand on these later on in this post:<\/p>\n<ul>\n<li>The management port out-of-the box is assigned to a management VRF (called \u2018mgmtVrf\u2019 or some variation depending on the platform and software version you\u2019re working with) and <em>cannot<\/em> be re-assigned to either another VRF, or the global routing table (so you can\u2019t cheat);<\/li>\n<li>We restrict VTY lines on our devices using an ACL to limit access to defined management IP hosts\/networks. I found that without an additional parameter in the access-class configuration statement I got \u2018connection refused\u2019 errors when attempting to connect to the VTY line;<\/li>\n<li>Rather counter-intuitively, using the \u2018vrf &lt;vrfname&gt;\u2019 variant of the ip domain-name command needed for Secure Shell (SSH) configuration did not work when generating crypto keys;<\/li>\n<li>Authentication Authorisation &amp; Accounting (AAA) configurations using the \u2018default\u2019 server group would not work;<\/li>\n<li>A custom AAA server group had to be defined for TACACS+\/RADIUS servers. Within this I had to use some specific commands to get this to work including specifying the source interface for associated requests;<\/li>\n<li>Some common global configuration mode commands could be used as normal, but others required the mgmtVrf VRF to be configured as an additional parameter;<\/li>\n<\/ul>\n<p>See? I told you it was tricky!<\/p>\n<h2>SSH\/VTY configuration<\/h2>\n<p>As described earlier, the sensible thing to do is to restrict access to your devices to only use SSH and only be allowed to do so from certain authorised hosts\/networks.<\/p>\n<p>In light of this, here\u2019s what our basic configuration looks like (I\u2019ve changed some IPs to dummy ones for security reasons):<\/p>\n<pre>aaa new-model\r\n\r\nusername networks secret &lt;password&gt;\r\n\r\nip domain-name lom.oucs.ox.ac.uk\r\n\r\nip access-list standard SSH-ACCESS\r\n\u00a0permit 192.168.3.222\r\n\u00a0permit 192.168.1.67\r\n\u00a0permit 192.168.102.0 0.0.0.31\r\n\u00a0permit 192.168.21.0 0.0.0.255\r\n\u00a0permit 192.168.22.0 0.0.0.255\r\n\u00a0permit 172.16.0.0 0.0.15.255\r\n\u00a0permit 192.168.2.0 0.0.0.255\r\n\r\nip ssh time-out 60\r\nip ssh source-interface &lt;source-interface&gt;\r\nip ssh version 2\r\n\r\nline vty 0 4\r\n\u00a0access-class SSH-ACCESS in\r\n\u00a0exec-timeout 5 0\r\n\u00a0logging synchronous\r\n\u00a0transport input ssh\r\n\r\nline vty 5 15\r\n\u00a0exec-timeout 0 0\r\n\u00a0logging synchronous\r\n\u00a0transport input none<\/pre>\n<p>Then of course, we would generate the RSA key:<\/p>\n<pre>crypto key generate rsa general-keys modulus 2048<\/pre>\n<p>OK, this part of the configuration has probably changed the least in light of using the management port.<\/p>\n<p>I\u2019d like to highlight that using the following command <b>as a substitute<\/b> for the one above <b>did not work<\/b>:<\/p>\n<pre>ip domain-name vrf mgmtVrf lom.oucs.ox.ac.uk<\/pre>\n<p>Great! This is really counter-intuitive isn\u2019t it? \u00a0Using the VRF-specific variant of the command <b>instead<\/b> of the standard command will mean you won\u2019t be able to generate the RSA key. However, you <b>do<\/b> need this command <b>in<\/b> <b>addition<\/b> to allow DNS lookups assuming you want to do this via the management interface too in conjunction with VRF-specific name server commands.<\/p>\n<p>The only remaining changes necessary to allow this part of the configuration to work was the addition of two commands within the line vty configuration:<\/p>\n<pre>line vty 0 4\r\n\u00a0access-class SSH-ACCESS in <strong>vrf-also<\/strong>\r\n\u00a0exec-timeout 5 0\r\n\u00a0logging synchronous\r\n<strong>\u00a0login authentication TAC_PLUS<\/strong>\r\n\u00a0transport input ssh\r\n\r\nline vty 5 16\r\n\u00a0exec-timeout 0 0\r\n\u00a0logging synchronous\r\n\u00a0transport input none<\/pre>\n<p>With these changes in place, you should be able to generate the RSA key as normal and find that SSH access via the VTYs works as expected. These are only very subtle differences granted, but I suspect you may find yourself scratching your head for a while without them \u2013 I certainly did!<\/p>\n<p>The configuration of the specific custom AAA server group (named TAC_PLUS in my examples) is detailed in the next section. If in your own scenario you simply rely on the local database for authentication, then you shouldn\u2019t need the \u2018login authentication\u2019 command.<\/p>\n<h2>AAA configuration<\/h2>\n<p>You can probably ignore this section if you aren\u2019t using AAA \u2013 ie. if you don\u2019t use a TACACS+ or RADIUS server to manage access to your network devices. In all likelihood, I would imagine you would be using one or the other in most cases.<\/p>\n<p>Our default AAA configuration is pretty standard really. In the case of normal operation, any users wishing to log into a network switch for example, are required to authenticate via our team-internal TACACS+ service, which in-turn decides what level of access a user is allowed (full or read-only) and what commands they are allowed to enter. This service also keeps accounting records \u2013 i.e. what a user did whilst they were logged in to a switch.<\/p>\n<p>In the rare case where the TACACS+ server may be unavailable, users can authenticate via the local user database on the switch. This should only ever be the case if the TACACS+ method is unavailable.<\/p>\n<p>These rules should also be applied regardless of where a user logs in from \u2013 i.e. whether they log in remotely over a VTY line or if they are attached directly to the console port of the switch.<\/p>\n<p>So with all this in mind, our normal AAA configuration template looks like this:<\/p>\n<pre>aaa authentication login default group tacacs+ local\r\naaa authentication enable default enable group tacacs+\r\naaa authorization console\r\naaa authorization exec default group tacacs+ local \r\nif-authenticated\r\naaa authorization commands 15 default group tacacs+ local \r\nif-authenticated\r\naaa accounting commands 1 default stop-only group tacacs+\r\naaa accounting commands 15 default stop-only group tacacs+\r\n\r\ntacacs-server host &lt;tacacs-server-IP&gt; key &lt;key-string&gt;\r\ntacacs-server directed-request\r\n\r\nip tacacs source-interface &lt;source-interface&gt;<\/pre>\n<p>This configuration didn\u2019t work at all when using the management interface. Instead, you have to first define your own server group like this:<\/p>\n<pre>aaa group server tacacs+ TAC_PLUS\r\n\u00a0server-private &lt;tacacs-server-IP&gt; key &lt;key-string&gt;\r\n\u00a0ip vrf forwarding mgmtVrf\r\n\u00a0ip tacacs source-interface &lt;management-interface&gt;<\/pre>\n<p>In fairness, Cisco have been warning us for quite some time that they would be deprecating the old \u2018tacacs-server\u2019 and \u2018radius-server\u2019 commands. Old habits often die hard though!<\/p>\n<p>Also note the use of the \u2018server-private\u2019 command and the definition of the mgmtVrf VRF within the group. Both are important!<\/p>\n<p>In light of our new custom AAA server group configuration, the AAA method commands also have to be amended to match. These now should look something like this (exact commands may vary depending on your own AAA policies used locally of course):<\/p>\n<pre>aaa authentication login default group TAC_PLUS local\r\naaa authentication enable default group TAC_PLUS enable\r\naaa authorization console\r\naaa authorization exec default group TAC_PLUS local \r\nif-authenticated\r\naaa authorization commands 15 default group TAC_PLUS local \r\nif-authenticated\r\naaa accounting commands 1 default stop-only group TAC_PLUS\r\naaa accounting commands 15 default stop-only group TAC_PLUS<\/pre>\n<h2>Other global configuration mode commands<\/h2>\n<p>There are of course other management services to consider, assuming of course, you want all management-related traffic to utilise the management port.<\/p>\n<p>Commands for these other services are entered in global configuration mode. Using the dedicated management port, some of these commands have to be amended to include additional parameters whereas others do not. I would suggest that using the context-help (our helpful friend the &#8216;?&#8217;) in IOS\/IOS-XE will help here in addition to the configuration guide for your platform.<\/p>\n<p>Here\u2019s how I configured the 4500-X platform to send queries to our DNS servers, send logs to our syslog server, participate in SNMP and synchronise its clock to our NTP servers via the management port. I\u2019ve highlighted in bold the commands that have to be amended:<\/p>\n<pre><strong>ip domain-name vrf mgmtVrf lom.oucs.ox.ac.uk<\/strong>\r\n<strong>ip name-server vrf mgmtVrf &lt;dns-server-1-IP&gt;<\/strong>\r\n<strong>ip name-server vrf mgmtVrf <strong>&lt;dns-server-2-IP&gt;<\/strong><\/strong>\r\n<strong>ip name-server vrf mgmtVrf <strong>&lt;dns-server-3-IP&gt;<\/strong><\/strong>\r\n\r\nlogging trap debugging\r\nlogging facility local6\r\n<strong>logging host &lt;syslog-server-IP&gt; vrf mgmtVrf<\/strong>\r\n<strong>logging host &lt;syslog-server-IP&gt; vrf mgmtVrf<\/strong>\r\n\r\nsnmp-server community &lt;community-string&gt; RO \r\n&lt;restricted-ACL-name\/number&gt;\r\nsnmp-server trap-source &lt;management-interface&gt;\r\nsnmp-server source-interface informs &lt;management-interface&gt;\r\nsnmp-server contact Networks\r\n<strong>snmp-server host &lt;snmp-poller-IP&gt; vrf mgmtVrf \r\n&lt;community-string\/username&gt;\u00a0 tty vtp config vlan-membership snmp<\/strong>\r\n<strong>snmp-server host <strong>&lt;snmp-poller-IP&gt;<\/strong> vrf mgmtVrf \r\n&lt;community-string\/username\u00a0 tty vtp config vlan-membership snmp<\/strong>\r\n\r\nntp source &lt;management-interface&gt;\r\n<strong>ntp server vrf mgmtVrf &lt;ntp-server-1-IP&gt;<\/strong>\r\n<strong>ntp server vrf mgmtVrf <strong>&lt;ntp-server-2-IP&gt;<\/strong><\/strong>\r\n<strong>ntp server vrf mgmtVrf <strong>&lt;ntp-server-3-IP&gt;<\/strong><\/strong>\r\n<strong>ntp server vrf mgmtVrf <strong>&lt;ntp-server-4-IP&gt;<\/strong><\/strong><\/pre>\n<p>Please note I do not intend the above to be exhaustive. These are provided purely as examples and of course, you may have other services to configure that I haven&#8217;t mentioned here.<\/p>\n<h1>Conclusion<\/h1>\n<p>Once you get your head around the configuration specifics surrounding the management port, it actually provides a neat way of connecting your new device with your network management infrastructure without wasting front-facing interfaces. It also provides an out-of-the-box method for isolating your management traffic away from normal data traffic.<\/p>\n<p>If I had one criticism, it would be that the configuration for this in the Cisco world could be easier and more consistent. But we can\u2019t have it all our own way all of the time!<\/p>\n<p>Thanks for reading!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Following on from recent posts where I have covered our use of the Cisco Catalyst 4500-X platform for the eduroam networking infrastructure upgrade project, I thought it would be good to cover the Ethernet management interface in more detail. Why, &hellip; <a href=\"https:\/\/blogs-new.it.ox.ac.uk\/networks\/2014\/07\/30\/configuring-cisco-ethernet-management-interfaces\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":207,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-1547","post","type-post","status-publish","format-standard","hentry","category-cisco-networks"],"_links":{"self":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/1547","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/users\/207"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/comments?post=1547"}],"version-history":[{"count":11,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/1547\/revisions"}],"predecessor-version":[{"id":1612,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/1547\/revisions\/1612"}],"wp:attachment":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/media?parent=1547"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/categories?post=1547"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/tags?post=1547"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}