I am having difficulty getting the User tracking for IP Phones to work correctly in Ciscoworks LMS 3.2. Callmanager is version 7.1.5.10000-12.  Campus manager version is 5.2.1 The Callmanager publisher and two subscribers are all showing as application servers with green icons under the topology services view. The callmanagers show as CDP neighbours on the switches to which they are connected. I can do an SNMP walk of the ccmPhoneTable from the Ciscoworks devicecenter and get a ton of returned data. The IP phones are discovered as end hosts and have mac address and IP address info when checked in the User Tracking utility. Callmanager sysObjectID = OID: CISCO-PRODUCTS-MIB::ciscoMCS7835I Any help you could give with troubleshooting would be greatly appreciated. Regards Rob ... View more

I was just auditing my Internet router configuration against the NSA Router Security Configuration Guide and came across the old entries below. access-list 100 deny   53 any any access-list 100 deny   55 any any access-list 100 deny   77 any any access-list 100 deny   pim any any I remember applying them in the dim dark past and tracked it down to this advisory "Cisco IOS Interface Blocked by IPv4 Packets". Clearly they've just been propagated when then router and IOS get upgraded. My question is should we remove all the old workarounds, and how often do people audit their configs ? Anything after 12.3 is not vulnerable, so it could safely be removed, but then it doesn't really hurt to leave them since we aren't expecting any of those protocols to be coming from the internet.  There is always the possibility that someone will just copy it to a router with an older vulnerable IOS. Obviously there will be a small amount of additional processing overhead on the acl too. All comments are welcome. ... View more

I'm hoping someone can help me with the maths to reconcile what I've observed on our routers  on a tunnel interface.  The maximum amount of data I can get across the tunnel is 1339 bytes, which seems just a little bit too small. Background: we have two 3845 routers with IOS 12.4(3a) advanced ip services. I have tunnel interfaces on both routers, interface configs are below. crypto ipsec transform-set MY_TSET esp-3des esp-sha-hmac comp-lzs crypto ipsec profile MY_VTI set transform-set MY_TSET interface Tunnel7 ip address 10.1.40.134 255.255.255.252 tunnel source 10.252.0.14 tunnel destination 10.252.0.18 tunnel mode ipsec ipv4 tunnel path-mtu-discovery tunnel protection ipsec profile MY_VTI end interface Tunnel3 ip address 10.1.40.133 255.255.255.252 tunnel source 10.252.0.18 tunnel destination 10.252.0.14 tunnel mode ipsec ipv4 tunnel path-mtu-discovery tunnel protection ipsec profile MY_VTI end When I test the mtu of the source destination interfaces I get 1500 bytes, as you would expect from an ethernet connection to a service providers MPLS network. See output below. Router1#ping ip 10.252.0.18 df-bit size 1500 Type escape sequence to abort. Sending 5, 1500-byte ICMP Echos to 10.252.0.18, timeout is 2 seconds: Packet sent with the DF bit set !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms Router1#ping ip 10.252.0.18 df-bit size 1501 Type escape sequence to abort. Sending 5, 1501-byte ICMP Echos to 10.252.0.18, timeout is 2 seconds: Packet sent with the DF bit set ..... Success rate is 0 percent (0/5) When I test the mtu of the tunnels I get 1339 bytes, see the output below. router1#ping ip 10.1.40.133 df-bit size 1340 Type escape sequence to abort. Sending 5, 1340-byte ICMP Echos to 10.1.40.133, timeout is 2 seconds: Packet sent with the DF bit set M.M.M Success rate is 0 percent (0/5) router1#ping ip 10.1.40.133 df-bit size 1339 Type escape sequence to abort. Sending 5, 1339-byte ICMP Echos to 10.1.40.133, timeout is 2 seconds: Packet sent with the DF bit set !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/31/36 ms Now when we do the maths on the packet size I get the following 20 bytes    - IP header for ESP packet 8 bytes      - ESP header 8 bytes      - 3-DES IV 20 bytes    - ip header for GRE encapsulation 4 bytes      - GRE header 1339 bytes - original ip/icmp echo  data 5 bytes      - 3DES padding to make it a multiple of 8 bytes (20+4+1339+5)/8 = 171 8byte blocks 2 bytes      -  padding to ensure ESP trailer alignment ends on a 4 byte word 1 byte        - ESP trailer pad length field 1 byte        - ESP trailer next header field 12 bytes    - ESP auth information as per RFC2404 That comes to a total of 1420, which is 80 bytes short of the mtu of the source/destination interface of the tunnel. Can anyone help explain where things are going wrong, either with my maths or the router config. Regards Rob ... View more