As far as I understand, any solution where you choose egress based on SADDR will be some form of PBR.
There are multiple flavors of PBR you could use here (VRF, SCU/DCU in some platforms), depending on the platform. But I don't see anything that could be fairly described as 'BGP native'. And I understand the impetus, PBR feels risky, fragile, complex (not saying it is, just it feels like something you want to avoid if possible), but with the requirements you have, I see no alternative. On Mon, 23 Feb 2026 at 13:55, Muhammad Atif Jauhar via cisco-nsp <[email protected]> wrote: > > Hi, > > I would like to seek your expert guidance on a BGP traffic engineering > scenario in our current network design. > > We have two eBGP uplinks with our Service Provider and are advertising > three internal network prefixes, which are learned via OSPF from our > downstream infrastructure. > > Our design requirement is as follows: > > - > > Prefer *Link #1* as the primary egress/ingress path for the following > prefixes: > - > > 192.168.1.0/24 > - > > 192.168.2.0/24 > - > > Prefer *Link #2* as the primary egress/ingress path for: > - > > 192.168.3.0/24 > > All three prefixes are being redistributed into BGP from OSPF. In the event > of a failure of either BGP uplink, the remaining active link should > automatically serve as the backup path for all advertised prefixes, > ensuring uninterrupted connectivity. > > For inbound traffic, we are currently influencing path selection using > AS-Path Prepending on a per-prefix basis. > > However, for outbound traffic, we are presently relying on Policy-Based > Routing (PBR) to steer traffic via the preferred uplink. While this > approach is functional, we would prefer to achieve the desired path > selection using BGP-native mechanisms, if possible, to ensure better > scalability and operational simplicity. > > We would appreciate your recommendation on best practices to implement > prefix-based outbound traffic engineering using BGP attributes (such as > Local Preference, MED, communities, etc.) instead of relying on PBR. > > Your insights on a more optimal and scalable design approach would be > highly valuable. > > > Regards, > > Muhammad Atif Jauhar > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
