Adj resolve request: Failed to resolve… [ Cisco 3750X ]

After a migration to a pair of 3750Xs I was getting a bunch of disconcerting ARP errors in the logs. After a bit of digging, this appears to be a known bug. Error message content examples are shown below:

Nov  4 12:41:00: %ADJ-3-RESOLVE_REQ: Adj resolve request: Failed to resolve Vlan21
Nov  4 12:41:18: %ADJ-3-RESOLVE_REQ: Adj resolve request: Failed to resolve Vlan28

This was fixed/worked around with:

no ip cef optimize neighbor resolution

TACACS on 4431 Management Interface

Getting TACACs working via the Cisco 4431 Management interface threw up a few issues and took a few tweaks. The final issue I found was that referencing all servers with the tacacs+ keyword doesn’t work, you have to reference the TACACS group with the servers defined within it.

Below is a working configuration example for TACACs via the management port in the Mgmt-intf vrf. I’ve also included a non-exhaustive couple of examples to get a few other things working.

! Mgmt interface config
interface GigabitEthernet0
 description ** Mgmt intf **
 vrf forwarding Mgmt-intf
 ip address
 negotiation auto
! Default route for Management VRF
ip route vrf Mgmt-intf
! Define source interface at global level
ip tacacs source-interface GigabitEthernet0
! aaa config
aaa new-model
! Server-private restricts only within this VRF.
! VRF forwarding and source interface need to be configured
! within the aaa group context too.
aaa group server tacacs+ TACACS
 server-private key MYKEY
 server-private key MYKEY
 ip vrf forwarding Mgmt-intf
 ip tacacs source-interface GigabitEthernet0
! Fail to enable password if TACACS is not working in this config.
aaa authentication login REMOTE_ACCESS group TACACS enable
aaa authentication enable default group TACACS enable
aaa accounting exec REMOTE_ACCESS
 action-type stop-only
 group TACACS
aaa accounting commands 15 REMOTE_ACCESS
 action-type stop-only
 group TACACS
aaa session-id common
! Apply to vtys and console if you need to.
line vty 0 4
 accounting commands 15 REMOTE_ACCESS
 accounting exec REMOTE_ACCESS
 login authentication REMOTE_ACCESS
line vty 5 15
 accounting commands 15 REMOTE_ACCESS
 accounting exec REMOTE_ACCESS
 login authentication REMOTE_ACCESS


logging source-interface GigabitEthernet0 vrf Mgmt-intf
logging host vrf Mgmt-intf

TFTP (auto write after wr mem)

ip tftp source-interface GigabitEthernet0

 path tftp://$h-

SNMP Traps

snmp-server trap-source GigabitEthernet0
snmp-server host vrf Mgmt-intf version 2c MYCOMMUNITY

Recovering a Cisco 3850 that’s stuck in Boot Loop/ROMMON

This wasn’t even after an upgrade, just a reload, but the below messages were displayed before an unmounts and reboot of the switch:

Last heartbeat 0.00 secs ago

PID: 9225
Exit code: signal 11 (no core)

Quick steps:

1) Set up a local switch with the correct image on is as a tftp server to expedite fix as tftp is painful.

tftp-server flash:[image-name.bin]

2) Configure an interface with an IP to allow for direct connection to the management port of the broken switch.

interface GigabitEthernet1/0/47
 description -= temp for tftp to other switch =-
 no switchport
 ip address

3) Connect (or ask someone on site to connect) the interface to the management port of the broken switch (duh!)

4) On broken switch, hold MODE for 10 seconds to interrupt boot loop, or just wait for 5 or so failures for it to drop to ROMMON.

5) Set up IP info. GW only necessary if you’re tftping from a server outside the local subnet.

switch: set IP_ADDR

switch: set DEFAULT_ROUTER

6) Check for emergency files (you’re looking for cat3k_caa-recovery.bin or similar.

switch: dir sda9:

7) Ping the tftp server

switch: ping
ping with 32 bytes of data ...
Up 1000 Mbps Full duplex (port  0) (SGMII)
Host is alive.

8) Start the tftp emergency install. On a local connection this will take 10-20 mins.

