Fcip link flapping priodically

We have a 9509 at the HQ site and a 9216 in the DR site connected via a DS3.
There are preiodic times when the fcip link will flap and come back up, sometimes it will continue for minutes and has happened for several hours with this error:
%PORT-5-IF_DOWN_TCP_MAX_RETRANSMIT: %$VSAN 50%$ Interface fcip1 is down(TCP conn. closed - retransmit failure)
originally the fcip profile was configured for 1000 max bandwidth and it was suggested to change it to something closer to the DS3 and this change was made:
fcip profile 1
ip address 10.1.2.1
tcp max-bandwidth-mbps 41 min-available-bandwidth-mbps 30 round-trip-time-ms 4
tcp send-buffer-size 5000
It made no difference at all. There is connectivity to the DR site during the flapping, I can see the bandwidth spike up, but there should be plenty to handle the load during the flapping.
Last night the serial interface of the DS3 was showing the tx load 65/255 and rx was 5/255 during the problem.
I am wondering, would the "min bandwidth" setting cause a "retransmit failure"?
That seems like more of a tcp/ip issue that an interface configuration issue, but I cannot find any reason for the flap.
No interface errors, but I have seen the ping response times go from 3ms to 25ms during this time, an indication of congestion somewhere.
Does anyone have any ideas?
There ar no errors on any of the interfaces for the DS3 or the fcip.

thanks for the reply,
Where do I make these changes and can you explain the logic behind them?
"enabling ip compression" I think compression is enabled in mode1 if I remember correctly
"and disabled fccit" what does this do?
"change the Rx buffer to defaults 16" is this in place of:
tcp send-buffer-size 5000
Are you talking about 16K rather than 5K?

Similar Messages

FCIP link issues

We have a 9509 at the HQ site and a 9216 in the DR site connected via a DS3.
There are periodic times when the fcip link will flap and come back up, sometimes it will continue for minutes and has happened for several hours with this error:
%PORT-5-IF_DOWN_TCP_MAX_RETRANSMIT: %$VSAN 50%$ Interface fcip1 is down(TCP conn. closed - retransmit failure).
My manager is telling me it is a setting on the FCIP profile and it is impossible the DS3 could be congested because it is a point to point link.
Verizon is also telling me it is a Cisco problem having to do with fragmentation.
Originally the fcip profile was configured for 1000 max bandwidth and it was suggested to change it to something closer to the DS3 and this change was made:
fcip profile 1
ip address 10.1.2.1
tcp max-bandwidth-mbps 41 min-available-bandwidth-mbps 30 round-trip-time-ms 4
tcp send-buffer-size 5000
It made no difference at all. There is connectivity to the DR site during the flapping, I can see the bandwidth spike up, but there should be plenty to handle the load during the flapping.
The time I had this problem the serial interface of the DS3 was showing the tx load 65/255 and rx was 5/255.
No interface errors, but I have seen the ping response times go from 3ms to 25ms during this time, an indication of congestion somewhere.
There are no errors on any of the interfaces for the DS3 or the fcip.
I have tried numerous different profile settings and nothing has made a differnce.
I have opened a TAC case and Cisco could find no reason for the flapping and suggested a carrier issue.
Does anyone have any ideas?
Any suggestion would be appreciated.

what version of SAN-OS are you running?
Are you using IP Compression and if so what mode?
what alerts are the peer switch sending when the link flaps?
we ran into a new bug when upgrading to SAN-OS 3.1(3a). if using IP compression set to (auto). 'auto' uses a combination of both software and hardware based compression depending on the type of traffic, load, bandwidth, etc.. the software portion of the ip compression in SAN-OS 3.1(3a) wiggs out dealing with packet buffers. this would cause our fcip profile to bounce randomly anywhere from 10-20 times a day. EMC SAC and Cisco TAC had me enable IPS full core dumps to a tftp server. from there they were able to determine that it was specifically the 'auto' setting in IP compression on the MPS 14/2 blades on the MDS 9216i's. we then set the IP compression to 'mode1', which is all hardware based compression, on all switches and that resolved our issue with the fcip profile flapping.

WLC 5508 reboot cause switch port link flap error disable

Hi All
today my customer call me saied after reboot WLC , the switch port was err-disable , the cause is link flap
after we reboot 3 times , the switch port link flap err-disable every time
does anyone to meet the same problem??
we don't know why the WLC rebboot will cause it , it just normal action on device
the WLC version is 7.4.100.0
link switch with access port , no port channel , no portfast
Asa Hung 2013/05/30

