Re: [uknof] Trimming the Routing Table

[James Bensley]

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 cluster with IOS-XRv/CSRv/vMX
etc, just a couple of spare servers you've got lying around with KVM and
quagga/bird will do if you just want to hold more routes.

Cheers,
James.

Re: [uknof] Trimming the Routing Table

[Alistair Key]

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 store one routing table at a time?

PS, I did see methods filtering prefixes longer than 'n' hops - could
anybody provide a better 'n' value? :)

The majority of my traffic around Europe and Americas is what I need
control over to influence outbound and inbound routing - anything further
such Asia and Africa - a default prefix should suffice - do you think this
could adequately trim my prefix count if I filter AS's from these countries
/ certain AS-path length cut off?

Again many thanks so far for your help chaps!

Regards,
Alistair

On 2 November 2015 at 13:07, Mark Tinka  wrote:

>
>
> 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 platforms you're running, so folk can provide more
> meaningful help (if possible).
>
> Mark.
>

Re: [uknof] Trimming the Routing Table

[Pawel Rybczyk]

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.

Regards,
Pawel Rybczyk
Product Engineer
BORDER 6


On 11/02/2015 12:06 PM, 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?
> 
> 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 default from both providers still brings me not much further.
> 
> 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.
> 
> Many Thanks,
> Alistair
> 

Re: [uknof] Trimming the Routing Table

[Brian Candler]

> 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   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd
aaa.aa.aa.aaa   4   ii 10212329 8301380 31450264100 
12w4d  464785
xxx.xx.xxx.xxx  4  2480652   37924 314502611 00 
1w5d   554247


rtr1# sh bgp ipv6 unicast summary
...
NeighborV   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd

:xxx:::
4   567657   83036 33790410 00 
3w5d24596

::a:aaa::aaa
4   ii 1148950  831084 33790417 00 
12w4d   18914


rtr1#sh proc memory sorted
Processor Pool Total: 2368073936 Used:  578934948 Free: 1789138988
  I/O Pool Total:  117440512 Used:   18606288 Free:   98834224

 PID TTY  Allocated  FreedHoldingGetbufsRetbufs Process
 336   0  885066900 1989483932  430124080  0  0 BGP Router
 204   0  195215412  214911576   96650648  0  0 IP RIB 
Update

   0   0  151904364   90387224   57900300  0  0 *Init*
 237   0   13212848   201407603125708  0  0 IPv6 
RIB Event H

 277   01275836  183321264768  0  0 EEM Server
   0   0 2149920572 3079609700 8423482483563  0 *Dead*
 273   0 463520   3756 445548  0  0 VLAN 
Manager
 335   0 441272  22644 419044  0  0 
OSPF-100 Router

...

And the other one is similar:

rtr2#sh bgp ipv4 unicast summary
...
NeighborV   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd
yyy.yy.y.yyy4  17504637  139480 39393026 00 
12w4d  552998
bbb.bb.bb.bbb   4   ii 8301832 10212667 39393503 00 
12w4d  431682


rtr2#sh bgp ipv6 unicast summary
...
NeighborV   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd

:yyy:y:yy::y:y
4  1973378  139518  2167092 00 
12w4d   23160

::b:bbb::bbb
4   ii  831122 1148977  2167092 00 
12w4d   19563


rtr2#sh proc memory sorted
Processor Pool Total: 2368097488 Used:  568174800 Free: 1799922688
  I/O Pool Total:  117440512 Used:   18572320 Free:   98868192

 PID TTY  Allocated  FreedHoldingGetbufsRetbufs Process
 336   0  450496888  863316832  419524372  0  0 BGP Router
 204   0   952448683110848   94214820  0  0 IP RIB 
Update

   0   0  151998800   90378244   57906052  0  0 *Init*
 237   05513424 1059005523444  0  0 IPv6 
RIB Event H

 277   01275788  183321264720  0  0 EEM Server
   0   0 3713827068 3955372652 7495362440471  0 *Dead*
 273   0 463520   3756 445548  0  0 VLAN 
