I'm glad we figure it out. I didn't find any documentation regarding this behavior and I've not tested with other vendors, but it seems to be consistent with Cisco devices running IOS. Regards, ... View more

Hi Americo,   I got your point:    R4# show ip bgp BGP table version is 43, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network            Next Hop     Metric      LocPrf      Weight   Path *> 10.10.10.10/32 192.168.24.2  435200                   32768   i <--- Because of network command in R4 * i               192.168.13.1  409600        100            0   i *> 20.20.20.20/32 192.168.24.2  435200                   32768   i <--- Because of network command in R4 * i               192.168.13.1  409600        100            0   i *> 30.30.30.30/32 192.168.24.2  435200                   32768   i <--- Because of network command in R4 * i               192.168.13.1  409600        100            0   i   There are several things to notice to understand this scenario:   R1,R2,R3,R4 are in the same AS, so they are iBGP peers You're having equal path (from IGP perspective) to Lo1,Lo2 and Lo3 on R1 An iBGP router will not advertise a route learned from an iBGP peer to another iBGP peer unless you use the route reflector feature, or in this case, since that same router are already being learned through and IGP (EIGRP) then you can use the BGP network command and it will work because BGP will find a valid EIGRP route in the routing table. In this particular scenario you're using the network command under BGP on routers R1, R3, and R4 but not on R2. I would be interesting if you could check what happens when using the network command on routers R1, R2, and R3 but not on R4. On R4, the path that is not selected as the best path by BGP is the one that you actually learn this router from R3 with next hop 192.168.13.1 after using the network command on R3 for 10.10.10.10/32 and the other prefixes. The path that is selected as the best path by BGP is the one through 192.168.24.2 and is as a result of the network commands on R4 that is causing this path to have a higher Weight attribute (32768) as if it were a locally originated network (but with next hop different from 0.0.0.0 since we've valid routes learned through EIGRP). So the right question would be, why is R4 always selecting 192.168.24.2 as the next hop for those networks in R1 after using the network command for the same on R4 under BGP?    The answer seems to be that after issuing the network command under BGP router mode on R4 for those networks, BGP will always select as the next hop (between the posible paths) the lowest IP address.  I did change segment between R3 and R4 to be 192.168.14.0/24 so it would be lower when compared to 192.168.24.0/24 and this is what I got (I did clear BGP):   R4#sh ip bgp BGP table version is 4, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network                 Next Hop        Metric   LocPrf         Weight Path *> 10.10.10.10/32 192.168.14.3 131072                     32768 i  <----- Next hop is R3 * i                          192.168.13.1 130816  100                     0 i *> 20.20.20.20/32 192.168.14.3 131072                     32768 i  <----- Next hop is R3 * i                          192.168.13.1 130816  100                     0 i *> 30.30.30.30/32 192.168.14.3 131072                     32768 i  <----- Next hop is R3 * i                          192.168.13.1  130816 100                     0 i R4#   I then changed the network segment between R2 and R4 to be 192.168.11.0/24 and R4 did choose R2 again (192.168.11.2 in my test) as the next hop.   I hope this helps. ... View more

