cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
883
Views
1
Helpful
2
Replies

IE4000: PRP Interface with Alarm Profile - Alarm Fails - Underlying Physical Interfaces pinned to PRP Interface

BrianSekleckiGE
Level 1
Level 1

All:

 

I have an interesting scenario below.

 

IE4000 (Stratix S5400) running Version 15.2(7)E

 

Physical interfaces that are members of a PRP interface can change status, but they do not show down until both interfaces (LAN_A, LAN_B) are down.

 

It is almost as if the physical interfaces have their status "pinned" to the Logical interface for some other reason.

 

But the result: Alarm fails to trip when a either Ring interface is lost

 

I think its a bug?

 

~BAS

 

CORE010#show prp channel 1 detail

PRP-channel: PR1
------------
Layer type = L2
Ports: 2 Maxports = 2
Port state = prp-channel is Inuse
Protocol = Enabled
Ports in the group:
1) Port: Gi1/1
Logical slot/port = 1/1 Port state = Inuse
Protocol = Enabled
2) Port: Gi1/2
Logical slot/port = 1/2 Port state = Inuse
Protocol = Enabled

CORE010#show prp channel 1 status

PRP-channel: PR1
------------
Port state = prp-channel is Inuse
Protocol = Enabled


CORE010#sh int status | i PR1|Gi1/[12]
Gi1/1 Trunk to T108-Fa1/ connected trunk a-full a-100 10/100/1000BaseTX
Gi1/2 Trunk to T107-Fa1/ connected trunk a-full a-100 10/100/1000BaseTX
PR1 Trunk to PR1 connected trunk a-full a-100

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

CORE010#sh run int range gi1/1-2,PR1

Building configuration...

Current configuration : 300 bytes
!
interface GigabitEthernet1/1
description Trunk to LAN_A_Edge1-Fa1/2
switchport trunk allowed vlan 121,200-299
switchport trunk native vlan 121
switchport mode trunk
alarm profile ALARM_PROFILE_FOO!! <----- !!!!
prp-channel-group 1
service-policy input CIP-PTP-Traffic
service-policy output Policymap-Output-Default

!
interface GigabitEthernet1/2
description Trunk to LAN_B_Edge1-Fa1/2
switchport trunk allowed vlan 121,200-299
switchport trunk native vlan 121
switchport mode trunk
alarm profile ALARM_PROFILE_FOO!! <----- !!!!
prp-channel-group 1
service-policy input CIP-PTP-Traffic
service-policy output Policymap-Output-Default

!
interface PRP-channel1
description Trunk to PRP Ring
switchport trunk allowed vlan 121,200-299
switchport trunk native vlan 121
switchport mode trunk
spanning-tree bpdufilter enable
end

 

!!!!!!!!!!!!!!!

CORE010# show alarm profile ALARM_PROFILE_FOO

alarm profile ALARM_PROFILE_FOO:

Interfaces GigabitEthernet1/5 GigabitEthernet1/6 GigabitEthernet1/8 GigabitEthernet1/9 GigabitEthernet1/10 GigabitEthernet1/4 GigabitEthernet1/3 GigabitEthernet1/2 GigabitEthernet1/1
Alarms link-fault, not-forwarding, fcs-error
Syslog link-fault, not-forwarding, fcs-error
Notifies link-fault, not-forwarding, fcs-error
Relay Major link-fault, not-forwarding, fcs-error


!!!!!!!!!!!!!!!!!!!

 

!!!!!!!!!!!!!!!!!!!!!!!


CORE010# show facility-alarm status
Source Severity Description Relay Time

CORE010# show facility-alarm relay major
Source Description Relay Time


!!!!!!!!!!!!!!!!!!!


! So as you can see, GigabitEthernet1/1 and GigabitEthernet1/2 constitute interface PR1

! (Link To LAN_A_Edge1 (LAN_A) and LAN_B_Edge1 (LAN_B) ring edge switches)

!!!!!!!!!!!!!!!!!!!!

 

[ Event ] 

! <----------!!!!!!!! Physically disconnect Gi1/1 Switch

! <--- !!!!!! At this point, there should be an alarm on Gi1/1


CORE010# show facility-alarm status
Source Severity Description Relay Time

 

! <----------!!!!!!!! And it still says Gi1/1 it is up, but it is unplugged!


CORE010# sh int gi1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 34c0.f985.7e81 (bia 34c0.f985.7e81)


! <----------!!!!!!!! Physically disconnect Gi1/2 from Switch

! <--- ! At this point, both interfaces  now show down

 

CORE010 #sh int gi1/1 | i pro
GigabitEthernet1/1 is down, line protocol is down (notconnect)


CORE010  #sh int gi1/2 | i pro
GigabitEthernet1/2 is down, line protocol is down (notconnect)
0 unknown protocol drops

 

 

CORE010# show facility-alarm status

Source Severity Description Relay Time
GigabitEthernet1/2 MAJOR 1 Link Fault MAJ Jun 16 2020 11:23:08
GigabitEthernet1/1 MAJOR 1 Link Fault MAJ Jun 16 2020 11:23:08


!!!! Logs only register an event after physically disconnecting both interfaces

 

Jun 16 09:23:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface PRP-channel-LAN_A, changed state to down
Jun 16 09:23:08: %LINK-3-LINK_FAULT: ASSERT MAJOR GigabitEthernet1/1 Link Fault
Jun 16 09:23:08: %LINK-3-LINK_FAULT: ASSERT MAJOR GigabitEthernet1/2 Link Fault
Jun 16 09:23:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/2, changed state to down
Jun 16 09:23:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/1, changed state to down
Jun 16 09:23:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface PRP-channel1, changed state to down
Jun 16 09:23:09: %LINK-3-UPDOWN: Interface GigabitEthernet1/2, changed state to down
Jun 16 09:23:09: %LINK-3-UPDOWN: Interface PRP-channel1, changed state to down
Jun 16 09:23:09: %LINK-3-UPDOWN: Interface GigabitEthernet1/1, changed state to down

 

! Reconnect either Gi1/1 or Gi1/2
!


Jun 16 09:23:39: %LINEPROTO-5-UPDOWN: Line protocol on Interface PRP-channel-LAN_A, changed state to up
Jun 16 09:23:39: %ALARM-3-CLEAR: CLEAR MAJOR GigabitEthernet1/1 Link Fault entity deleted
Jun 16 09:23:40: %LINK-3-LINK_FAULT: CLEAR MAJOR GigabitEthernet1/2 Link Fault
Jun 16 09:23:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface PRP-channel-LAN_B, changed state to up
Jun 16 09:23:41: %LINK-3-UPDOWN: Interface GigabitEthernet1/2, changed state to up
Jun 16 09:23:41: %LINK-3-UPDOWN: Interface GigabitEthernet1/1, changed state to up
Jun 16 09:23:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/2, changed state to up
Jun 16 09:23:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/1, changed state to up
Jun 16 09:23:44: %LINK-3-UPDOWN: Interface PRP-channel1, changed state to up
Jun 16 09:23:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface PRP-channel1, changed state to up

 

 

2 Replies 2

BrianSekleckiGE
Level 1
Level 1

FYI this bug still exists four years later; I will engage with Rockwell and Cisco to address it.

Also, I will check if the bug still exists in the PRP implementation on the IOS-XE based IE-9300 platform.

This bug does not exist on the IOS-XE based implementation of PRP on the new generation of Catalyst IE-9300.

 

seklecki_0-1705678857880.png

 

Review Cisco Networking for a $25 gift card