INTERFACE FLAP TROUBLESHOOTING - STANDARD OPERATING PROCEDURE

Knowledge Base Article

Document ID: KB-IFACE-FLAP-001
Version: 1.0
Last Updated: June 12, 2026
Platform: Juniper Networks (MX, SRX, EX, QFX, vMX)
Status: Production

1. OVERVIEW

Interface flapping (rapid link up/down transitions) degrades network stability, causes protocol convergence issues, and can lead to service disruptions. This SOP provides systematic procedures for identifying, diagnosing, and resolving interface flap issues across all Juniper platforms.

1.1 Objective

• Detect and identify interface flapping quickly
• Diagnose root cause (physical, software, configuration)
• Resolve flap with minimal downtime
• Prevent recurrence through proper configuration
• Provide escalation path for complex issues

1.2 Scope

This document covers: - Physical layer (fiber, copper) flapping - Driver/firmware issues - Configuration-related flapping - Protocol convergence due to flaps - Multi-link bundle flapping - Sub-interface and logical interface flapping

2. UNDERSTANDING INTERFACE FLAPPING

2.1 Definition and Impact

Interface Flapping: Rapid, repeated transitions between “up” and “down” states within minutes or seconds.

Network Impact: - Routing convergence: BGP/OSPF neighbors down/up cycles - VRRP failover: Unintended Master/Backup transitions - STP topology changes: Excessive TCN (Topology Change Notification) - MAC address instability: MAC table corruption - Service disruption: Temporary loss of connectivity - CPU overload: Processing repeated state changes - Log flooding: Excessive system log entries

Severity Levels: - Critical: >1 flap per minute on production link - High: >5 flaps per hour on production link - Medium: >1 flap per hour on production link - Low: Occasional flaps during maintenance

3. PREREQUISITES FOR TROUBLESHOOTING

Before starting troubleshooting:

• Physical access to affected port/cable (preferred)
• Fiber inspection tools (if fiber interface)
• Cable testing equipment (TDR, optical power meter)
• Baseline interface statistics for comparison
• System log access for historical analysis
• Ability to disable/enable interfaces
• Maintenance window if replacement needed
• Spare cables/SFPs for testing

4. INITIAL DETECTION & MONITORING

Procedure 4.1: Detect Flapping Interface

Method 1: View System Logs for Flap Events

# Search for interface up/down transitions
show log messages | grep -i "interface\|link" | tail -50

# More specific search
show log messages | grep -E "ge-0/0/0.* (down|up)" | tail -20

# Count flaps in timeframe
show log messages | grep "ge-0/0/0" | grep -E "(down|up)" | wc -l

Expected Output for Flapping Interface:

Jun 12 10:15:23 ge-0/0/0 down
Jun 12 10:15:27 ge-0/0/0 up
Jun 12 10:15:31 ge-0/0/0 down
Jun 12 10:15:35 ge-0/0/0 up

Expected Output for Stable Interface:

Jun 12 09:00:00 ge-0/0/0 up (single entry, no transitions)

Procedure 4.2: Get Real-time Status

Command:

show interfaces ge-0/0/0 terse
show interfaces ge-0/0/0.0 terse

Interpret Output:

Physical Interface:
ge-0/0/0              up    up
  
Logical Interface:
ge-0/0/0.0           up    up

# ✓ Both "up" = Interface stable
# ✗ Physical "down" = Link problem
# ✗ Logical "down" = Configuration issue

Procedure 4.3: Monitor Flap Rate

Real-time Monitoring:

# Monitor interface changes
monitor interface ge-0/0/0

# Alternative: Capture state over time
show interfaces ge-0/0/0 terse > status_t0.txt
# Wait 30 seconds
show interfaces ge-0/0/0 terse > status_t30.txt
# Compare files for state changes
diff status_t0.txt status_t30.txt

Collect Flap History:

# Count flaps per interface (last 24 hours)
show log messages | grep -E "up|down" | grep -oE "ge-[0-9/]+" | sort | uniq -c

# Identify most unstable interface
show interfaces terse | grep "down"

5. STEP-BY-STEP TROUBLESHOOTING WORKFLOW

SCENARIO 1: Physical Interface Down/Up (Layer 1 Issue)

Step 1.1: Verify Physical Layer Status

# Check detailed interface information
show interfaces ge-0/0/0 detail

