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

[Saku Ytti]

But you stated you already have a working PBR solution.

What acute problems are you trying to solve?

Like one option could be that you use VRF, where you have Transit1,
Transit2 VRF.
Then you have Edge1 and Edge2 VRF.

On Edge1 VRF import you prefer Transit1
On Edge2 VRF import you prefer Transit2

Then you put 1/24, 2/24 on Edge1 and 3/24 on Edge2.

But all this of course largely hinges on what actual problems you have
with your current PBR setup.

On Mon, 23 Feb 2026 at 20:31, Muhammad Atif Jauhar via cisco-nsp
<cisco-nsp at puck.nether.net> wrote:
>
> Thanks Arie،
>
> We are planning for SDWAN but in 3rd quarter of this year. But before this
> we need something to work.
>
> Regards,
>
> Muhammad Atif Jauhar
> (+966-5600-04985)
>
> On Mon, Feb 23, 2026, 20:08 Arie Vayner <ariev at vayner.net> wrote:
>
> > Muhammad,
> >
> > As you mention specific destinations that you seem to own/manage on both
> > ends, wouldn't it make more sense to run some overlay here, with tunnels
> > taking all available paths, and some simple SD-WAN-like routing policies
> > selecting the correct overlay for the relevant traffic?
> >
> > Tnx
> > Arie
> >
> > On Mon, Feb 23, 2026, 8:03 AM Muhammad Atif Jauhar <atif.jauhar at gmail.com>
> > wrote:
> >
> >> Hi,
> >> Thank you both for your feedback.
> >>
> >> Basically, one subnet is for backup environment and other link is for
> >> normal user traffic toward Data center.
> >>
> >> If we use one link most of the bandwidth captured by backup to avoid any
> >> bandwidth issue and slowness faced by users, we acquired one link for only
> >> backup and replication.
> >>
> >> Now want to segregate traffic on both link to avoid any bandwidth issue.
> >>
> >> Regards,
> >>
> >> Muhammad Atif Jauhar
> >> (+966-5600-04985)
> >>
> >> On Mon, Feb 23, 2026, 17:36 Arie Vayner <ariev at vayner.net> wrote:
> >>
> >>> Muhammad,
> >>>
> >>> To add to Gert's comment about symmetry... Can you please try and
> >>> explain why you have that requirement?
> >>>
> >>> I think this may be a case of reassessing the requirements before going
> >>> into solution mode.
> >>>
> >>> Tnx,
> >>> Arie
> >>>
> >>> On Mon, Feb 23, 2026, 5:36 AM Gert Doering via cisco-nsp <
> >>> cisco-nsp at puck.nether.net> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> On Mon, Feb 23, 2026 at 02:50:55PM +0300, Muhammad Atif Jauhar via
> >>>> cisco-nsp wrote:
> >>>> > 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.
> >>>>
> >>>> There is none.  BGP does not care about packet source addresses.
> >>>>
> >>>> (That said, you could trick around with VRFs, but it's questionable
> >>>> if that will be more satisfactory in the end)
> >>>>
> >>>> Symmetric traffic is an illusion, and trying to achieve that in
> >>>> "the Internet" is time not spent well.
> >>>>
> >>>> gert
> >>>> --
> >>>> "If was one thing all people took for granted, was conviction that if
> >>>> you
> >>>>  feed honest figures into a computer, honest figures come out. Never
> >>>> doubted
> >>>>  it myself till I met a computer with a sense of humor."
> >>>>                              Robert A. Heinlein, The Moon is a Harsh
> >>>> Mistress
> >>>>
> >>>> Gert Doering - Munich, Germany
> >>>> gert at greenie.muc.de
> >>>> _______________________________________________
> >>>> 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/
> >>>>
> >>>
> _______________________________________________
> 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