Newbies Question: Do I really need to sacrifice Prefix-aggregation to do BGP Load-sharing? (the case of Multi-homed + Multi-routers + Multi-upstreams)

Pirawat WATANAPONGSE pirawat.w at ku.th
Wed Oct 19 06:27:34 UTC 2022


Dear Guru(s),


My apologies if these questions have already been asked;
in that case, please kindly point me to the answer(s).

I hope the following information sufficiently describes my current
"context":
- Single customer: ourselves
- One big IPv4 block + one big IPv6 block
- Native Dual-Stack, Non-tunneling
- Non-transit (actually, a “multi-homed Stub”)
- “All-green” IRR & RPKI registered (based on IRRexplorer report)
- Fully-aggregated route announcement (based on CIDR report)
- Two (Cisco) gateway routers on our side
- Two upstreams (See the following lines), fully cross-connected to our
gateways
- One (pure) commercial ISP
- One academic consortium ISP (who actually uses the above-mentioned
commercial ISP as one of its upstreams as well)

My current “situation”:
- All inbounds “flock” in through the commercial ISP, overflowing the
bandwidth;
since (my guess) the academic ISP also uses that commercial ISP as its
upstream, there is no way for its path to be shorter.

Questions:
1. Do I really have to “de-aggregate” the address blocks, so I can do the
“manual BGP load-sharing”?
I hate to do it because it will increase the global route-table entries,
plus there will be IRR & RPKI “hijack gaps” to contend with at my end.
2. If the answer to the above question is definitely “yes”, please point me
to the Best-Practice in doing the “manual BGP load-sharing (on Cisco)”.
Right now, all I have is:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13762-40.html#anc52

Thanks in advance for all the pointers and help given (off mailing-list is
also welcome).


Best Regards,

Pirawat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221019/2ef49cb3/attachment.html>


More information about the NANOG mailing list