Unfortunately I can't reload

e.maksyukov · ‎03-30-2017

Good day. I meet an issue with ASR 903 (RSP3) that I don't understand.

cisco ASR-903 (RSP3_400) processor

Cisco IOS XE Software, Version 03.18.02.SP.156-2.SP2-ext

I have an ethernet interface (A900-IMA8S1Z, cooper gigabit SFP) with configuration:

interface GigabitEthernet0/2/6
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 1309

I connect my laptop to this interface and check mac-address-table:

S7-05-CR903-T1#sh mac-address-table bdomain 1309

   Nile Mac Address Entries

   BD    mac addr        type     ports
   -----------------------------------------------
   1309 0087.3195.953f DYNAMIC Te0/0/2.tefp1
   1309 c81f.be46.930b DYNAMIC Te0/0/3.tefp1
   1309 c81f.bea3.f6d2 DYNAMIC Te0/0/4.tefp1
   1309 ec8e.b557.5e34 DYNAMIC Gi0/2/6.Efp1

Then laptop was disconnected and I got interesting mac-address-table:

S7-05-CR903-T1#sh int gi0/2/6
GigabitEthernet0/2/6 is down, line protocol is down
Hardware is A900-IMA8S1Z, address is 0087.3195.8918 (bia 0087.3195.8918)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

S7-05-CR903-T1#sh mac-address-table bdomain 1309

   Nile Mac Address Entries

   BD    mac addr        type     ports
   -----------------------------------------------
   1309 0087.3195.953f DYNAMIC Te0/0/2.tefp1
   1309 c81f.be46.930b DYNAMIC Te0/0/3.tefp1
   1309 c81f.bea3.f6d2 DYNAMIC Te0/0/4.tefp1
   1309 ec8e.b557.5e34 DYNAMIC Gi0/2/6.Efp1

Interface is down, but associated mac-address entry is in place. Why is it there? Isn't supposed it to be invalidated and removed?

What do I miss?

Austin Sabio · ‎03-30-2017

Because of MAC address aging time -default is 300 seconds- on the EFPs.

I hope this helps.

e.maksyukov · ‎03-31-2017

It's correct. But corresponding physical interface for that EFP is down. Can I somehow track state of physical interface and clear mac-addresses on that EFP if interface is down?

Austin Sabio · ‎03-31-2017

Yes. the switch module should automatically remove the mac-address of the disconnected node. I would advise to reload, upgrade the code and see if that helps.

e.maksyukov · ‎04-01-2017

Unfortunately I can't reload this device, some kind of production scheme. But I should note, after 300 seconds mac-address was aged out. But why had not it been deleted when physical interface link turned down.

Austin Sabio · ‎04-03-2017

Then, in this case, I would say the mac address learning is based on the efp (~service instance) not the physical interface - as its a logical interface connects a bridge domain to the physical port. also, is "service instance 1 ethernet" statement applied to more than one physical interface Gi0/2/6? referred as two service instances on same bridge domain. check with

ASR903# show ethernet service instance id 1 interface gigabitEthernet 0/2/6 detail

"To see MAC address information for bridge domains, use the show mac-address-table bdomain domain command. When an EFP property changes (bridge domain, rewrite, encapsulation, split-horizon, secured or unsecured, or a state change), the old dynamic MAC addresses are flushed from their existing tables. This is to prevent old invalid entries from lingering."

The mac learning action matrix is really helpful here.

Table 1 MAC Learning Actions

Scenario	Action
A bridge domain is created.	The MAC learning is enabled by default in point–to–multipoint bridge domains. The MAC learning is not supported in point–to–point bridge domains.
A bridge domain is deleted.	The MAC addresses learned on the bridge domain are removed from the software MAC address table that is maintained on the fabric cards. These MAC addresses are also removed from the line card hardware.
An EFP is added and is the first EFP on a bridge domain on a card.	All the MAC addresses learned on the bridge domain are sent to this new card.
An EFP is added and is not the first EFP on a bridge domain.	Nothing needs to be done as the MAC addresses learned on the bridge domain are already present.
An EFP is deleted.	All the MAC addresses learned on that EFP are deleted.
An EFP admin state is UP.	When the EFP is the first EFP on the bridge domain on the card, all the MAC addresses learned on the bridge domain are sent to this new card. When the EFP is not the first EFP on the bridge domain on the card, nothing needs to be done as the MAC addresses learned on the bridge domain are already present.
An EFP admin state is DOWN.	All the MAC addresses learned on that EFP are deleted.
The port goes down.	All the MAC addresses learned on the port on all the bridge domains are deleted.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-3s/asr903/b_layer2_ASR903.pdf

http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/ce/b_ce_xe-313s-asr920-book.pdf

http://www.cisco.com/c/en/us/td/docs/optical/cpt/r9_5/configuration/guide/cpt95_configuration/cpt93_configuration_chapter_01100.pdf

I hope this helps and clears up the confusion.

e.maksyukov · ‎04-04-2017

Thank you for fresh sight. I will research this approach. But it seems there is only one associated physical interface with this service instance.

CR903#show ethernet service instance id 1 interface gigabitEthernet 0/2/6 detail

Service Instance ID: 1
Service Instance Type: Static
Associated Interface: GigabitEthernet0/2/6
Associated EVC:
L2protocol drop
CE-Vlans:
Encapsulation: untagged
Interface Dot1q Tunnel Ethertype: 0x8100
State: Down
EFP Statistics:
   Pkts In   Bytes In   Pkts Out Bytes Out
       186      24558        272      17984
EFP Microblocks:
****************
Microblock type: Bridge-domain
Bridge-domain: 1309

Microblock type: L2Mcast
L2 Multicast GID: 6

Microblock type: dhcp_snoop
L2 Multicast GID: 6

ASR903 mac-address entry deletion from efp