Cisco Management – Can’t Access Remote Management Interface

I know the 3750X's have a management interface on the back which is a 10/100 Fast ethernet port. Its right next to the RJ-45 console port. I also believe that the 2960 switch that you listed there also has a management port on the front of it, above the SFP ports.

Assuming your switches aren't too far away, you could use the management interfaces to manage your devices remotely if you will. Of course you would require additional cabling back to another "management switch" which would likely contain the VLAN required just to manage these devices.

Otherwise, you could also run a terminal server server such as an OpenGear or something of that nature and have the console connections linked back to this device in order to remotely control them if your entire network is having issues or what not.

These management interfaces do operate on their own VRF and will also not participate in STP as they're not running on the active VLAN that is being trunked down to them. However, I have seen it where some organizations like to have the management VLAN on the same subnet as the hosts on the switch. This allows them to ping and check the arp table/mac address table and pinpoint where devices are a bit easier than if it was just a simple L2 network. There are of course pro's and con's to each method, however, given that you wanted to go about a out-of-band method. I would say the management interface is probably is your best direction.

If all traffic needs to go from gi0/4 to gi0/3 and from gi0/2 to gi0/1 you could use layer 2 local switching. Configuration would be about:

connect Router1-TM GigabitEthernet0/4 GigabitEthernet0/3 
connect Router2-TM GigabitEthernet0/1 GigabitEthernet0/2

If your linecards do not support layer 2 local connect, then consider bridge-groups:

bridge irb
interface range GigabitEthernet0/4 , GigabitEthernet0/3
 bridge-group 1
interface range GigabitEthernet0/1 - 2
 bridge-group 2
!
bridge 1 protocol ieee
bridge 1 priority 128
bridge 2 protocol ieee
bridge 2 priority 128

However I'm dubious if bridge is actually in PFC, not at least up-to PFC3, I'm not sure about PFC4 (SUP2T).

Finally you have option to use QinQ:

interface range GigabitEthernet0/4 , GigabitEthernet0/3
 switchport
 switchport access vlan 42
 switchport mode dot1q-tunnel
 switchport nonegotiate
!
interface range GigabitEthernet0/1 - 2
 switchport
 switchport access vlan 43
 switchport mode dot1q-tunnel
 switchport nonegotiate
!

In this option VLAN 123 that comes from Router1, gets VLAN 42 on top of it [ 42 123 ], MAC addresses from ALL Router1 VLANs are populated in VLAN 42 mac-address-table. So then MAC lookup is done against VLAN 42 where we only have traffic-manager, once we send the frame out to traffic-manager, we pop VLAN 42 out.
Now after traffic manager send it OUT, again in VLAN 123, it gets VLAN 43 on top of it [ 43 123 ], and as previously MAC lookup is done for table 43, where we only have Router2, frame is sent out towards Router2 and VLAN 43 is popped out.

By default STP is not tunneled like rest of the traffic, but STP BPDU is directly visible to the switch, and switch will react to it normally, this is often undesirable. If STP BPDU needs to be tunneled as well you need feature called 'Layer 2 Protocol Tunnel' or L2PT.
L2PT is fancy word for DMAC address rewrite, when incoming frame has DMAC identifying the frame as special BPDU, such as STP, you rewrite the DMAC to some non-special address, for STP BPDU DMAC is written ingress to 01-00-0c-cd-cd-d0 then in egress the 01-00-0c-cd-cd-d0 DMAC id again rewritten back to STP DMAC.
Configuration is as follows:

 l2protocol-tunnel cdp
 l2protocol-tunnel lldp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp

You can use 'show l2protocol-tunnel interface giga0/1' to see counters for both directions of the MAC rewrite 'encap' means real DMAC was written to 01-00-0c-cd-cd-d0 and 'decap' means 01-00-0c-cd-cd-d0 was written back to real DMAC.

switch#show l2protocol-tunnel  interface giga1/0/6
COS for Encapsulated Packets: 5

Port       Protocol Shutdown  Drop      Encapsulation Decapsulation Drop
                    Threshold Threshold Counter       Counter       Counter
---------- -------- --------- --------- ------------- ------------- -------------
Gi1/0/6    cdp           ----      ----       2674827        263832            0