However, ever since we deployed this CCR1009, I've been noticing this every few hours:
Code: Select all
apr/22 17:23:35 interface,info ether1 link down
apr/22 17:23:35 interface,info ether2 link down
apr/22 17:23:35 interface,info ether3 link down
apr/22 17:23:35 interface,info ether4 link down
apr/22 17:23:35 route,ospf,info OSPFv2 neighbor X.X.128.33: state change from Full to Down
apr/22 17:23:35 route,ospf,info OSPFv2 neighbor X.X.128.47: state change from Full to Down
apr/22 17:23:37 interface,info ether2 link up (speed 100M, full duplex)
apr/22 17:23:37 interface,info ether3 link up (speed 100M, full duplex)
apr/22 17:23:38 interface,info ether1 link up (speed 1G, full duplex)
apr/22 17:23:38 interface,info ether4 link up (speed 1G, full duplex)
apr/22 17:24:28 route,ospf,info Database Description packet has different master status flag
apr/22 17:24:28 route,ospf,info new master flag=false
apr/22 17:24:28 route,ospf,info OSPFv2 neighbor X.X.128.33: state change from Full to 2-Way
I'm noticing it happen on ether1-ether4, which correlates to the switch chip, even though we're not switching from this unit at all. I've combed over the unit's full export and nothing is really different from our previous incarnation of this unit being a CRS125 (and having CPU issues from that).
When doing a ping from one hop away, (out the ether4) I see when this happens (X.X.136.106 is down ether2 on the above, X.X.65.17 is upstream bridging between ether1 and ether4 on the above device via OSPF:
Code: Select all
SEQ HOST SIZE TTL TIME STATUS
727 X.X.136.106 56 63 4ms
728 X.X.136.106 56 63 1ms
729 X.X.136.106 timeout
730 X.X.136.106 timeout
731 X.X.136.106 timeout
732 X.X.136.106 timeout
733 X.X.136.106 56 63 1ms
734 X.X.128.162 84 64 0ms redirect host
735 X.X.136.106 timeout
736 X.X.65.17 84 64 134ms TTL exceeded
737 X.X.65.17 84 64 134ms TTL exceeded
738 X.X.65.17 84 64 118ms TTL exceeded
739 X.X.65.17 84 64 130ms TTL exceeded