This article documents a routing issue where a misconfigured subnet mask on interface prevented outbound ICMP and BGP traffic. The issue was resolved by correcting the subnet mask from /3 to /30

ICMP and BGP sessions were not establishing.

PE router was receiving traffic from the customer but was not transmitting any traffic out.

Affected services due to lack of outbound routing.

A configuration error where the subnet mask was incorrectly set to /3 instead of the required /30, resulting in improper routing behavior and packet forwarding issues.

The subnet mask was corrected via a configuration change on the affected logical interface.

re1> configure private

{master}[edit]

# Deleted incorrect subnet mask

delete interfaces lt-1/2/0 unit 2341 family inet address 100.x.x.x/3

# Applied correct subnet mask

set interfaces lt-1/2/0 unit 2341 family inet address 100.x.x.x/30

# Verified change

show | compare

[edit interfaces lt-1/2/0 unit 2341 family inet]

+  address 100.x.x.21/30;

-  address 100.x.x.21/3;

# Committed change with tracking comment

commit and-quit

Configuration was successfully committed on both routing engines.

Services were restored immediately after the change.

BGP sessions and ICMP traffic began flowing as expected.

When a subnet mask (CIDR value) is incorrectly configured—especially if it's overly broad (e.g., /3 instead of /30)—it causes the router to interpret the IP address as part of a vastly larger subnet. This can lead to several issues:

• Overlapping Subnets: The incorrectly large subnet may overlap with other valid subnets in the routing table, leading to unpredictable or incorrect routing decisions.
• Incorrect Next-Hop Resolution: The router may match traffic to an unintended route, or fail to resolve the correct next-hop entirely.
• BGP/ICMP Packet Drop: Packets sourced from or destined to the incorrectly configured interface might not be routed correctly, resulting in failure to establish BGP sessions and no response to ICMP pings.
• ARP Resolution Failure: In some cases, the device might not attempt ARP resolution if the destination is assumed to be within a large local subnet, even though it's actually unreachable.
• Traffic Blackholing: The router might believe it has a valid path due to the broad subnet, but that path leads nowhere, causing silent packet drops.