Hello Asa,
As per your query i can suggest you the following solution-
Complete these steps to reset the WLC to factory default settings using the CLI:
Enter reset system at the command prompt.
At the prompt that asks whether you need to save changes to the configuration, enter Y or N. The unit reboots.
When you are prompted for a username, enter recover-config to restore the factory default configuration.
The WLC reboots and displays the Welcome to the Cisco WLAN Solution Wizard Configuration Tool message.
Use the configuration wizard to enter configuration settings.
Note: Once the WLC is reset to defaults, you need a serial connection to the WLC in order to use the configuration wizard.
Hope this will help you.

Link flap problem?

Hello everyone,
Quick question about what causes a "link flap failure"
Here is the output
11-07-2005 18:48:38 Local7.Warning 172.16.208.184 1737: *Mar 13 05:47:09.196: %PM-4-ERR_DISABLE: link-flap error detected on Gi0/1, putting Gi0/1 in err-disable state
11-07-2005 18:49:10 Local7.Error 205.110.152.19 9281: 1w3d: %LINK-3-UPDOWN: Interface FastEthernet0/5, changed state to up
11-07-2005 18:50:53 Local7.Warning 172.16.208.184 1738: *Mar 13 05:49:23.765: %PM-4-ERR_RECOVER: Attempting to recover from link-flap err-disable state on Gi0/1
11-07-2005 18:50:55 Local7.Error 172.16.208.184 1739: *Mar 13 05:49:26.137: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
I leave the errdisable recovery on and it brings the port back up once the timer goes.
What causes this link flap?
Thanx

Hello there 8)
From the previously mentioned switch:
Gi0/1 TRUNK TO ISF159 connected trunk a-full a-1000 1000BaseLX
CONTRA#sh run | begin Gig
interface GigabitEthernet0/1
description TRUNK TO AS
switchport mode trunk
This is from the connected switch:
Gi0/1 TRUNK TO CONTRACTO connected trunk a-full a-1000 1000BaseLX
AS#sh run | begin Gig
interface GigabitEthernet0/1
description TRUNK TO CONTRACTORS
switchport trunk encapsulation dot1q
switchport mode trunk
no ip address
Thanx for any help

Link-flap faulty port

Hi,there
I have a Catalyst 2950 switch which was connected to a 3620 Cisco router.The router had hw problems and was repaired.After that,I tried to connect the repaired router to the 24th port of the switch,where it was.But the LED was off and I saw the port was in err-disable state because of link-flap.I've connected my router to the 22nd port of the switch and everything was fine.The 22nd and the 24th port have the same configuration now.I've entered the "no shut" command on int 24 but the state remained err-disabled.I've entered the err-disable recovery interval 30 but the output of sh errdisable detect recovery was ErrDisable Reason Timer Status
udld Disabled
bpduguard Disabled
security-violatio Disabled
channel-misconfig Disabled
vmps Disabled
pagp-flap Disabled
dtp-flap Disabled
link-flap Disabled
psecure-violation Disabled
gbic-invalid Disabled
dhcp-rate-limit Disabled
unicast-flood Disabled
loopback Disabled
Timer interval: 30 seconds
Interfaces that will be enabled at the next timeout:
switch#
Is there a hw problem with the port because of the faulty router in the past?Or is there another way to re-establish the state of my port so I can use it?Thank you for your time!

I would not think this is an hardware issue. To restore port, you need to do a shut first and then no shut. For automatic recovery, you need to configure "errdisable recovery cause all" or "errdisable recovery cause link-flap".

2960s Link-Flap issue.

I've recently had a few ports on 48 way 2960s go in to err mode.
Bit of digging and they have been disabled due to link flapping. I disconnected the devices to check cables etc and all checked out. I've since repatched in another stacked 2960s without issue.
The switch with the issue seems to have got progressively worse, what started with a couple of ports now has gone to gi1/0/33-40 are now disabled due to flapping.Even though none of the ports are now in use. I've restarted the switch just in case it was having a special moment but no luck.
show log displays
000062: Dec 17 19:30:19.490: %PM-4-ERR_DISABLE: link-flap error detected on Gi1/0/40, putting Gi1/0/40 in err-disable state
Switch attempts to recover after 300s with no luck. Just to confirm there is nothing patched in to the effected ports.
Any suggestions or is it it RMA time.

Hello Leo Laohoo,
Thank you for the quick reply,
I mentioned earlier in the thread that I've unpatched and tested the cables and have moved the devices in to another switch all working fine. Ports also have recover on too, and still are in error mode.
Below is test result on one port which shows fine.
Interface Speed Local pair Pair length        Remote pair Pair status
Gi1/0/33 auto Pair A     0    +/- 0 meters N/A         Normal
                Pair B     0    +/- 0 meters N/A         Normal
                Pair C     0    +/- 0 meters N/A         Normal
                Pair D     0    +/- 0 meters N/A         Normal
Regards
Rob

