We're in the middle of a phased migration from an MPLS + colo-DC setup to Cato SDP. The legacy side still runs BGP (AS 65001) out of our primary data center, peering with our ISPs and a couple of key partners. We've established the Cato socket there and are advertising a subset of routes (our new cloud app prefixes) from Cato into our DC via BGP, expecting them to propagate out the legacy WAN.
The problem: Route flapping. The prefixes advertised from Cato into our network are unstable. They appear, then withdraw, reappear a few minutes later. This is causing havoc for external partners who peer with us.
What we've verified so far:
* The BGP session between our edge router (Cisco ASR) and the Cato socket is stable (no resets).
* Our router shows consistent received advertisements from Cato.
* The flapping is observed on our other BGP peers (ISP and partners). The routes are being withdrawn and re-advertised by *our* router.
This points to our router making its own decision to stop advertising the Cato-learned routes. My leading theory is a mismatch in BGP attributes causing our local policy to mark them as invalid intermittently.
Relevant config snippet from our Cisco (sanitized):
```
router bgp 65001
neighbor 10.0.50.2 remote-as 65535
neighbor 10.0.50.2 description Cato-Socket
neighbor 10.0.50.2 ebgp-multihop 5
neighbor 10.0.50.2 update-source Loopback0
!
address-family ipv4
neighbor 10.0.50.2 activate
neighbor 10.0.50.2 route-map Cato-IN in
neighbor 10.0.50.2 route-map Cato-OUT out
no synchronization
exit-address-family
!
route-map Cato-IN permit 10
match ip address prefix-list Cato-Routes
set local-preference 150
!
route-map Cato-OUT permit 10
match ip address prefix-list Legacy-Routes-To-Cato
```
Has anyone else pushed Cato BGP into a complex legacy environment? Specifically:
1. Did you have to manipulate MED, AS_PATH, or community values from Cato to make your local BGP decision process stable?
2. Are there known issues with Cato's BGP implementation regarding route refresh or attribute consistency?
I need to see concrete configs or a reproducible scenario. "It works fine for us" isn't helpful without the underlying BGP policy details.
Show me the query.