Port 15/2 on Cat 6513

[cning99]

Hello,We are using Cat 6513 still running hybrid mode.When I used "sho cam" command to trace a specific computer's connecting port,I got the following results:

CAT6513> (enable) sho cam 0011.25ab.dd75

* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.

X = Port Security Entry $ = Dot1x Security Entry

VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]

---- ------------------ ----- -------------------------------------------

333 00-11-25-ab-dd-75 4/18 [ALL]

20 00-11-25-ab-dd-75 15/2 [ALL]

3 00-11-25-ab-dd-75 15/2 [ALL]

10 00-11-25-ab-dd-75 15/2 [ALL]

Total Matching CAM Entries Displayed =4

CAT6513> (enable)

I know the first line indicates the connecting port,but how come there are other 3 results with diffrent vlan point to port 15/2?What's what I could understand,could anyone explain to me?

Thanks a lot

[t.hadarson]

Hello,

I think this is the port to the MSFC card on the supervisor. If you use show module you'll se all slots and connected cards.

Tony

[cning99]

Thanks Tony for your reply.Yes,I know module 15 is to MSFC,but first of all, 15/1 should be the one,not 15/2.When I do a "show port 15/2",I got errors.

Secondly,I had never seen this before(I mean show cam command gave me multiple results point to 15/2),does it indicate any problem?

thanks

[Georg Pauwen]

Hello,

you might want to check if this bug applies to you:

CSCsb07680 Bug Details

Headline CAM learn 15/2 by non-routable packet when fallback bridging is enabled

Symptom:

The problem is that the mac address learned by non-routable packet will be pointing

to 15/2 on supervisor and the connectivity to VLAN interface where fallback bridging

configured is lost. Once shut/no shut affected VLAN interface the connectivity is

restored, but the problem will occur again after reloading MSFC.

Conditions:

Catalyst 6500 hybrid system with Sup1a/MSFC1.

CatOS 6.4(16) / IOS 12.1(26)E1.

CatOS 7.6(11) / IOS 12.1(26)E1.

Fallback bridging is configured on VLAN interface on MSFC.

The problem does not occur with Sup2/MSFC2.

Workaround:

Enable CDP on affected VLAN interface on MSFC resolves this issue but the reason is

under investigating.

Regards,

GP