Manager
 335   0 423284  0 423068  0  0 
OSPF-100 Router

...

(x and y are upstreams, a/b are the iBGP peers)

So a little over half a gig in total is used on each router. I am doing 
only the most basic bogon filtering, otherwise accepting everything 
offered, no default, and no soft-reconfiguration inbound.


As I understand it, BGP soft reset makes soft-reconfiguration inbound 
unnecessary anyway:

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_sftrst.html

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.

http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf

Regards,

Brian.

Re: [uknof] Trimming the Routing Table

[Mark Tinka]

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 platforms you're running, so folk can provide
more meaningful help (if possible).

Mark.

Re: [uknof] Trimming the Routing Table

[Mark Tinka]

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 able to help - I wouldn't want to run into the Xmas
> period with this situation that's for sure. 
>
> It seems nuts that traffic control over stability and reach ability is
> important here.

I would have to agree.

Mark.

Re: [uknof] Trimming the Routing Table

[Tom Hill]

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 strained for
routers receiving full table transit sessions.

If so, I'd start by making sure you're not accepting prefixes equal-to
or greater than a /25 from upstreams/peers. (The same limit of /49 goes
for IPv6).

Trying to filter based on 'ASNs of a country' is problematic, to say the
least. The same goes for 'prefixes of a country'. Though note that /24
prefixes (and /48 for IPv6) make up around half of the DFZ table, so
there's your semi-tactical nuclear option.

Other things that might help:

 1. Not using 'soft-configuration in' (as per Andy)
 2. If you're using multiple supervisors, RPR+ will use less memory than
SSO redundancy, at the expense of time-to-fail-over
 3. IOS 12.2SRE uses a fair bit less RAM than anything 15.x

But really, getting to the point of #2 or #3 is a bit hap-hazard, vs.
just buying new routers. The 6880-XL (actually XXL as it has a 2M IPv4
FIB), the ASR1K (with enough DRAM) and the ASR9k are all very sensible
Cisco upgrade routes, of varying cost.

Presuming I'm right about the SUP720, you should be pestering management
daily to start budgeting for new routers *very* early into the new
financial year. :)

If you need to last slightly longer, the RSP720 3CXL has the same TCAM
limit as the SUP720 3BXL, but a greater DRAM limit (>4GB for the RP, if
I recall correctly) and that is a drop-in replacement for most of the
7600/6500 configurations that people run.

Just be careful, as support costs for those systems becomes per-LC
rather than per-chassis, and if you have any 3BXL DFC daughter boards
(show module, show inv) then you'll need to replace those with 3CXL
equivalents.

HTH,

-- 
Tom

Re: [uknof] Trimming the Routing Table

[Neil J. McRae]

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 period with this situation 
that's for sure.

It seems nuts that traffic control over stability and reach ability is 
important here.

Regards,
Neil

Sent from my iPhone

On 2 Nov 2015, at 14:34, Alistair Key 
> wrote:

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 store one routing table at a time?

PS, I did see methods filtering prefixes longer than 'n' hops - could anybody 
provide a better 'n' value? :)

The majority of my traffic around Europe and Americas is what I need control 
over to influence outbound and inbound routing - anything further such Asia and 
Africa - a default prefix should suffice - do you think this could adequately 
trim my prefix count if I filter AS's from these countries / certain AS-path 
length cut off?

Again many thanks so far for your help chaps!

Regards,
Alistair

On 2 November 2015 at 13:07, Mark Tinka 
> wrote:


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 platforms you're running, so folk can provide more 
meaningful help (if possible).

Mark.

[uknof] Trimming the Routing Table

[Alistair Key]

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 default from both providers still brings me not much further.

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.

Many Thanks,
Alistair

Re: [uknof] Trimming the Routing Table

[James Blessing]

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

[Andy Davidson]

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 doing soft-reconfiguration inbound 
(“Keep all” in Juniper dialect).  Can turn that off if you support route 
refresh.

Andy