Look for in output: - Link Level: “Up” or “Down” - Physical Link: “Up” or “Down” - Speed: Should match connected device - MTU: Should be appropriate - CRC Errors: Should be 0 (if >0, likely physical issue) - Input Errors: Should be near 0

Step 1.2: Check Physical Interface Diagnostics

For Fiber Interfaces:

# View optical signal levels
show interfaces ge-0/0/0 diagnostics optics

# Expected output:
# Module Temperature        : 42°C
# Laser RX Power           : -15.5 dBm (normal: -10 to -3 dBm)
# Laser TX Power           : -5.2 dBm  (normal: -5 to 4 dBm)

Interpret Optical Levels:

For Copper Interfaces (RJ45):

# Check link speed negotiation
show interfaces ge-0/0/0 detail | grep -i "speed\|duplex"

# Expected: 1000base-T, full-duplex, no errors

Step 1.3: Inspect Physical Cable

Fiber Cable Inspection:

# Check for:
# 1. Proper connector seating (no half-inserted connectors)
# 2. Dirt/contamination on ferrule (use lint-free wipe)
# 3. Visible damage or bending
# 4. Correct cable type (SM vs MM if applicable)
# 5. Proper jumper fiber connection to transceiver

# Test with inspection microscope:
# - Look for scratches, pits, or core offset
# - Cleanliness of connector face

Copper Cable Inspection:

# Check for:
# 1. Proper RJ45 connector seating
# 2. Cable damage or creasing
# 3. Twisted pair integrity (should see all 8 wires ordered)
# 4. Correct pinout (568A/568B standard)

Step 1.4: Test Cable Continuity

Cable Testing (if equipment available):

# Fiber testing (if optical power meter available):
# 1. Measure RX power at far end
# 2. Compare with acceptable range
# 3. If low, test each fiber separately

# Copper testing (if TDR/continuity tester available):
# 1. Run cable test
# 2. Look for open circuits
# 3. Check impedance consistency

Step 1.5: Check for Connector Issue

Procedure:

# If cable looks good, connector may be faulty

# Test procedure:
# 1. Disconnect cable from interface
# 2. Inspect connector pins/ferrule with microscope
# 3. Look for:
#    - Oxidation (green/black residue)
#    - Bent pins (copper only)
#    - Debris
#    - Scratches on ferrule (fiber)

# If visible damage:
# 1. Clean with appropriate cleaner (lint-free solution)
# 2. Dry completely with compressed air
# 3. Inspect again
# 4. Reconnect and test

# If still flapping:
# Replace cable/connector completely

Step 1.6: Test with Different SFP (Fiber Only)

Procedure:

# If SFP module suspected:
# 1. Get known-good SFP of same type
# 2. Insert into same interface port
# 3. Monitor for flapping (30 min minimum)

show interfaces ge-0/0/0 terse
show log messages | grep "ge-0/0/0"

# If flapping stops:
# Original SFP is faulty - replace it
# If flapping continues:
# Port or cable issue - see other scenarios

SCENARIO 2: Configuration-Induced Flapping

Step 2.1: Check Interface Configuration

# Review complete interface configuration
show configuration interfaces ge-0/0/0.0

# Look for potentially problematic settings:
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24
set interfaces ge-0/0/0 disable  # <-- DISABLED would cause flap!
set interfaces ge-0/0/0 mtu 1500
set interfaces ge-0/0/0 link-mode full-duplex
set interfaces ge-0/0/0 speed 1g

Step 2.2: Check for Disable/Enable Statements

# Search for any disable statement
show configuration interfaces | grep -i "disable"

# If interface listed:
# Delete disable statement
delete interfaces ge-0/0/0 disable
commit

# Verify interface comes up
show interfaces ge-0/0/0.0 terse

Step 2.3: Verify Speed/Duplex Settings

# Check configured speed
show configuration interfaces ge-0/0/0 | grep -i "speed\|duplex"

# Verify matches connected device (check switch/router manual)

# If mismatch:
# Option 1: Set to auto-negotiate
set interfaces ge-0/0/0 speed 1g
delete interfaces ge-0/0/0 link-mode
commit

# Option 2: Set to specific speed (if auto-negotiate fails)
set interfaces ge-0/0/0 speed 1g
set interfaces ge-0/0/0 link-mode full-duplex
commit