FCIP link merging fabrics or using IVR

Hi everyone, this is the situation:
I need to connect 2 Cisco MDS9509 through an IP WAN for mirroring 2 storage IBM 4800. The 2 sites are not far (1 mile) but are connected through a 300 Mbps IP WAN shared with other applications. The 2 fabrics are not too large, both are using just VSAN1 and have 12 double path server each and 1 storage device, only the 2 storages should communicate.
What the best practice would be, to merge or not to merge the 2 fabrics using IVR and a transit vsan? What would be cons and pros?
Thnx in advance.

I have a similar problem. We have two data centers about 200 miles apart and we have a 300 Mbps IP WAN between them. I have created an FCIP link and tunnel but the problem is, now both fabrics are merged. The VSANS themselves are isolated (because we have only allowed 1 vsan through the FCIP tunnel) but the device-aliases are all merged. I mean device-aliases which have been created on either fabrics now have been merged to both the fabrics now and DCNM sees switches from both the Data centres as one huge fabric now. I am not sure how to separate the fabrics. I atleast want the device-alias databases separate from each other. Any help is much appreciated.

VPC trouble - link flapping between C3750 stack and Nexus 5596

Hi All,
I have configured 1 vPC's between 2 Nexus 5596 and 1 stack C3750 switch. The links in the stack are distributed over both members.
Gi1/1/1 -> Eth 1/44 NX 5596-02
Gi 2/1/1 -> Eth 1/45 NX 5596-02
Gi 1/1/2 -> Eth 1/46 NX 5596-01
Gi 2/1/2 -> Eth 1/47 NX 5596-01
The same logic is for another stack C3750 to the same pair of Nexus 5596 switches.
The problem is that the links from the vPCs keep flapping at random moments - 1-2 times per hour.
The network is not loaded at this time and the same issue is on both vPC's.
the flaps in the nexus 5596 looks like this
%ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel108: Ethernet1/44 is down
%ETH_PORT_CHANNEL-5-FOP_CHANGED: port-channel108: first operational port changed from Ethernet1/44 to Ethernet1/45
%ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing)
%ETH_PORT_CHANNEL-5-PORT_UP: port-channel108: Ethernet1/44 is up
%ETHPORT-5-IF_UP: Interface Ethernet1/44 is up in mode trunk
On the stack is just up/down the pair interface.
I started few debugs on the stack and captured the folowing output:
C3750X-02#im_if_stack_relationship_add: Posting the ACP job for stack add for 5018.10902
im_if_stack_relationship_add: Posted the ACP job for stack add successfully
im_add_ifstackentry: higher_if_index = 5018 lower_if_index = 10902
im_add_ifstackentry: Failed to delete nolayerelem from NoLowerLayerTree for higher_ifIndex = 5018
im_add_ifstackentry: Failed to delete nolayerelem from NoHigherLayerTree for lower_ifIndex = 10902
im_add_ifstackentry: Deleted nolayerelems from NoHigherLayerTree and NoLowerLayerTree
im_add_ifstackentry: Failed to insert stackelem into StackTree
Jul 12 03:35:26.122: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/1/2, changed state to downim_if_stack_relationship_add: Posting the ACP job for stack add for 5018.10902
im_if_stack_relationship_add: Posted the ACP job for stack add successfully
im_add_ifstackentry: higher_if_index = 5018 lower_if_index = 10902
im_add_ifstackentry: Failed to delete nolayerelem from NoLowerLayerTree for higher_ifIndex = 5018
im_add_ifstackentry: Failed to delete nolayerelem from NoHigherLayerTree for lower_ifIndex = 10902
im_add_ifstackentry: Deleted nolayerelems from NoHigherLayerTree and NoLowerLayerTree
im_add_ifstackentry: Failed to insert stackelem into StackTree
Jul 12 03:35:29.058: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/1/2, changed state to up
Do someone have any idea what happens here ?
The configuration is ok because i have another vPC connected to FEX's and is working fine.
Kind regards,

Hello,
Problem solved after upgrade to the last version of NX OS 6.0.2.N2.3
BR,

[RSTP] Modifying Timers to avoid link flap related issues?

Hi All + ftallet :-)
Assume the following scenario;
There are two links between two switches. The primary link fails, RSTP cuts over to the secondary link. Now, the primary comes up for 10 seconds, and goes down again.
Question:
1. Is there a feature that can overcome this problem? E.g. adjust some timer to say 60 seconds, such that the primary link has to be working for 60 seconds before reverting to it.
2. Better still is there a feature that sends 'hello' style packets to check if a link is up for 60 seconds before reverting to the primary link? (like tracking in a 1800 series router )
I really only need to know if such features exist, and if they do, what are they called so I can search for it and read about it.
Cheers
Martin

