BGP offloading (fixing legacy router BGP scalability issues)

Ca By cb.list6 at gmail.com
Thu Apr 2 03:28:54 UTC 2015


On Wednesday, April 1, 2015, Frederik Kriewitz <frederik at kriewitz.eu> wrote:

> Hello,
>
> We've a lot of customers with Cisco 6500 routers (mostly with SUP720
> supervisors) in operation. They are very popular with smaller ISPs in
> Africa/middle east due to their cheap price on the used marked and
> their fully sufficient routing performance for the given tasks. In
> practice the biggest problem with them is their poor BGP scalability
> due to the CPU/memory limitations.
>
> We're looking into options for a cheap fix for this problem.
>
> The idea is to offload BGP IPv4/IPv6 RIB calculation from the router
> to a standard server. All BGP sessions will be handled by the server.
> The server takes care of the RIB calculation and aggregates the result
> as much as possible (the aggregation potential of the global tables
> should be very high if it can completely ignore the AS path and only
> care about the next hop). The final optimized RIB is then pushed to
> the Router via an iBGP session (the only BGP session configured on the
> router).
>
> If there's room in the transfer net for the server and the router, the
> setup is simple (eBGP session is established with the server and
> next-hop is set to the router).
>
> In other peering situations the setup might be more challenging. E.g.
> with typical IXP constrains (only a single MAC address/IP address
> allowed) the session would have to be a multihop session and an
> additional static route (host route for the server) on the peer router
> should be installed.
>
> Another way to make the server appear completely transparent for other
> peers (no special configuration on the peer side) might be NAT for the
> BGP port to the server or proxy ARP. But we would like to avoid doing
> NAT with a SUP720 and proxy ARP would make us the default gateway for
> any incorrectly configured IXP participant router and a configuration
> error on our side might cause severe harm to the IXP. And of course
> both ideas won't work for IPv6 (SUP720 doesn't support NAT for IPv6 or
> proxy NDP).
>
> The only solution to make it fully transparent for IPv4 and IPv6 we
> came up with it is to configure the IXP router interface as unnumbered
> + static route for the IXP nets + host routes for the assigned IXP IPs
> to the server. In that case the server would have to monitor the IXP
> vlan and take care of responding to ARP and Neighbor Solicitation
> requests for the IXP IPs (using the MAC of the router). Additionally
> it might be necessary to inject the ARP/IPv6 neighbors into the cisco
> using static entries (to avoid sending ARP/NS requests with a non IXP
> IP).
>
> We're wondering if anyone has experience with such a setup?
>
>
> Best Regards,
>
> Freddy
>

Do these use cases really require a full table?

Could you get-by with a simple filter Less than or equal to /22 ?
Especially applying such a filter to non-local / inter-continental routes?

I have done similar for a long time on 7600s, works fine for me (with a
default from my upstream)

CB



More information about the NANOG mailing list