On 2 Nov 2015 12:43, "James Blessing" wrote:
>
> 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/
>
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 clus
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 abl
On 02/11/15 22:51, Neil J. McRae wrote:
> NHR (they have a new name)
Indeed, they're now called Curvature - and to help with the transition,
everyone's tame account manager (Neil) also moved on to another business.
(I can provide contact details for his replacement off-list if anyone
needs them,
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 pe
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 straine
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.
R
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 stor
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 what
On 02/11/2015 12:55, Brian Candler wrote:
Aside: a new 2901 with 2.5GB RAM should set you back less than a
grand. However it may not have the throughput you need: it's rated at
327Kpps, which is 167Mbps with 512-byte packets.
I forgot 8 bits per byte, doh! It's 167Mbps with 64-byte packets.
> 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
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
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
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 d
14 matches
Mail list logo
