“show interface trunk” weirdness in 3.3(5)

Update: This has been confirmed and new bugID CSCti69374 has been created, it will be addressed in a later release.

This issue may exist in previous version of SAN-OS such as 3.3(3), but I have not tested it. On this particular day I just happened to be using 3.3(5) and if I run an earlier version (which I frequently do), I will try to remember to test this.

What I found is that the output of “show interface trunk” seems to have some issues, observe the following:

I noticed that “show interface trunk vsan 50” on one of my switches is producing the following output:

MDS2# show int trunk v 50
ip access-group po101 in
ip access-group 6po101

This looks to be some sort of bug, as the output of this command should not produce results such as above.

Also, you will see additional problems, when I look at VSAN 10 for example:

MDS2# show int trunk v 10
fc1/12 is trunking
Belongs to port-channel 128
Vsan 10 is up (None)
fc1/13 is trunking
Belongs to port-channel 128
Vsan 10 is up (None)
ip access-group po101 in
ip access-group 6po101
port-channel 128 is trunking
Vsan 10 is up (None)
fcip1 is trunking
Vsan 10 is up (None)
fcip2 is trunking
Vsan 10 is up (None)

Notice the “ip access-group po101 in” and “ip access-group 6po101”. These don’t belong here. Observe the output of fc1/13 and po128:

MDS2# show run int fc1/13
version 3.3(5)

interface fc1/13
switchport ignore bit-errors
channel-group 128 force
fcsp off
no shutdown

MDS2# show run int po128
version 3.3(5)

interface port-channel 128
fspf cost 1001 vsan 10
fspf cost 200 vsan 30
no shutdown
channel mode active
switchport trunk allowed vsan 5
switchport trunk allowed vsan add 10
switchport trunk allowed vsan add 20
switchport trunk allowed vsan add 30
no shutdown

In fact, those lines are from po101 which has nothing to do with fc1/13:

MDS2# show run int po101.11
version 3.3(5)

interface port-channel 101.11
ipv6 enable
ip address 192.168.11.2 255.255.255.0
ipv6 address 2000:0:0:1::1/64
ipv6 address 2000:0:0:1::2/64
no shutdown
ip access-group po101 in
ipv6 traffic-filter 6po101 in

MDS2# show int po101.11
port-channel 101.11 is up
Hardware is GigabitEthernet, address is 000c.30da.9552
Internet address(es):
192.168.11.2/24
2000:0:0:1::1/64
2000:0:0:1::2/64
fe80::20c:30ff:feda:9552/64
MTU 1500 bytes
ip access-group po101 in
ip access-group 6po101
5 minutes input rate 1080 bits/sec, 135 bytes/sec, 1 frames/sec
5 minutes output rate 1064 bits/sec, 133 bytes/sec, 1 frames/sec
10547 packets input, 1366286 bytes
328 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun 0 fifo
10552 packets output, 1340396 bytes, 0 underruns
0 output errors, 0 collisions, 0 fifo
0 carrier errors
Member[1] : GigabitEthernet2/3
Member[2] : GigabitEthernet2/4

Its just weird. I have found other issues with the CLI output which I believe I posted about (problems with VSAN restricted roles leaking information on E ports).

This bug does not appear to effect anything but the display output, but it can be confusing. Also I have not yet gotten the bugID (and subsequently bug confirmation) from Cisco but will post it here when/if I do or what the outcome is.

This entry was posted in CCIE Storage, CLI and tagged , , , , . Bookmark the permalink.

Leave a Reply