Hi Martin,
I don't know of any such protocol. It would not be so complex to implement something that plays around with the STP cost of an interface based on its recent history though...
STP's memory does not go beyond max age. Uplinkfast is able to prevent an uplink that went down from becoming active immediately for some few additional seconds, but there nothing configurable there.
Finally, there is a solution called "flexlink", that basically keeps an interface blocked as a backup for a primary. If the primary fails, the backup interface goes forwarding. If the old primary comes back up, it becomes a backup interface...
That's all I can think of, which is not much you see;-)
F.

Nexus 5000 - Odd Ethernet interface behavior (link down inactive)

Hi Guys,
This would sound really trivial but it is very odd behavior.
- We have a server connected to a 2, Nexus 5000s (for resiliancy)
- When there is no config on the ethernet interfaces whatsoever, the ethernet interface is UP / UP, there is minimal amount of traffic on the link etc. E.g.
Ethernet1/16 is up
Hardware: 1000/10000 Ethernet, address: 000d.ece7.85d7 (bia 000d.ece7.85d7)
Description: shipley-p1.its RK14/A13
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
Port mode is access
full-duplex, 10 Gb/s, media type is 1/10g
Beacon is turned off
Input flow-control is off, output flow-control is off
Rate mode is dedicated
Switchport monitor is off
Last link flapped 00:00:07
Last clearing of "show interface" counters 05:42:32
30 seconds input rate 0 bits/sec, 0 packets/sec
30 seconds output rate 96 bits/sec, 0 packets/sec
Load-Interval #2: 5 minute (300 seconds)
    input rate 0 bps, 0 pps; output rate 8 bps, 0 pps
RX
    0 unicast packets 0 multicast packets 0 broadcast packets
    0 input packets 0 bytes
    0 jumbo packets 0 storm suppression packets
    0 runts 0 giants 0 CRC 0 no buffer
    0 input error 0 short frame 0 overrun   0 underrun 0 ignored
    0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
    0 input with dribble 0 input discard
    0 Rx pause
TX
    0 unicast packets 163 multicast packets 0 broadcast packets
    163 output packets 15883 bytes
    0 jumbo packets
    0 output errors 0 collision 0 deferred 0 late collision
    0 lost carrier 0 no carrier 0 babble
    0 Tx pause
1 interface resets
- As soon as I configure the link to be an access port, the link goes down, flagging "inactivity" E.g.
sh int e1/16
Ethernet1/16 is down (inactive)
Hardware: 1000/10000 Ethernet, address: 000d.ece7.85d7 (bia 000d.ece7.85d7)
Description: shipley-p1.its RK14/A13
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
Port mode is access
auto-duplex, 10 Gb/s, media type is 1/10g
Beacon is turned off
Input flow-control is off, output flow-control is off
Rate mode is dedicated
Switchport monitor is off
Last link flapped 05:38:03
Last clearing of "show interface" counters 05:41:33
30 seconds input rate 0 bits/sec, 0 packets/sec
30 seconds output rate 0 bits/sec, 0 packets/sec
Load-Interval #2: 5 minute (300 seconds)
    input rate 0 bps, 0 pps; output rate 0 bps, 0 pps
RX
    0 unicast packets 0 multicast packets 0 broadcast packets
    0 input packets 0 bytes
    0 jumbo packets 0 storm suppression packets
    0 runts 0 giants 0 CRC 0 no buffer
    0 input error 0 short frame 0 overrun   0 underrun 0 ignored
    0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
    0 input with dribble 0 input discard
    0 Rx pause
TX
    0 unicast packets 146 multicast packets 0 broadcast packets
    146 output packets 13083 bytes
    0 jumbo packets
    0 output errors 0 collision 0 deferred 0 late collision
    0 lost carrier 0 no carrier 0 babble
    0 Tx pause
0 interface resets
- This behavior is seen on both 5Ks
- I've tried using a different set of ports, changed SFPs, and fibre cabling to no avail
- I can't seem to understand this behavior?! In that, why would configuring the port cause the link to go down?
- If anyone has experience this before, or could shed some light on this behavior, it would be appreciated.
sh ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2010, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
BIOS:      version 1.2.0
loader:    version N/A
kickstart: version 4.2(1)N1(1)
system:    version 4.2(1)N1(1)
power-seq: version v1.2
BIOS compile time:       06/19/08
kickstart image file is: bootflash:/n5000-uk9-kickstart.4.2.1.N1.1.bin
kickstart compile time: 4/29/2010 19:00:00 [04/30/2010 02:38:04]
system image file is:    bootflash:/n5000-uk9.4.2.1.N1.1.bin
system compile time:     4/29/2010 19:00:00 [04/30/2010 03:51:47]
thanks
Sheldon

