verfiy firewall rules with telnet

Often you need to check does a firewall rule work. You can do this with telnet to the port number but you have to remember that the source interface used by the telnet will be the IP address of the next hop interface. In some versions of ios you can put a /source in the telnet command then if your firewall rule is an entire subnet you can at lest test TCP connections see below for a working example woodridge1-mdf-rsw1>telnet 174.137.37.108 14002 /source vlan200 Trying 174.137.37.108, 14002 ... Open myMethod=keepAlivemyMethod=keepAlivemyMethod=keepAlivemyMethod=keepAlivemyMethod=keepAlive^CmyMethod=keepAlivemyMethod=keepAlive^C

IP addresses in links part of an MLPPP bundle

You can put (with your carrier) ip addresses on individual links in an MLPPP bundle. It is useful to test those links for errors with pings. But they do not show up in the routing table as connected routes. This seems to be normal behavior, and perhaps you can put static routes to the interface in at the cost of more stuff in the routing table you may not use much. the ip address on the multink interface is what shows up in routing https://supportforums.cisco.com/thread/2068848 has the reference

Nexis 7k drops on the M1 card are for the ENTIRE asyc

Got a call that there was a spike in output drops on a nexus 7K M1 card. the odd thing was there were 3 port channels with the EXACT same number of drops. looking further there were only 1 port per port channel with drops and again they were all the same. It then occured to me to look at the port to ASIC chart and all 3 ports were using the same ASIC. While we still have a case with cisco, looks like output drops are counted at the ASIC level not the port level. Also seemed like having a running monitor port in that ASIC had a lot do with the drops in the first place. sho int counter error shows the deal -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- mgmt0 0 0 -- -- -- -- Eth1/1 0 0 0 0 0 0 Eth1/2 0 0 0 0 0 11285742206 Eth1/3 0 0 0 0 0 0 Eth1/4 0 0 0 0 0 11285742206 Eth1/5 0 0 0 0 0 0 Eth1/6 0 0 0 0 0 11285742206 Eth1/7 0 0 0 0 0 0 Eth1/8 0 0 0 0 0 11285742206 Eth1/9 0 0 0 0 0 0 also policy maps on the interfaces glic-core-rsw1# sho policy-map int e 1/4 Global statistics status : enabled Ethernet1/4 Service-policy (queuing) input: default-in-policy SNMP Policy Index: 301991953 Class-map (queuing): in-q1 (match-any) queue-limit percent 50 bandwidth percent 80 queue dropped pkts : 0 Class-map (queuing): in-q-default (match-any) queue-limit percent 50 bandwidth percent 20 queue dropped pkts : 565 Service-policy (queuing) output: default-out-policy SNMP Policy Index: 301991962 Class-map (queuing): out-pq1 (match-any) priority level 1 queue-limit percent 16 queue dropped pkts : 0 Class-map (queuing): out-q2 (match-any) queue-limit percent 1 queue dropped pkts : 0 Class-map (queuing): out-q3 (match-any) queue-limit percent 1 queue dropped pkts : 0 Class-map (queuing): out-q-default (match-any) queue-limit percent 82 bandwidth remaining percent 25 queue dropped pkts : 11731496978 glic-core-rsw1#

not all maps are alike

I am used to using route maps for a lot of things so I am very used to a route-map fred permit 10 what to do syntax. BUT when you do an access-map for a VACL there is no permit or deny in the access-map statement SO you have to always put in an acl reference. That being said, I am of the mind to not be cute and just use a single extended ACL in 1 access-map statement so you are not trapped in the route map logic and say close to the traditional security acl syntax

PVST+ HP swtiches

You can connect PVST swtiches to MST swtiches. What happens is that PVST has its own MAC address that the HP swtiches to not listen to, so PVST BPDUs go all they way between the two PVST domains while the MST cloud ignores them. The issue is that the native VLAN must match on the PVST trunk interfaces. The question is how do the swtiches know? As it truns out, PVST BPDUs include a TLV that has the native VLAN number that is how a mismatch is detected. Net of this is that ensure that native VLANs match when you connect PVST switches over a 'cloud' of non PVST swtiches or better yet do to that at all. The reference is at http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml Troubleshooting Spanning Tree PVID- and Type-Inconsistencies