All 0100.0ccc.cccc STATIC CPU This MAC is used for L2 protocols such has CDP, VTP, DISL, PAgP, , UDLD (https://quickview.cloudapps.cisco.com/quickview/bug/CSCsw80664) All 0100.0ccc.cccd STATIC CPU (SSTP BPDU) for native VLAN / PVST+ native VLAN is send a second time tunneled over IEEE 802.1q using special multicast MAC (https://cciethebeginning.wordpress.com/2008/10/15/differences-between-pvst-and-pvst/) All 0180.c200.0000 STATIC CPU (IEEE BPDU) Spanning Tree Protocol (for bridges) IEEE 802.1D) or DMAC "the Nearest Customer Bridge group MAC address; propagation constrained by customer bridges; this gives the same coverage as a customer-customer MACSec (IEEE Std 802.1AE) connection." (note: LLDP packets with mac 0180.c200.0003 or 0180.c200.0000 will be dropped and not learnt.) All 0180.c200.0001 STATIC CPU Ethernet flow control (Pause frame) IEEE 802.3x All 0180.c200.0002 STATIC CPU LACP Multicast / Ethernet OAM Protocol IEEE 802.3ah or "the Nearest non-TPMR (Two-Port MAC Relay) bridge group MAC address; propagation constrained by all bridges other than TPMRs; intended for use within provider bridged networks" All 0180.c200.0003 STATIC CPU DMAC "the Nearest non-TPMR (Two-Port MAC Relay) bridge group MAC address; propagation constrained by all bridges other than TPMRs; intended for use within provider bridged networks." (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvj43529/?referring_site=ss&dtid=osscdc000283) (note: LLDP packets with mac 0180.c200.0003 or 0180.c200.0000 will be dropped and not learnt.) All 0180.c200.0004 STATIC CPU All 0180.c200.0005 STATIC CPU All 0180.c200.0006 STATIC CPU All 0180.c200.0007 STATIC CPU All 0180.c200.0008 STATIC CPU Spanning Tree Protocol (for provider bridges) IEEE 802.1AD (https://learningnetwork.cisco.com/thread/38323) All 0180.c200.0009 STATIC CPU All 0180.c200.000a STATIC CPU All 0180.c200.000b STATIC CPU All 0180.c200.000c STATIC CPU All 0180.c200.000d STATIC CPU All 0180.c200.000e STATIC CPU DMAC "The Nearest bridge group MAC address; propagation constrained to a single physical link; stopped by all types of bridge." All 0180.c200.000f STATIC CPU All 0180.c200.0010 STATIC CPU All ffff.ffff.ffff STATIC CPU
01-80-C2-00-00-21 GARP VLAN Registration Protocol (also known as IEEE 802.1q GVRP) 01-80-C2-00-00-30 - 01-80-C2-00-00-3F Ethernet CFM Protocol IEEE 802.1ag All 0100.0CCC.CCCC STATIC CPU = DTP / CDP / VTP ALL 0100.0CCC.CCCD STATIC CPU = Non-Native VLAN BPDU & Cisco Shared Spanning Tree Protocol Address 01-00-5E-xx-xx-xx 0x0800 IPv4 Multicast (RFC 1112) (01-00-5E-00-00-00 - 01-00-5E-7F-FF-FF) 33-33-xx-xx-xx-xx 0x86DD IPv6 Multicast (RFC 2464) 01-1B-19-00-00-00, or 01-80-C2-00-00-0E (0x88F7) Precision Time Protocol (PTP) version 2 over Ethernet (layer-2)
... View more
NOTE: I went to 9.9.2-18 ( and some testing with 9.9.2-25)
I'm seeing spotty effects with SNMP THROUGH VTI-BGP.
Desgin: two separate EIGRP Pools internal : VTI_BGP on firewalls (5506 & 5545) between them.
BGP and EIGRP redistribute.
Effect #1 : SNMP to the MDF switch (direct connected by copper) : The SNMP works RIGHT UP until the BGP session flaps.
WAN flap happens, the BGP session goes down and comes back up (only down 1 minute from ISP latency or such) ....When BGP comes back EIGRP shows the route timer reset to 00:00 .....SNMP DOES NOT WORK NOW:
WORK AROUND : change the IP address(es) we send SNMP toward a DIFFERENT ip address on the same switch: ie. if you have two loop back you just move to the OTHER loopb and the SNMP starts reporting again. HAPPENS again, change back to the Other Loopb and it comes right back.
I've Always seen SNMP as "session-Less" traffic because it is UDP 161 traffic so why would it be affected by a flap.
BUT I'm open to learning more : IS SNMP actually sessionful and it's just initiated with sessionless udp 161 ?
Effect 2: SNMP fails on firewall's Inside IP : Take out "management-interface inside" and then put it back right away....SNMP starts working again: this one bothers me less....but still a quirk.
... View more
I too am considering adjust-mss on an LACP facing a WLC.
I noted that you cannot apply to the LACP (int Po1 )
I've TAC'd and they've explained that it should not applied on virtual interfaces.
I'm tempted to apply at the physical ports in the Po1 : but I've seen the port channel go down when the physical interface have anything on them that are not applied from the int Po1>
Any input here would be appreciated.
in answer to the "why" questions: i use GRE through ipsec. we must resize to accommodate the L3/Gre/IpSec header size. as you will find in 16.3.x you can apply an Adjust-Mss at the GRE, but (based on what TAC tells me) it does not actually resize / fragment anything. When encountering a server that was set to try jumbo packets and not resize its own mss (Linux box) we found that it lost traffic. When reviewing PCAP we found that the traffic (too big) arrived at the GRE and was dropped. The Switch did NOT send notification of the drop back to the apache system and so it was not re-transmitted. This manifested as www surfing on the machine reported as "lost"
Fix I decided was adjusting MSS at a L3 link between the server system and the desktop.
... View more
upgrade to get away from one bad issue : CSCva03272
and end up with a worse, and more visible issue: CSCuz88403
Issue Was: EIGRP / ECMP through GRE fails to work correctly on 3850's using 3.7.5
TAC advised moving to 16.3.x on our 3850's
Issue NOW is: HTTPS / WLC portal management no longer works.
ETA for resolution has not been offered.
How many people here are also having portal issues / WLC issues with 16.3.x ?
When is 16.3.4 due and WILL IT ADDRESS this very annoying bug?
... View more