Hello pp1001,   I hope you're doing well.   In that same document you've to important definitions:     Forwarding Engine Driver (FED): This is the heart of the Cisco Catalyst 3850 Series Switch and is responsible for all hardware programming/forwarding. IOSd: This is the Cisco IOS daemon that runs on the Linux kernel. It is run as a software process within the kernel. The idea with switches is to process the  traffic at the hardware level (using the ASICs) when possible. Is that's not possible, then traffic is punted to the Control Plane/CPU so it can be processed . IOSd resides at the control plane. So, in the snippet below we have that the packets received from ASIC ( for RXQ 16) are being sent to the IOSd (CPU/Control plane). If the packets were not being sent to the CPU (because of those being processed in hardware depending on the type of traffic and the ASIC capabilities) then those counters should be at zero.   When FED cannot send the packets to IOSd, then the Send to IOSd failed count will increase and the switch will suspend sending those packets to IOSd for a while to then try to send those again (unsuspend). So, the value of these counters will depend on the particular scenario that you're troubleshooting regarding the type of traffic, the rate and the amount of traffic that is hitting the switch, and the capacity of the CPU to handle all that. It could be expected to see values different from zero but you will need to determine the source of the traffic and if the values of these counters are increasing or not (by checking the output multiple times) to then determine how to proceed.     RX (ASIC2CPU) Stats (asic 0 qn 16 lqn 16): RXQ 16: CPU_Q_PROTO_SNOOPING ---------------------------------------- Packets received from ASIC     : 79099152 <------- Send to IOSd total attempts    : 79099152 <------- Send to IOSd failed count      : 1240331 <------- RX suspend count               : 1240331 <------- RX unsuspend count             : 1240330 <------- RX unsuspend send count        : 1240330 <------- RX unsuspend send failed count : 0 RX dropped count               : 0 RX conversion failure dropped  : 0 RX pkt_hdr allocation failure  : 0 RX INTACK count                : 0 RX packets dq'd after intack   : 0 Active RxQ event               : 9906280 RX spurious interrupt          : 0   I hope this helps.   Regards,   ... View more

