[c-nsp] Best Practices to make one BGP link prefer for egrees and ingress traffic of one subnet

Saku Ytti saku at ytti.fi
Mon Feb 23 07:20:47 EST 2026


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
<cisco-nsp at puck.nether.net> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



-- 
  ++ytti


More information about the cisco-nsp mailing list