Onverwachte mac entry op access-switch van Nexus switch

[GeleFles]

Ik ben bezig met het opschonen van de vlan's in ons netwerk, en daarbij loop ik tegen iets bijzonders aan.

We hebben 2 Cisco NEXUS switches als onze backbone, deze zijn door middel van een VPC met elkaar gekoppeld.

Op deze NEXUS switches zijn diverse 2960X stacks aangesloten, die allemaal een trunk hebben naar de nexus switches.

Op 1 access switchstack valt op dat er 1 mac adres aanwezig is in meerdere vlan's:

code:

accesswitch#sh mac address-table address 8c60.4fa1.20f8
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    8c60.4fa1.20f8    DYNAMIC     Po2
  96    8c60.4fa1.20f8    DYNAMIC     Po2
 110    8c60.4fa1.20f8    DYNAMIC     Po2
 113    8c60.4fa1.20f8    DYNAMIC     Po2
 143    8c60.4fa1.20f8    DYNAMIC     Po2
 144    8c60.4fa1.20f8    DYNAMIC     Po2
 145    8c60.4fa1.20f8    DYNAMIC     Po2
 149    8c60.4fa1.20f8    DYNAMIC     Po2

(dit is slechts een deel, maar er zijn 84 vlan's waar dit mac adres aanwezig is)

Po2 is de trunk naar de nexus switches.

Op de nexus switches komt dit mac adres niet naar voren in de show mac table, wat ik al vreemd vond.

Na wat speurwerk, blijkt het mac adres afkomstig te zijn van de vpc-link:

code:

NEXUS-02# sh int eth2/1
Ethernet2/1 is up
 Dedicated Interface

  Belongs to Po4
  Hardware: 40000 Ethernet, address: [b]8c60.4fa1.20f8[/b] (bia 8c60.4fa1.20f8)
  Description: vpc-link

Die Po4 is de vpc link tussen de 2 nexus switches, waarop ook alle vlan's gekoppeld zijn:

code:

interface port-channel4
  description vpc-link
  switchport mode trunk
  spanning-tree port type network
  speed 40000
  duplex full
  vpc peer-link

Nu is de vraag; waarom krijg ik dat mac adres terug in veel (dus niet alle) vlan's op mijn access switches, en hoe kan ik dat voorkomen?

Ik wil namelijk via een script inzichtelijk maken welke vlan's er allemaal 'leeg' zijn, zodat ze verwijderd kunnen worden.

[KoeKk]

Ik ben niet bekend met de exacte werking van Cisco's VPC links, maar dat maakt onder aan de streep toch niet uit?

Om te bepalen of de VLAN's leeg zijn kan je het Po4 mac adres negeren, dus dat zou je dan simpelweg in je script kunnen bouwen, niet? Dan is het simpelweg een kwestie van de mac adressen van alle VPC links verzamelen, in je script zetten in de 'ignore list' en klaar.

[jvanhambelgium]

Lijkt me normaal dat je deze vPC System-Mac en/of vPC Local System-Mac voor elke VLAN tegenkomt (tot) op je access-switches.
Op die access-switches heb je (per vlan) STP draaien zou ik denken.

Je zal in je script gewoon rekening moeten houden hiermee. Verder geen probleem toch?

[GeleFles]

Ik kan inderdaad in het script dit mac adres excluden, dat is geen probleem.

Ik was vooral benieuwd waarom ik dit mac adres zie, ik zou deze niet verwachten namelijk.
@jvanhambelgium we draaien MST als spanning tree protocol.

[KoeKk]

Als je MSTP draait zou het kunnen dat de VLAN's waar het mac adres niet op voorkomt ook niet in een MSTI gedefineerd zijn?

[Gravit0n]

GeleFles schreef op dinsdag 21 april 2020 @ 16:00:

Nu is de vraag; waarom krijg ik dat mac adres terug in veel (dus niet alle) vlan's op mijn access switches, en hoe kan ik dat voorkomen?

Heb je de VLANs waarin je dat MAC niet ziet wel op je VPC geconfigureerd (en dus niet enkel local op je access laag)?

[GeleFles]

Gravit0n schreef op donderdag 30 april 2020 @ 20:59:
[...]


Heb je de VLANs waarin je dat MAC niet ziet wel op je VPC geconfigureerd (en dus niet enkel local op je access laag)?

De VPC link is een full trunk, daarover gaan alle VLANs.
(In MST zijn ook alle VLANs netjes verdeeld over de instances)
Het wisselt ook een beetje met wanneer ik het mac adres zie, ik vermoed dat ie zich minder vaak meld dan dat de standaard mac age timer. (Dat maakte mijn script output ook zo vreemd)

Inmiddels opgelost door de VPC mac adressen te ignoren in mijn script, dus ik kan verder

Bedankt voor alle input!

[ Voor 5% gewijzigd door GeleFles op 01-05-2020 09:36 ]