switch: emergency-install tftp://
The bootflash will be erased during install operation, continue (y/n)?y
Starting emergency recovery (tftp://
Reading full image into memory......................done
Nova Bundle Image
Kernel Address    : 0x6042e5d8
Kernel Size       : 0x31794f/3242319
Initramfs Address : 0x60745f28
Initramfs Size    : 0xdbec9d/14412957
Compression Format: .mzip

Bootable image at @ ram:0x6042e5d8
Bootable image segment 0 address range [0x81100000, 0x81b80000] is in range [0x80180000, 0x90000000].
File "sda9:cat3k_caa-recovery.bin" uncompressed and installed, entry point: 0x811060f0
Loading Linux kernel with entry point 0x811060f0 ...
Bootloader: Done loading app on core_mask: 0xf

### Launching Linux Kernel (flags = 0x5)

Initiating Emergency Installation of bundle tftp://

Downloading bundle tftp://

Validating bundle tftp://
Installing bundle tftp://
Verifying bundle tftp://
Package cat3k_caa-base.SPA.03.03.03SE.pkg is Digitally Signed
Package cat3k_caa-drivers.SPA.03.03.03SE.pkg is Digitally Signed
Package cat3k_caa-infra.SPA.03.03.03SE.pkg is Digitally Signed
Package cat3k_caa-iosd-universalk9.SPA.150-1.EZ3.pkg is Digitally Signed
Package cat3k_caa-platform.SPA.03.03.03SE.pkg is Digitally Signed
Package cat3k_caa-wcm.SPA. is Digitally Signed
Preparing flash...
Syncing device...
Emergency Install successful... Rebooting
Restarting system.

Once this is done it’ll try and boot again. You need to disable manual boot.

The system is not configured to boot automatically.  The
following command will finish loading the operating system


switch: set MANUAL_BOOT no
switch: boot

Also remember to change the confreg value if it’s not 0x102 on the 3850. In this case it wasn’t needed. (show version last line)

Configuration register is 0x102

Don’t forget to remove the tftp-server config and temporary stuff. :)

GRE over IPSEC between Juniper and Cisco Router

This caused headaches as it needed slightly different configuration to normal. ip mtu not being set here was the cause of things sort-of-but-not-quite-working.

Normally with Cisco to Cisco over IPSEC we’d add “ip tcp adjust mss-1392” to the Tunnel interfaces either side.

This is the config that worked in the end.

GRE Juniper router side

interfaces {
    lo0 {
        unit 0 {
            family inet {

    gr-1/1/10 {
        unit 2 {
            description "-= Gre Tunnel to Remote Office =-";
            tunnel {
            family inet {
                mtu 1400;

    static {
        route next-hop [IPSEC FW Addr];


GRE Cisco Side

interface Loopback1
 description * Loopback for GRE Tunnel source/endpoint *
 ip address

interface Tunnel2
 description * GRE Tunnel to Juniper GR-1/1/10.2 *
 ip address
 ip mtu 1400
 load-interval 30
 tunnel source Loopback1
 tunnel destination
 hold-queue 2000 in
 hold-queue 2000 out

! Route GRE endpoint via IPSEC FW
ip route [IPSEC FW Addr]

Reference config for normal Cisco – Cisco.

interface Tunnel2
 description * GRE Tunnel to Remote site int tunnel2 *
 bandwidth 2000
 ip address
 ip tcp adjust-mss 1392
 load-interval 30
 tunnel source Loopback1
 tunnel destination
 hold-queue 2000 in
 hold-queue 2000 out

Cisco ASA denying traffic between interfaces despite correct policy

After a bit of head-scratching and frustration, I found an issue on a Cisco ASA (v9.1) with the configuration that has caught me out twice previously. I felt like a bit of an idiot for not clicking sooner.

Basically the policy was allowing “icmp any any” both sides along with the connection traffic from the specific external to internal interfaces, however the logs were showing denials:

Inbound TCP connection denied from A.B.C.D/53112 to W.X.Y.Z/443 flags SYN  on interface Ext-2
Deny inbound icmp src Ext-2:A.B.C.D dst Ext-1:W.X.Y.Z (type 8, code 0)

The issue here was that both interfaces were configured with the same security-level. This is a hangover from the old PIX days where this kind of communication was denied by default. The policy doesn’t seem to matter.

The fix in this case was that the security-level on the “dirty” interface was lowered to a more appropriate value. To allow ACLs to control communications between same-level interfaces, the following command can be used:

same-security-traffic permit inter-interface