Step 2.4: Check BPDU Guard / Loop Guard

# If STP enabled, check for guards
show configuration interfaces ge-0/0/0 | grep -i "guard\|bpdu"

# If BPDU Guard enabled, it may trigger flap
# Remove if not needed:
delete interfaces ge-0/0/0 unit 0 family bridge bpdu-guard-action

commit

Step 2.5: Check for Protocol Flaps (Not Physical)

# Interface physical link up, but protocol flapping
# Check if protocol being enabled/disabled repeatedly

show log messages | grep -i "ospf\|bgp\|vrrp" | grep "ge-0/0/0"

# If protocol messages but no physical state change:
# Issue is protocol-related, not physical
# See Scenario 3

SCENARIO 3: Protocol Convergence Flapping

Step 3.1: Check Dynamic Routing Protocol Status

# Check BGP neighbor state
show bgp summary
show bgp neighbor 10.0.0.2 detail

# Look for:
# ✗ Established -> Idle -> Established (flapping)
# ✓ Established (stable)
# ✗ Connect state (attempting connection)

If BGP Flapping:

# Check route flapping
show route receive-protocol bgp

# Check for rapid advertise/withdraw
show log messages | grep -i bgp | tail -30

# If flapping due to interface link changes:
# Fix underlying interface issue (See Scenario 1)

# If flapping despite stable interface:
# Check BGP configuration
show configuration protocols bgp | grep -A 5 "group peers"

Step 3.2: Check OSPF Adjacency

# Monitor OSPF neighbors
show ospf neighbor
show ospf neighbor detail

# Look for rapid state changes
show log messages | grep -i "ospf" | grep "neighbor" | tail -20

Step 3.3: Check VRRP State

# Check for VRRP transitions
show vrrp brief
show vrrp detail

# Look for Master/Backup cycling
show log messages | grep -i "vrrp" | tail -30

Step 3.4: Check STP Topology Changes

# Monitor STP stability
show spanning-tree statistics | grep "Topology"
show log messages | grep -i "topology.*change" | tail -20

# If excessive TCNs:
# Underlying interface flap is cause
# Return to Scenario 1 for physical troubleshooting

SCENARIO 4: Driver or Firmware Issue

Step 4.1: Check Interface Error Counters

# Detailed error analysis
show interfaces ge-0/0/0 extensive | grep -i "error\|crc\|drop"

Interpret Results:

# If error count > 100, physical issue likely
show interfaces ge-0/0/0.0 statistics | grep -i "error\|crc"

Step 4.2: Check Interface Statistics Over Time

# Collect baseline
show interfaces ge-0/0/0 extensive > iface_baseline.txt

# Check after 1 hour
show interfaces ge-0/0/0 extensive > iface_1hr.txt

# Compare error growth
diff iface_baseline.txt iface_1hr.txt | grep -i error

Step 4.3: Check for FPC/PIC Issues

# Check FPC status (on MX series)
show chassis fpc
show chassis fpc detail

# Look for:
# ✓ Online, Tested status
# ✗ Offline, Failed, Not Present

# Check for errors:
show chassis fpc 0 detail | grep -i "error\|alarm"

Step 4.4: Update Interface Firmware (if applicable)

# Check current firmware
show version
show interfaces ge-0/0/0 diagnostics information

# Document current version
# Check Juniper documentation for known flapping issues
# Update if available:
request chassis fpc slot 0 restart  # Restart FPC (will reset interfaces)

6. ADVANCED DIAGNOSTICS

Procedure 6.1: Packet Capture for Flap Analysis

Capture Physical Events:

# Start continuous capture during monitoring
request packet-capture interface ge-0/0/0 file /var/tmp/flap_capture.pcap count 500 timeout 60

# Monitor interface state while capturing
# Keep capture running for 1-2 flap cycles

# Save and analyze
file copy /var/tmp/flap_capture.pcap /var/tmp/backup/

Analyze in Wireshark: - Filter: lldp or stp (these indicate link up events) - Note timing of packets - Look for consistent pattern indicating cause

Procedure 6.2: Enable Interface Debug Tracing

For Complex Issues:

# Enable detailed interface tracing
set interfaces ge-0/0/0 traceoptions file iface_debug.log
set interfaces ge-0/0/0 traceoptions flag all

commit

# Monitor output
show log iface_debug.log | tail -f

