ACLs

One of the things people always think about then they add security acls is to ensure that telnet or ssh still works. But if you adding acls to act as a lightweight firewall, you may forget something like TACACS which can be really nasty if you use command authorization, also don't forget logging, snmp, tftp and any protocol you use to manage the box. If you happen of have a standard firewall rule set use that, if you done create one. Net of this is don't forget ALL the management protocols when you are adding acls, OR you can use an SVI that is not part of the address space you are protecting or add a new SVI and change the default route to bypass your ACL when you manage the box. Just adding a new SVI does not help if the default route points to the original SVI

Old and new nexus cards dont like each other

It seems that when you have a mix of N7K-M132XP-12 and N7K-M132XP-12L you have to do an force command in order to have a port on the 12L join and etherchannel with older 12 cards. You have to preconfig all the vlans (generally make the new interface look like the port channel) to get the thing to work. Clunky

old loopbacks never die.

Back in the old days many people would configure their loopbacks as /30s because we were told that /31 and /32 were not valid subnet masks. It is true that OSPF should have cured this (a loopback interface is always advertised as a /32 unless you change the OSPF network type.  BUT one day I happen to see

Jul 23 11:46:53 CDT: %OSPF-4-CONFLICTING_LSAID: Process 100 area dummy area: LSA
origination prevented by LSA with same LSID but a different mask
Existing Type 5 LSA: LSID 10.120.0.216/30
New Destination: 10.120.0.216/32

Turns out someone had configured a loopback address of 10.120.0.218/30 and in a different box 10.120.0.216/32 creating the situation above. I found the boxes by doing sho ip bgp <prefix> <mask> then check the AS number table. Now have to just change the subnet mask of the 10.120.0.218 interface and all will be well