Hello,
Your issue with BGP not coming up, despite the PPPoE and connectivity being established, seems to be related to BGP's reachability and how it resolves the path to the peer. Even though ICMP pings are working, BGP requires proper routing paths between the Loopback interfaces used as the BGP source addresses.
Let's troubleshoot this issue step by step:
1. Verify IGP Reachability of the Loopbacks:
Since you are using the loopback interfaces as BGP update sources, ensure that the BRAS can route to the CPE’s Loopback0 via the IGP (such as OSPF, EIGRP, or static routes).
- Check if the CPE’s Loopback0 is being advertised into the IGP on the BRAS side.
- On the BRAS, use show ip route <CPE Loopback0 IP> to verify if the loopback is reachable via the IGP. If it’s not, BGP will not establish the session.
Suggestion:
- Ensure that the CPE’s Loopback0 IP is redistributed into the IGP or that you have appropriate static routes on the BRAS to reach it.
2. Ensure the Correct BGP Peering Configuration:
On both the CPE and the BRAS, verify that the update-source is correctly set to the Loopback interfaces. Also, check if the neighbor statements are using the correct IP addresses (the Loopback IPs) for peering.
CPE BGP Config:
router bgp <AS number>
neighbor <BRAS Loopback> remote-as <BRAS AS number>
neighbor <BRAS Loopback> update-source Loopback0
BRAS BGP Config:
router bgp <AS number>
neighbor <CPE Loopback> remote-as <CPE AS number>
neighbor <CPE Loopback> update-source Loopback0
Make sure both sides are configured to use the loopbacks and that the IP addresses are correct.
3. Check Routing Tables and Next Hop:
BGP uses the next-hop IP in its path selection. Ensure that both the BRAS and the CPE can see each other’s Loopback IPs in their routing tables, and that the next hop is properly reachable.
Use the following commands to verify:
On the BRAS
show ip route <CPE Loopback>
On the CPE
show ip route <BRAS Loopback>
4. Consider Static Routes for BGP Peer Reachability:
If the loopback is not advertised into the IGP, you can use static routes as a workaround. Add static routes on the BRAS to point to the CPE's loopback address via the PPPoE interface, and vice versa.
On BRAS
ip route <CPE Loopback0> <next hop through dialer>
On CPE
ip route <BRAS Loopback0> <next hop through dialer>
5. Verify TCP MSS and MTU Settings:
Since PPPoE reduces the available MTU, it is good that you’ve already adjusted the TCP MSS. You might also want to ensure that there are no issues with packet fragmentation or firewall rules dropping fragmented packets.
The commands you’ve set for mtu 1492 and ip tcp adjust-mss 1452 seem appropriate for PPPoE, but you can check if there’s any fragmentation by doing a ping test with the DF bit set:
ping <BGP peer IP> source Loopback0 df-bit size 1472
If this fails, it indicates an issue with fragmentation. Adjust the MTU settings accordingly.
6. Check BRAS Logs and ACLs:
Review the BRAS logs to ensure there are no Access Control Lists (ACLs) blocking BGP traffic. Sometimes, BGP sessions are rejected if the required TCP port (179) is not allowed by an ACL on either side.
Check if ACLs are applied on the interface:
show ip interface <interface>
If there are any ACLs applied, ensure that BGP (TCP port 179) is allowed.
7. Debug BGP on CPE and BRAS:
Enable BGP debugging on both sides to capture more details about the failure:
On the CPE:
debug ip bgp
debug ip tcp transactions
On the BRA:
debug ip bgp
debug ip tcp transactions
This will give you more insight into why the TCP RST is being sent.
8. Check RADIUS Attribute for Consistency:
Since you’re using a Cisco-AVpair attribute for the loopback IP in RADIUS, ensure that the attribute is correctly being applied to both dialer interfaces and that both BRAS have a consistent view of the CPE’s loopback.
If you follow these steps and ensure that both BRAS have a route to the CPE’s loopback, the BGP session should come up without issue.
