Fix IndexError when parsing FIB route keys without colon

[nnelluri-cisco]

Description of PR

The FIB parsing code assumed all route keys contain a colon (:) and
attempted to split on it unconditionally:
prefix = k.split(':', 1)[1]

When a key like 'ROUTE_TABLE_DEL_SET' (without colon) is encountered,
split(':') returns a single-element list, causing IndexError when
accessing index [1].

Error:
prefix = k.split(':', 1)[1]
IndexError: list index out of range

Summary:
Added a safety check to verify colon exists before splitting:
if ":" in k:
prefix = k.split(':', 1)[1]
else:
continue

This ensures only properly formatted route keys (containing ':') are
processed, and malformed keys are skipped gracefully.
Fixes # (issue)

Type of change

• [X ] Bug fix
• Testbed and Framework(new/improvement)
• New Test case
  • Skipped for non-supported platforms
• Test case improvement

Back port request

• 202205
• 202305
• 202311
• 202405
• 202411
• [X ] 202505
• [ X] 202511

Approach

What is the motivation for this PR?

Fix an IndexError crash in FIB (Forwarding Information Base) route parsing that occurs when processing route table
Error:

prefix = k.split(':', 1)[1]
IndexError: list index out of range

How did you do it?

Added a safety check to verify the presence of a colon before attempting to split route keys:

Before:

prefix = k.split(':', 1)[1]  # Assumes colon always exists

After:

if ":" in k:
    prefix = k.split(':', 1)[1]
else:
    continue  # Skip keys without proper format

This ensures only properly formatted route keys (e.g., ROUTE_TABLE:192.168.0.0/24) are processed, while malformed or special keys are gracefully skipped.

How did you verify/test it?

1. Reproduced the issue with test_basic_fib
2. Applied the fix and confirmed test passes
3. Verified that normal route entries with colons still parse correctly
4. Tested with various key formats:
   • Standard routes: ROUTE_TABLE:10.0.0.0/24 ✓
   • IPv6 routes: ROUTE_TABLE:fc00::fc/126 ✓
   • Special keys: ROUTE_TABLE_DEL_SET ✓ (now skipped gracefully)
5. Ran full test suite to ensure no regressions

Any platform specific information?

Platform dependency: None - this is a generic parsing fix

Supported testbed topology if it's a new test case?

• Existing topologies: t0, t1, t1-lag

Documentation

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[nnelluri-cisco]

@bhavani
Can you please review and approve the PR

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[nnelluri-cisco]

@prabhataravind @xwjiang-ms
can you please review and merge the PR

[Copilot]

Pull request overview

This PR fixes an IndexError in FIB (Forwarding Information Base) route parsing that occurs when Redis keys without colons (e.g., ROUTE_TABLE_DEL_SET) are encountered. The code previously assumed all route keys contain a colon and attempted to split on it unconditionally, causing an IndexError when accessing the second element of a single-element list.

Changes:

• Added safety check to verify colon presence before splitting route keys in get_fib_info function
• Keys without colons are now skipped gracefully using continue statement

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).