Remotely Create Trunk Port on Same Interface as Telnet
I require a way to convert an access port to a trunk port on the same interface that I am using to administer the device via Telnet. I have a small remote site with no out of band management or technical hands on site. WAN access is provided via a layer 3 switch which terminates a Layer 2 WAN connection and then that switch connects via an access port to a 2901 router that is acting as a voice gateway ( a little backward, I know ).
The connection between the two is an access port and I need to convert it to a trunk port, but that interface is the only means I have to manage the router is telnet over that same interface. I need to also add another VLAN to use the trunk.
I have tried setting the switch interface to dynamic desirable and creating the subinterfaces I need on the router, however when I enter the command "encapsulation dot1q X" (where X is the vlan I am currently using the manage the device) the link drops all together.
I have been using the 'reload in x' command to have the device reload so I don't lose access to it all together.
Am I on the right track here? What am I missing?
PS: I am also toying with the idea of pulling down the startup-config via tftp, editing it, replacing it and then reloading the device, but I would like to avoid that if I can because I only get one shot at it.
To trunk to a router the switchport must be set as "switchport mode trunk" . Make your management vlan the native on the trunk . If you have a tftpserver and you have your configs backed up you can modify the config and then transfer it into "startup" config . You can then verify the startup config looks ok before reloading or doing a copy start run command. Just make sure the config is correct . Use dot1q as encapsulatiuon .
Thanks for your response. I'd like to avoid editing the startup-config if I can because that will give me no fall back if I get it wrong. The trunking itself is straight forward. Editing the link and maintaining management over that same link is the tricky bit.
1) you may be able to to leave the physical interface as is and make sure that the vlan on the switch that is used for the IP subnet is set to the native vlan on the trunk link.
If that worked then there is no need to use the "encapsulation dot1q .." command on the physical interface because it receives untagged frames so there is no need to tell it which vlan tags it should see.
Then you could just create a subinterface for the new vlan and add the encapsulation and an IP address to that.
It may or may not work so no guarantees but it is worth a try.
If you then still wanted to actually have the current vlan on a subinterface you may be able to log into the router via the subinterface and change the physical interface although i'm not sure whether that wouldn't temporarily bring down the whole interface.
All that said i'm not sure what you are trying to achieve. The vlans from the L3 switch terminate on the physical router interface so nothing else on the router can use those vlans. So why not simply route the vlans on the L3 switch and add the appropriate routes to both the L3 switch and the router.
Perhaps you can clarify what the additional vlan is meant to be used for ?
Thanks for the reply and good question on why I need it set up this way. This is part of a larger effort for one of our customers where we are rolling out a management network to all of their sites. Each site will receive a management subnet of the 172.20.0.0 /16 network and an ACL will be applied to each device to only allow Telnet from that network. For the ACL to work, the Telnet request must be seen to be coming from that management subnet, thus the trunk. Otherwise, you need to use the "telnet x.x.x.x /source-interface vlan xxx" command.
I like your native VLAN idea and I will try that when next I am near my lab. I'll report back what I find.
PS: Also, I can tolerate a brief period of inaccessibility if required. For the trunk to come up or the device to restart, but I need a fall back in case I cut my access.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...