I had identical issue
Two interfaces on two different FEXes were INACTIVE. I have two Nexus 5596 in vPC and A/A FEXes.
I also use config-sync feature.
Very same configuration was applied to other ports on other FEXes and they were working with no problems.
interface Ethernet119/1/1
inherit port-profile PP-Exchange2003
I checked VLAN status associated with this profile and it was active (of course it was, other ports were ok).
I solved it by removing port profile from this port and re-applied it... voila, port changed state to up!
Very very strange.

VSAN link to DR shows as dashed line in Fabric Manager

We have a 9509 at our HQ site and a 9216 at our DR site.
We have a single VSAN configured from HQ to Dr that accries all of the replication traffic to DR.
We recenlty had a situation where the fcip link to DR was down with:
"2007 Aug 21 06:46:10 lkld-9509-01 %PORT-5-IF_DOWN_TCP_MAX_RETRANSMIT: %$VSAN 50%
$ Interface fcip1 is down(TCP conn. closed - retransmit failure)"
The link has been up fro a week now, but it is showing as a dashed line in Fabric Manager. The connection shows "Up" and all traffic is making it to the VSAN at the DR site.
Before, I could see the link as a solid yellow line when I would look in Fabric Manager.
Anyone have any thoughts on this?

Thanks,
Everything seems to be stable now, but is it possible there could be an issue with a port configuration?
I have been here for almost 5 months and it happend one time for those hours I mentioned, nothing since.
I have head that this has happened before.
I have heard that these could be an issue:
Buffer credits - not sure what to do there
Interface not configured for the 45Mbps DS3 link we have.
It seems if those were issues, we would see this more often that once every few months.
Anything I can look for?

FCIP Peer in the same VLAN

Hi,
I will have 2 data centre connected with a 1gb possibly 2 x 1gb ethernet link.
There will be some 802.q trunking between location and some traffic will be routed.
I have the option of having my FCIP peer in the same vlan and carried in the trunk. Or have them in different VLAN and routed between location.
Initiallay I though routed would be good because I can use QoS to prioritise FCIP traffice.
But could I still achieve this using single vlan. and is it allowed.
both site are connect using 6509 with sup720s
Thanks
John

Hi John,
For the FCIP link it is just an IP connectivity. So, you can do in both ways as you describe. You can route it or use a vlan. Just make sure that you have no too hign RTT. And also there RTT timout setting on FCIP you can play with that according to your RRT in your network.
Thanks,
Hakan.

Write Acceleration on FCIP tunnels degrading Mirrorview performance

Disaster Recovery(DR)for storage:
Odd fabric:MDS1 (fcip1)----> MDSDR(fcip1)
Even fabric: MDS1(fcip3)----> MDSDR (fcip3)
Link details: b/w=2.0g,latency(7ms)
fcip Link on the MDS is on 14+2 card.
Ip compression mode=1 turned on.
WriteAcceleration turned on.
Without WA enabled, fcip1 traffic is in MB consistently.
With WA enabled, fcip1 traffic degrades to < 5KB. Lots of small 100-300B pkts seen on the Source TX and receive RX of fcip1.

So I would leave WA off if there is no performance gain. So, you have 2G total BW for 2 FCIP links? So, what are the min/max values on the tcp profile? If this is more than 100MB/sec, I would suggest leaving compression off as more than likely it takes longer to compress than just to send it. Compression is done in HW in mode1 on the 14/2 and 9216i cards and done in SW for the IPS4 and IPS8 cards. Above 100M you will see more gain from setting the MTU from end to end to 2300.

BGP flap