Hi Qus83,   So, is the connection between the two sites a Layer 2 MPLS?   If so, you could have a trunk between the two sites so you can pass traffic for multiple VLANs:   Site_A_SW-------Trunk-------L2 MPLS-------Trunk-------Site_B_SW   Then, if you want devices in VLAN 120 to communicate with devices in a different/new VLAN (let's say VLAN 102) you could configure VLAN SVIs on those switches so you can have inter-VLAN routing:   Site_A_SW# configure terminal Site_A_SW(config)# interface vlan 120 Site_A_SW(config-if)# ip add <ip_address> <network_mask> Site_A_SW(config-if)# no ip redirects Site_A_SW(config-if)# no ip directed-broadcast Site_A_SW(config-if)# exit Site_A_SW(config)# interface vlan 102 Site_A_SW(config-if)# ip add <ip_address> <network_mask> Site_A_SW(config-if)# no ip redirects Site_A_SW(config-if)# no ip directed-broadcast   Can do the same on Site_B_SW. In that way you'll have the new VLAN to reduce the broadcst domain and devices in each VLAN should be able to communicate using inter-VLAN routing if their default-gateway is set to the IP address configured for the VLAN they belong to.   I hope this helps.   Regards,   ... View more

Hello Tukaram,   This question is not clear at all. Can you explain better what you're trying to achieve and the results that you're getting?   Regards, ... View more

Hello Hanish,   You're not having (by default) any Access Control List (ACL) applied to the VLAN SVIs (Layer 3 VLAN interfaces), so all the VLANs configured on the switch and having a VLAN SVI should be able to communicate with any other VLAN with the same settings on the switch (Inter-VLAN routing). This is something that you can test by running the folllowing commands on the switch:   ping 172.16.21.10 source vlan 20 ping 172.16.22.10 source vlan 20 ping 172.16.23.10 source vlan 20   Also, you're already having IP routing enabled. So, the only thing that seems to be missing is a default route (required after enabling IP routing):   switch# configure terminal switch(config)# ip route 0.0.0.0 0.0.0.0 <ip_address_default_gateway> switch(config)# end switch#wr   The <ip_address_default_gateway> should be the IP address of the device (Router, Firewall) that will be routing the traffic to other networks not configured on the switch and to the Internet (in which case that device should be also performing NAT/PAT). That IP address should be within the same segment of the network for VLAN 20, or 21, or 22, or 23.   So, more than access-list, what you´re missing is the default route, although that next hop (the default-gateway) might have configured ACLs in which case you will need to add the rules on that device and not on the switch.   I hope you find this information useful.   Regards,   ... View more

Are you teaming those two NIC cards/Ports on the server? does the server support STP BPDUs and/or etherchannel?   One option would be to configure those two interfaces on the switch as a port-channel if the server supports that (LACP or without negotiation - mode on). The other option would be, if the server supports dot1q encapsulation and STP, to configure those interfaces on the switch as trunk interfaces without portfast and bpdu-guard so the switch can block one of the ports. However, since you're already having BPDU guard, I don't think the server could be sending BPDUs because that would cause the interfaces to go into err-disabled and that's not happening, right?   Regards, ... View more

NX-OS is a different NOS for a different set of plaforms (Nexus devices).   However, this can also apply to IOS-XE. Can you share the output of the show process cpu history command?   There are cases in which an SNMP server is polling the switch agressively from time to time causing CPU spikes.   That can be determined by configuring a EEM script and checking the process causing those spikes:   configure terminal process cpu threshold type total rising 80 interval 60 switch 1 event manager applet HIGH_CPU authorization bypass  event syslog pattern "%CPUMEM-5-RISING_THRESHOLD" maxrun 300  action 1.0 syslog msg "High CPU detected"  action 2.0 cli command "enable"  action 2.1 cli command "terminal len 0"  action 2.5 cli command "show clock | append flash:CPUlog.txt"  action 3.0 cli command "show process cpu sorted | append flash:CPUlog.txt"  action 4.0 cli command "show processes cpu detailed process iosd sort | append flash:CPUlog.txt"  action 5.0 cli command "show processes cpu detailed process fed sort | append flash:CPUlog.txt"  action 6.0 cli command "show platform punt statistics port-asic 0 cpuq -1 direction rx | append flash:CPUlog.txt"  action 7.0 cli command "show platform punt statistics port-asic 1 cpuq -1 direction rx | append flash:CPUlog.txt"  action 7.1 cli command " show snmp stats oid  | append flash:CPUlog.txt"  action 8.0 cli command "show logging | append flash:CPUlog.txt"  action 8.5 cli command "terminal len 24"  action 9.0 syslog msg "HIGH_CPU EEM Script finished running"  action 9.5 cli command "end"  end ! The previous script, supossing that you're having a standalone switch or that switch 1 in a stack is the current active unit. If not, adjust the switch id accordingly.   Once the EEM script triggers, you will need to check the contents of the generated CPUlog.txt file in flash memory.   Please let me know if you find this information useful.   Regards, ... View more

Hello Clare,   Are all the ports showing in the logs trunk ports?  Can you share the configuration of some of those?   Make sure you're not having spanning-tree portfast on any of the trunk ports.   You can track those host by using the following command:   show mac add add bc30.5bd7.46cb <--- for example   Then, if you're having a switch connected to the interfaces showing in the MAC flapping notification, connect to that switch and run the same command. Repeat until you find that the output reports and access port instead of a trunk port. You might need to run the command a couple of times on each switch just to make sure that you're not getting a different interface everytime.   Regards, ... View more

Hello, are you referring to the following command?   show interfaces GigabitEthernet X/Y/Z mac-accounting   It requires the ip accounting mac-address to be configured at interface configuration level.   And the output is like this:   router#show interfaces GigabitEthernet X/Y/Z mac-accounting GigabitEthernetX/Y/Z Input(494 free) 0000.0c5d.92f9(58 ): 1 packets, 106 bytes, last: 4038ms ago 0004.c059.c060(61 ): 0 packets, 0 bytes, last: 2493135ms ago 00b0.64bc.4860(64 ): 1 packets, 106 bytes, last: 20165ms ago 0090.f2c9.cc00(103): 12 packets, 720 bytes, last: 3117ms ago Total: 14 packets, 932 bytes Output (511 free) 0090.f2c9.cc00(103): 8 packets, 504 bytes, last: 4311ms ago Total: 8 packets, 504 bytes   Regards, ... View more