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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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 < > [email protected]> > > > 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 <[email protected]> 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 < > > >>> [email protected]> 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 > > >>>> [email protected] > > >>>> _______________________________________________ > > >>>> cisco-nsp mailing list [email protected] > > >>>> https://puck.nether.net/mailman/listinfo/cisco-nsp > > >>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > >>>> > > >>> > > _______________________________________________ > > 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/