We have p2p link between SanDeago and Mexico, configured with BGP.
in recent times the link is plapping continuously, plz check below bgp config on both routers.
NatPen_MX_3825#sh run | be bgp
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 10.60.0.0 mask 255.255.0.0
redistribute static metric 20 route-map MXCAMMAP
neighbor 10.63.0.1 remote-as 1
neighbor 10.63.0.1 fall-over
no auto-summary
NatPen_MX_3825#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 10.63.0.1 to network 0.0.0.0
199.220.41.0/30 is subnetted, 1 subnets
B 199.220.41.176 [20/0] via 10.63.0.1, 00:00:13
1.0.0.0/24 is subnetted, 1 subnets
B 1.4.204.0 [20/0] via 10.63.0.1, 00:00:13
152.177.0.0/30 is subnetted, 1 subnets
B 152.177.74.24 [20/0] via 10.63.0.1, 00:00:13
152.181.0.0/30 is subnetted, 1 subnets
B 152.181.185.68 [20/0] via 10.63.0.1, 00:00:13
206.113.119.0/26 is subnetted, 2 subnets
B 206.113.119.128 [20/0] via 10.63.0.1, 00:00:13
B 206.113.119.0 [20/0] via 10.63.0.1, 00:00:13
199.220.194.0/30 is subnetted, 1 subnets
B 199.220.194.232 [20/0] via 10.63.0.1, 00:00:13
172.17.0.0/30 is subnetted, 1 subnets
B 172.17.29.0 [20/0] via 10.63.0.1, 00:00:13
172.16.0.0/24 is subnetted, 1 subnets
B 172.16.1.0 [20/0] via 10.63.0.1, 00:00:13
172.18.0.0/30 is subnetted, 2 subnets
B 172.18.30.0 [20/0] via 10.63.0.1, 00:00:13
B 172.18.29.0 [20/0] via 10.63.0.1, 00:00:13
172.21.0.0/30 is subnetted, 1 subnets
D 172.21.106.120 [220/63232] via 172.20.107.229, 5d03h, Serial2/0
172.20.0.0/30 is subnetted, 1 subnets
C 172.20.107.228 is directly connected, Serial2/0
172.23.0.0/30 is subnetted, 1 subnets
B 172.23.9.0 [20/0] via 10.63.0.1, 00:00:13
172.22.0.0/30 is subnetted, 2 subnets
B 172.22.0.144 [20/0] via 10.63.0.1, 00:00:13
D 172.22.157.84 [220/63232] via 172.20.107.229, 5d03h, Serial2/0
172.32.0.0/24 is subnetted, 1 subnets
B 172.32.7.0 [20/0] via 10.63.0.1, 00:00:13
10.0.0.0/8 is variably subnetted, 21 subnets, 5 masks
B 10.30.0.0/21 [20/0] via 10.63.0.1, 00:00:13
B 10.31.0.0/16 [20/0] via 10.63.0.1, 00:00:13
B 10.30.13.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.20.0.0/16 [20/0] via 10.63.0.1, 00:00:14
B 10.21.0.0/16 [20/0] via 10.63.0.1, 00:00:14
B 10.40.0.0/16 [20/0] via 10.63.0.1, 00:00:14
B 10.41.0.0/16 [20/0] via 10.63.0.1, 00:00:14
C 10.63.0.0/16 is directly connected, GigabitEthernet0/1
S 10.61.1.0/24 [1/0] via 10.60.0.2
C 10.60.0.0/16 is directly connected, GigabitEthernet0/0
B 10.100.0.44/30 [20/0] via 10.63.0.1, 00:00:14
B 10.133.201.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.100.0.32/30 [20/0] via 10.63.0.1, 00:00:14
B 10.90.0.0/16 [20/0] via 10.63.0.1, 00:00:14
B 10.172.16.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.4.204.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.4.205.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.3.202.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.4.202.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.4.201.0/24 [20/0] via 10.63.0.1, 00:00:14
B 10.254.254.240/32 [20/0] via 10.63.0.1, 00:00:14
147.225.0.0/30 is subnetted, 1 subnets
B 147.225.40.160 [20/0] via 10.63.0.1, 00:00:14
B 206.169.74.0/24 [20/0] via 10.63.0.1, 00:00:14
B 192.168.100.0/24 [20/0] via 10.63.0.1, 00:00:14
B* 0.0.0.0/0 [20/0] via 10.63.0.1, 00:00:14
NatPen_MX_3825#sh ip bg
NatPen_MX_3825#sh ip bgp
BGP table version is 32518, local router ID is 172.20.107.230
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.63.0.1 0 1 65000 65000 i
*> 1.4.204.0/24 10.63.0.1 0 1 ?
*> 10.3.202.0/24 10.63.0.1 0 1 ?
*> 10.4.201.0/24 10.63.0.1 0 1 ?
*> 10.4.202.0/24 10.63.0.1 0 1 ?
*> 10.4.204.0/24 10.63.0.1 0 1 ?
*> 10.4.205.0/24 10.63.0.1 0 1 ?
*> 10.20.0.0/16 10.63.0.1 0 1 65000 65000 ?
*> 10.21.0.0/16 10.63.0.1 0 1 65000 65000 i
*> 10.30.0.0/21 10.63.0.1 0 0 1 i
*> 10.30.13.0/24 10.63.0.1 0 0 1 i
*> 10.31.0.0/16 10.63.0.1 0 0 1 ?
*> 10.40.0.0/16 10.63.0.1 0 1 65000 65000 i
*> 10.41.0.0/16 10.63.0.1 0 1 65000 65000 ?
*> 10.60.0.0/16 0.0.0.0 0 32768 i
*> 10.61.1.0/24 10.60.0.2 20 32768 ?
r> 10.63.0.0/16 10.63.0.1 0 0 1 ?
*> 10.90.0.0/16 10.63.0.1 0 1 65000 10 i
*> 10.100.0.32/30 10.63.0.1 0 1 ?
*> 10.100.0.44/30 10.63.0.1 0 1 65000 65000 ?
*> 10.133.201.0/24 10.63.0.1 0 1 ?
*> 10.172.16.0/24 10.63.0.1 0 1 ?
*> 10.254.254.240/32
10.63.0.1 0 1 ?
*> 147.225.40.160/30
10.63.0.1 0 0 1 ?
*> 152.177.74.24/30 10.63.0.1 0 1 65000 ?
*> 152.181.185.68/30
10.63.0.1 0 1 65000 ?
*> 172.16.1.0/24 10.63.0.1 0 1 ?
*> 172.17.29.0/30 10.63.0.1 0 1 65000 65000 ?
*> 172.18.29.0/30 10.63.0.1 0 0 1 ?
*> 172.18.30.0/30 10.63.0.1 0 1 ?
*> 172.22.0.144/30 10.63.0.1 0 1 ?
*> 172.23.9.0/30 10.63.0.1 0 1 65000 65000 ?
*> 172.32.7.0/24 10.63.0.1 0 1 ?
*> 192.168.100.0 10.63.0.1 0 1 ?
*> 199.220.41.176/30
Network Next Hop Metric LocPrf Weight Path
10.63.0.1 0 1 ?
*> 199.220.194.232/30
10.63.0.1 0 1 65000 ?
*> 206.113.119.0/26 10.63.0.1 0 1 65000 65004 ?
*> 206.113.119.128/26
10.63.0.1 0 1 65000 65004 ?
*> 206.169.74.0 10.63.0.1 0 1 65000 65000 ?
NatPen_MX_3825#
NatPen_MX_3825#sh run | in ip rou
ip route 10.61.1.0 255.255.255.0 10.60.0.2
NatPen_MX_3825#
===============================================================================================================
router bgp 1
no synchronization
bgp log-neighbor-changes
network 10.30.0.0 mask 255.255.248.0
network 10.30.13.0 mask 255.255.255.0
redistribute connected
neighbor 10.63.0.2 remote-as 65001
neighbor 10.63.0.2 fall-over
neighbor 147.225.40.161 remote-as 65000
neighbor 147.225.40.161 distribute-list no-redist-CV-Routes out
neighbor 172.18.29.2 remote-as 1
no auto-summary
NatPen_SD2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 147.225.40.161 to network 0.0.0.0
199.220.41.0/30 is subnetted, 1 subnets
B 199.220.41.176 [200/0] via 10.100.0.34, 3w1d
1.0.0.0/24 is subnetted, 1 subnets
B 1.4.204.0 [200/0] via 10.133.201.254, 3w1d
152.177.0.0/30 is subnetted, 1 subnets
B 152.177.74.24 [20/0] via 147.225.40.161, 4w3d
152.181.0.0/30 is subnetted, 1 subnets
B 152.181.185.68 [20/0] via 147.225.40.161, 4w3d
206.113.119.0/26 is subnetted, 2 subnets
B 206.113.119.128 [20/0] via 147.225.40.161, 4w3d
B 206.113.119.0 [20/0] via 147.225.40.161, 4w3d
199.220.194.0/30 is subnetted, 1 subnets
B 199.220.194.232 [20/0] via 147.225.40.161, 4w0d
172.17.0.0/30 is subnetted, 1 subnets
B 172.17.29.0 [20/0] via 147.225.40.161, 3w0d
172.16.0.0/24 is subnetted, 1 subnets
B 172.16.1.0 [200/0] via 10.133.201.254, 3w1d
172.18.0.0/30 is subnetted, 2 subnets
B 172.18.30.0 [200/0] via 172.18.29.2, 3w1d
C 172.18.29.0 is directly connected, FastEthernet1/1
172.23.0.0/30 is subnetted, 1 subnets
B 172.23.9.0 [20/0] via 147.225.40.161, 1w2d
172.22.0.0/30 is subnetted, 1 subnets
B 172.22.0.144 [200/0] via 172.18.29.2, 3w1d
172.32.0.0/24 is subnetted, 1 subnets
B 172.32.7.0 [200/0] via 10.133.201.254, 3w1d
10.0.0.0/8 is variably subnetted, 21 subnets, 5 masks
C 10.30.0.0/21 is directly connected, GigabitEthernet0/0.1
C 10.31.0.0/16 is directly connected, GigabitEthernet0/0.2
C 10.30.13.0/24 is directly connected, GigabitEthernet0/0.2
B 10.20.0.0/16 [20/0] via 147.225.40.161, 4w0d
B 10.21.0.0/16 [20/0] via 147.225.40.161, 4w3d
B 10.40.0.0/16 [20/0] via 147.225.40.161, 1w2d
B 10.41.0.0/16 [20/0] via 147.225.40.161, 1w2d
C 10.63.0.0/16 is directly connected, GigabitEthernet0/1
B 10.61.1.0/24 [20/20] via 10.63.0.2, 00:01:44
B 10.60.0.0/16 [20/0] via 10.63.0.2, 00:01:44
B 10.100.0.44/30 [20/0] via 147.225.40.161, 4w3d
B 10.133.201.0/24 [200/0] via 172.18.29.2, 3w1d
B 10.100.0.32/30 [200/0] via 172.18.29.2, 3w1d
B 10.90.0.0/16 [20/0] via 147.225.40.161, 4w3d
B 10.172.16.0/24 [200/0] via 10.133.201.254, 3w1d
B 10.4.204.0/24 [200/0] via 10.133.201.254, 3w1d
B 10.4.205.0/24 [200/0] via 10.133.201.254, 3w1d
B 10.3.202.0/24 [200/0] via 10.133.201.254, 3w1d
B 10.4.202.0/24 [200/0] via 10.133.201.254, 3w1d
B 10.4.201.0/24 [200/0] via 10.133.201.254, 3w1d
B 10.254.254.240/32 [200/0] via 10.133.201.254, 3w1d
147.225.0.0/30 is subnetted, 1 subnets
C 147.225.40.160 is directly connected, Serial3/0
B 206.169.74.0/24 [20/0] via 147.225.40.161, 2w1d
B 192.168.100.0/24 [200/0] via 10.133.201.254, 3w1d
B* 0.0.0.0/0 [20/0] via 147.225.40.161, 3w5d
NatPen_SD2#
NatPen_SD2#sh run | in ip route
ip route 0.0.0.0 0.0.0.0 10.133.201.254 210
ip route 1.4.205.147 255.255.255.255 10.100.0.29
ip route 170.146.36.16 255.255.255.255 10.100.0.29
ip route 170.146.234.48 255.255.255.255 10.100.0.29
NatPen_SD2#

