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

[Muhammad Atif Jauhar]

Hi,

I am not facing any problem just need advice for best approach for my
scenario.

Regards,

Muhammad Atif Jauhar
(+966-5600-04985)

On Mon, Feb 23, 2026, 21:57 Saku Ytti <saku at ytti.fi> wrote:

> 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
>