Article Detail

Description

In this article, we discuss a scenario where a BGP session is being established between two VRFs within the same device. Although the configuration correctly specifies the AS and peer address, the system reports that the AS sent over BGP is incorrect, causing the session to remain in active state. We analyze the root cause of this behavior and provide the solution.

Symptoms

Symptoms

EBGP sessions between 2 VRF on the same box.
The configuration correctly points to the appropriate peer AS.
BGP sessions remain active on both sides.
Open messages are being sent but not received.

Solution

We are working on establishing an EBGP session between two VRFs on the same device. The setup uses interface ae1 with the address 192.168.19.1/30 peering with interface ae2, configured with 192.168.19.1/30.

NOTE: The connectivity occurs point‑to‑point between physical interfaces on the same device. For the purposes of this discussion, we will not go into detail about how those connections are created.

After reviewing the configuration, we confirmed that the two interfaces can reach each other and that the BGP setup correctly references the appropriate physical IPs and VRF AS numbers. Here is the configuration from the AS at the global level:

routing-options {
router-id 100.100.100.100;
autonomous-system {
65100;
loops 2;
}
forwarding-table {
export load-balance-per-flow;

Here are both VRFs with the BGP session in question:

Routing-instances {
Test1 {
instance-type vrf;
routing-options {
router-id 10.10.10.10;
autonomous-system {
65110;
loops 2;
independent-domain {
no-attrset;
}
}
multipath;
auto-export;
}
protocols {
bgp {
group test {
type external;
mtu-discovery;
family inet {
unicast;
}
neighbor 192.168.19.2 {
peer-as 65120;
}
}
}
}
interface ae2;
interface lo0.1;
route-distinguisher 10.10.10.10:1111;
vrf-target target:1000:1000;
vrf-table-label;
}

Test2 {
instance-type vrf;
routing-options {
router-id 10.10.10.20;
autonomous-system {
65120;
loops 2;
independent-domain {
no-attrset;
}
}
multipath;
auto-export;
}
protocols {
bgp {
group test {
type external;
mtu-discovery;
family inet {
unicast;
}
neighbor 192.168.19.1 {
peer-as 65110;
}
}
}
interface ae1;
interface lo0.2;
route-distinguisher 10.10.10.20:2222;
vrf-target target:1000:1000;;
vrf-table-label;

Despite this, the logs show that the AS number being advertised over BGP is incorrect, and the following error messages are generated.

Feb 13 12:35:55.560 2026 maindevice rpd[14537]: bgp_process_open:5032: NOTIFICATION sent to 192.168.19.1 (External AS 65110): code 2 (Open Message Error) subcode 2 (bad peer AS number), Reason: peer 192.168.19.1 (External AS 65110) claims 65100, 65110 configured,peer_autodiscovered 0,bgp_group_ok_for_peer_as_list 0
Feb 13 12:35:59.555 2026 maindevice rpd[14537]: bgp_pp_recv:5726: NOTIFICATION sent to 192.168.19.2+58763 (proto): code 2 (Open Message Error) subcode 2 (bad peer AS number), Reason: no group for 192.168.19.2+58763 (proto) from AS 65110 found (peer as mismatch) in Test1(null-interface), dropping him

We can see the adjacencies remain active:

root@maindevice> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 2
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.19.1 65110 0 0 0 0 1w5d 21:08:12 Active
192.168.19.2 65120 0 0 0 0 1w5d 21:08:12 Active

When reviewing the BGP traceoptions for 192.168.19.1 on Test1 VRF, We can see that the BGP neighbor is attempting to send the initial Open message to itself:

Feb 16 14:25:33.924304 BGP SEND 192.168.19.1+58403 -> 192.168.19.1+179 > Here
Feb 16 14:25:33.924309 BGP SEND message type 3 (Notification) length 21
Feb 16 14:25:33.924316 BGP SEND Notification code 2 (Open Message Error) subcode 2 (bad peer AS number)
Feb 16 14:25:33.924350 BGP_65100.65110.192.168.19.1: send proc: writev 21/21 bytes, rc 1
Feb 16 14:25:33.924359 bgp_peer_close_and_restart: peer 192.168.19.1 (External AS 65120), state is 4 (OpenSent) event RecvOpen, flags=0x0
Feb 16 14:25:33.924367 bgp_peer_close_and_restart: closing peer 192.168.19.1 (External AS 65120), state is 4 (OpenSent) event RecvOpen
Feb 16 14:25:33.924398 bgp_send_deactivate:3837: 192.168.19.1 (External AS 65120) ,flags=0x0: removed from active list

When reviewing the BGP neighbors, both peers are sending Open messages but were not receiving the Open message from their counterpart:

root@maindevice> show bgp neighbor 192.168.19.2
Peer: 192.168.19.2 AS 65120 Local: 192.168.19.2 AS 65110 > Peering its own IP address.
Description: Test1
Group: self Routing-Instance: Test1
Forwarding routing-instance: Test1
Type: External State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: Open Message Error
Options: <AddressFamily PeerAS Refresh>
Options: <MtuDiscovery BfdEnabled>
Options: <GracefulShutdownRcv>
Address families configured: inet-unicast
Holdtime: 90 Preference: 170
Graceful Shutdown Receiver local-preference: 0
Number of flaps: 0
Receive eBGP Origin Validation community: Reject
Error: 'Open Message Error' Sent: 7561 Recv: 0 > No open messages error received.
Trace options: all
Trace file: /var/log//bgp.txt size 5242880 files 5

root@maindevice> show bgp neighbor 192.168.19.1
Peer: 192.168.19.1 AS 65110 Local: 192.168.19.1 AS 65120 > Peering its own IP address.
Description: Test2
Group: self Routing-Instance: Test2
Forwarding routing-instance: Test2
Type: External State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: Open Message Error
Options: <AddressFamily PeerAS Refresh>
Options: <MtuDiscovery BfdEnabled>
Options: <GracefulShutdownRcv>
Address families configured: inet-unicast
Holdtime: 90 Preference: 170
Graceful Shutdown Receiver local-preference: 0
Number of flaps: 0
Receive eBGP Origin Validation community: Reject
Error: 'Open Message Error' Sent: 7561 Recv: 0 > No open messages error received.
Trace options: all
Trace file: /var/log//bgp.txt size 5242880 files 5

The BGP configuration toward the neighbor peer and AS appears correct. However, the issue arises because the VRFs are resolving their local addresses to the same IPs that are configured for peering. In Junos, if the peer’s interface address is also present as a connected or local address within the same VRF, the system will select that address as the source through local route resolution.

While reviewing the physical interfaces assigned to the VRFs, we found that EBGP was resolving peer IPs locally because the aggregation links within the VRFs included the peer interfaces instead of the intended local interface that should have been used as the session source.

Specifically, interface ae1 (192.168.19.1) was mistakenly configured under VRF Test2 when it should have been part of Test1 to provide the correct source IP for the EBGP session. Conversely, interface ae2 (192.168.19.2) was placed under VRF Test1. This misalignment caused EBGP to source traffic incorrectly, leading to the behavior we observed.

The issue will be resolved by changing the correct interfaces within the corresponding VRFs:

root@maindevice> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 2
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.19.1 65110 3285 3284 0 0 1:04:57 Establ
192.168.19.2 65120 3285 3283 0 0 1:04:57 Establ

Modification History

2026-02-18 : Article Created