# After issue reproduces, disable tracing
delete interfaces ge-0/0/0 traceoptions
commit

Procedure 6.3: Test Port with Loopback

Verify Port Hardware:

# Create loopback to test interface directly
# For fiber: Use optical loopback module
# For copper: Use Ethernet loopback adapter

# Insert loopback adapter into port
# Connect cable back to port

# Test if interface remains up
show interfaces ge-0/0/0 terse
show log messages | grep "ge-0/0/0" | tail -10

# If interface stays up with loopback:
# Problem is external (cable/far-end port)

# If interface flaps even with loopback:
# Local port/transceiver issue - replace

7. LOG COLLECTION FOR FLAP ISSUES

7.1 Basic Flap Diagnostics

Execute immediately:

# Capture current interface status
show interfaces ge-0/0/0 detail > flap_iface_detail.txt
show interfaces ge-0/0/0.0 terse > flap_iface_terse.txt
show interfaces ge-0/0/0 diagnostics > flap_diagnostics.txt

# For fiber, capture optical levels
show interfaces ge-0/0/0 diagnostics optics > flap_optical.txt

# Capture flap history
show log messages | grep "ge-0/0/0" > flap_history.txt
show log messages | grep -E "up|down" >> flap_history.txt

# Capture error counters
show interfaces ge-0/0/0 extensive > flap_extensive.txt
show interfaces statistics > flap_statistics.txt

# Capture configuration
show configuration interfaces ge-0/0/0 > flap_config.txt

7.2 Protocol-Specific Logs

If BGP/OSPF/VRRP affected:

# BGP diagnostics
show bgp neighbor 10.0.0.2 detail > flap_bgp.txt
show bgp summary >> flap_bgp.txt
show log messages | grep -i bgp >> flap_bgp.txt

# OSPF diagnostics
show ospf neighbor > flap_ospf.txt
show ospf neighbor detail >> flap_ospf.txt
show log messages | grep -i ospf >> flap_ospf.txt

# VRRP diagnostics
show vrrp detail > flap_vrrp.txt
show log messages | grep -i vrrp >> flap_vrrp.txt

# STP diagnostics
show spanning-tree brief > flap_stp.txt
show spanning-tree statistics >> flap_stp.txt
show log messages | grep -i "stp\|topology" >> flap_stp.txt

7.3 System-Wide Logs

Context for incident:

# System status
show system information > flap_system.txt
show chassis routing-engine > flap_cpu.txt

# Full system log during incident
show log messages | last 1000 > flap_system_log.txt

# Check for related alarms
show system alarms > flap_alarms.txt

8. FLAP RESOLUTION PROCEDURES

Resolution Procedure A: Physical Cable Replacement

When: CRC errors, optical levels out of range, visible cable damage

Steps:

# Step 1: Prepare replacement cable
# - Ensure correct type and length
# - Confirm connector types
# - Test replacement cable with loopback first

# Step 2: Disable interface (optional, may cause service impact)
set interfaces ge-0/0/0 disable
commit

# Step 3: Replace cable
# - Physically disconnect old cable
# - Document connection points
# - Install new cable
# - Ensure proper seating

# Step 4: Enable interface
delete interfaces ge-0/0/0 disable
commit

# Step 5: Monitor for stability
show interfaces ge-0/0/0 terse
show log messages | grep "ge-0/0/0" | tail -10

# Wait minimum 5 minutes for stability verification

Resolution Procedure B: SFP Module Replacement (Fiber)

When: Optical levels erratic, flapping despite good cable

Steps:

# Step 1: Prepare replacement SFP
# - Same type/speed as original
# - Known-good unit preferred
# - Verify compatibility with interface

# Step 2: Remove old SFP
# - Interface will go down (service impact)
# - Document time for change ticket

# Step 3: Install new SFP
# - Ensure proper seating
# - Clean ferrule before inserting

# Step 4: Verify interface comes up
show interfaces ge-0/0/0 terse
show interfaces ge-0/0/0 diagnostics optics

# Step 5: Monitor for 10 minutes minimum
show log messages | grep "ge-0/0/0"

Resolution Procedure C: Configuration Correction

When: Disable statements, speed mismatches, protocol issues

Steps:

# Step 1: Identify incorrect setting
show configuration interfaces ge-0/0/0 | grep -i "disable\|speed\|duplex"