Dear Sathish,
Is the link flapping or the BGP is flapping?
If it is the link that is flapping then your BGP with the neighbour and the IGP with the neighbour must flap.
If it is only BGP which is flapping then we have to look in to different scenario , please share the log messages for the notification provided by the peer.
BR
Md Thanveer

Unstable Link on SF100D-05

Hi!
We considered using the SF100D-05 Switches in small offices with an insufficient amount of network jacks. However, it appears that this switch-series is faulty. In the combination of new MSI-mainboards with Realtek network chipset, the link to the client is extremely unstable. I am not talking about one computer on one switch. The Problem occurs on every SF100D-switch with every new computer equipped with the aforementioned mainboard on our campus. Older computers or mainboards from other vendors are not affected. Also, any other low-price desktop-switch we use (Digitus, LevelOne, etc.) is working fine while the SF100D induces link-flaps on the mentioned machines.
The problem in detail:
Connecting a new, freshly installed, computer (with MSI-mainboard and Realtek network chipset) with the switch. The Link comes up and the computer has access to the network. After approx. 30-60 sec. the link gets down. (both link LEDs go off and the networkconnection is offline) After another 1-2 sec. the Link comes up again and network is working fine till the next 30-60 sec. Then the problem repeats.
The time between two link-downs decreases with higher network traffic. While downloading large amounts of data the link-down interval is reduced to 5-10 sec.
Setting the computers NIC to 100 Mbps full-duplex instead of Auto has no effect on the problem.
We tested the scenario with different
- switchports
- wires
- computers
- electric circuits
- offices
The behaviour is not identical to
https://supportforums.cisco.com/message/3143262
The Problem occurs on NICs with the following MAC-OUIs
D4:3D:7E
8C:89:A5
Here are some serial-number-ranges of our switches (SF100D-05 V02):
PSZ163902**
PSZ164305**
Has anyone observed similar problems?

Dear Customer,
Thank you for reaching Small Business Support Community.
It is a very interesting and very well described and troubleshooted issue, very good and time consuming job you have done here! and since I have found no similar cases, documented software bugs and not even a firmware upgrade I can suggest, my only recommendation is to contact the Small Business Support Center to see if they have any idea in how to overcome this issue which in my opinion is a compatibility problem;
https://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html
Unfortunately I am not able to reproduce your case scenario but please do not hesitate to reach me back if there is anything I may assist you with in the meantime.
Kind regards,
Jeffrey Rodriguez S. .:|:.:|:.
Cisco Customer Support Engineer
*Please rate the Post so other will know when an answer has been found.

Fcip link flapping priodically

Similar Messages

Maybe you are looking for