Re: [uknof] Trimming the Routing Table

If you have a tiny budget and your topology and upstream providers allow it, land the transit BGP sessions on some virtual route reflectors, use multi hop eBGP for example or use a /29 on the peering link so the RRs don't need to sit in the data path. Then you don't needy some fancy OpenStack

Re: [uknof] Trimming the Routing Table

Many thanks for everyone's input so far there are some interesting approaches. My current supervisors hold up to 1 million routes and each have 1GB DRAM each for the route and switch processors. Andy, so are you saying that it's the DRAM I need to be concerned with only, as the FIB will only

Re: [uknof] Trimming the Routing Table

Hi Alistair, Please have a look at the webinar from Cumulus Networks and BORDER 6: URL: http://tinyurl.com/ogpc5bc With the Border 6 NSI Controller, Cumulus Linux switch-routers learn only the necessary BGP routes. Therefore they require less TCAM memory. Let me know if you need more details.

Re: [uknof] Trimming the Routing Table

> As a side note, does anybody have practical experience with taking two > tables and how this affects FIB and memory? Here I take two full feeds on two separate 2901's (IOS 15.2, each with 2.5GB RAM) which iBGP with each other. rtr1#sh bgp ipv4 unicast summary ... NeighborV

Re: [uknof] Trimming the Routing Table

On 2/Nov/15 13:06, Alistair Key wrote: > > > As a side note, does anybody have practical experience with taking two > tables and how this affects FIB and memory? My knowledge tells me that > only one table is stored in the FIB but both tables must remain in the > memory. Would help to know

Re: [uknof] Trimming the Routing Table

On 3/Nov/15 00:51, Neil J. McRae wrote: > In reality you need to stop trying to flog this horse and invest in a > new one, it's done. > All it will take is some config snafu and bang you are down. Try to > find some used kit if funds are tight NHR (they have a new name) or > Rincon might be

Re: [uknof] Trimming the Routing Table

On 02/11/15 14:31, Alistair Key wrote: > My current supervisors hold up to 1 million routes and each have 1GB > DRAM each for the route and switch processors. Sounds like Cisco SUP720 3BXL? Whilst there's a bit of headroom left in the TCAM, the 1GB RP memory they sport is beginning to look

Re: [uknof] Trimming the Routing Table

In reality you need to stop trying to flog this horse and invest in a new one, it's done. All it will take is some config snafu and bang you are down. Try to find some used kit if funds are tight NHR (they have a new name) or Rincon might be able to help - I wouldn't want to run into the Xmas

[uknof] Trimming the Routing Table

Hi All, Does anybody have any experience with practical ways to trim down the size of the global routing table in terms of prefixes? Unfortunately upgrading is not an option at this moment in time! I ideally need to take full feeds from providers for traffic engineering purposes, partial plus a

Re: [uknof] Trimming the Routing Table

On 2 November 2015 at 11:06, Alistair Key wrote: > Hi All, > > Does anybody have any experience with practical ways to trim down the size > of the global routing table in terms of prefixes? Feeling brave? http://route-aggregation.net/ J -- James Blessing 07989 039 476

Re: [uknof] Trimming the Routing Table

Hi, — Alistair wrote: > As a side note, does anybody have practical experience with taking two tables > and > how this affects FIB and memory? My knowledge tells me that only one table is > stored in the FIB but both tables must remain in the memory. Both tables must remain in memory if you are