# Step 2: Correct configuration
# Example: Remove disable
delete interfaces ge-0/0/0 disable
commit

# Or: Fix speed mismatch
set interfaces ge-0/0/0 speed 1g
commit

# Step 3: Verify interface state
show interfaces ge-0/0/0 terse

# Step 4: Monitor for stability (5-10 minutes)
show log messages | grep "ge-0/0/0" | tail -20

Resolution Procedure D: Port Replacement

When: Physical port issues, repeated flapping after cable/SFP replaced

Steps:

# Step 1: Identify replacement port
# - Same type and speed
# - Adjacent port on same FPC preferred
# - Verify no critical services using it

# Step 2: Move cable to replacement port
# - Service disruption will occur
# - Coordinate with stakeholders

# Step 3: Update configuration
delete interfaces ge-0/0/0
set interfaces ge-0/0/1 # New port
commit

# Step 4: Verify connectivity
show interfaces ge-0/0/1 terse
ping <far-end-address>

# Step 5: Monitor for stability (15+ minutes)

9. POST-RESOLUTION VERIFICATION

Checklist After Resolution:

[✓] Interface remains "Up" for minimum 15 minutes
[✓] No flap events in system log
[✓] Error counters stopped incrementing
[✓] Protocol sessions stable (BGP/OSPF Established)
[✓] Traffic passing normally
[✓] Optical levels normal (if fiber)
[✓] No excessive STP topology changes
[✓] CPU usage normal
[✓] All dependent services operational
[✓] Configuration backed up and documented

10. PREVENTION OF FUTURE FLAPS

Configuration Best Practices:

# Set appropriate MTU
set interfaces ge-0/0/0 mtu 1500

# Disable automatic speed negotiation if issues occur
set interfaces ge-0/0/0 speed 1g
set interfaces ge-0/0/0 link-mode full-duplex

# Enable monitoring
set interfaces ge-0/0/0 hold-time up 2000 down 0

# For critical interfaces, use BFD
set interfaces ge-0/0/0 family inet address 10.0.0.1/24
set protocols bgp group peers bfd-liveness-detection minimum-interval 300

# Document interface purpose
set interfaces ge-0/0/0 description "Link to Switch-B Port 1"

commit

Monitoring for Early Detection:

# Setup for automated alerts on flapping
# In your monitoring system (Nagios, Zabbix, etc.):
# - Alert if interface transitions > 5 times per hour
# - Alert if CRC errors increasing
# - Alert if optical RX power dropping

# Manual check (can be scripted):
show log messages | grep "ge-0/0/0" | wc -l  # Should be low

11. ESCALATION CRITERIA

Escalate to Hardware Support if:

1. Flapping persists after cable replacement
2. Flapping continues after SFP replacement
3. Multiple ports on same FPC flapping
4. Optical levels in dead band (too low/high)
5. Port shows persistent error counters
6. Issue occurs with loopback adapter installed
7. Port offline after reset attempt

Escalate to JTAC if:

1. Cannot identify root cause after 30 minutes
2. Flapping due to firmware/driver issue
3. Multiple interfaces flapping on same device
4. Flapping affects high-priority production services

Provide with escalation: - All logs from Section 7 - PCAP files (if captured) - Flap history from logs - Hardware/interface specifications - Timeline of troubleshooting steps - Results of each diagnostic step

12. COMMON FLAP CAUSES REFERENCE

13. REFERENCE - COMMAND QUICK REFERENCE

# Monitor flapping
show log messages | grep "ge-0/0/0"
show interfaces ge-0/0/0 terse
monitor interface ge-0/0/0

# Check optical levels
show interfaces ge-0/0/0 diagnostics optics

# Check errors
show interfaces ge-0/0/0 extensive | grep error

# Check configuration
show configuration interfaces ge-0/0/0

# Clear statistics (for baseline)
clear interfaces statistics ge-0/0/0

# Disable/enable interface
set interfaces ge-0/0/0 disable
delete interfaces ge-0/0/0 disable
commit

# Check BGP/OSPF
show bgp neighbor
show ospf neighbor

# View recent history
show log messages | last 100 | grep -i flap

14. DOCUMENT HISTORY

For Support: Contact Network Operations Center or JTAC
Document Owner: Network Engineering Team
Last Reviewed: June 12, 2026