From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Sun Nov 30 2003 - 21:12:20 GMT-3
Jim & Tony,
Maybe I didn't make this as clear as I should have in the last
thread, but the memory savings is the difference of the full view and your
filtered view. If you are just taking a full view without filtering,
enabling or disabling soft reconfig won't really make that much of a
difference either way.
Suppose your full view takes 50Mb of memory. If you're filtering
off half of the prefixes you should be using about 25Mb of memory. However,
if soft reconfig inbound is enabled, you'll still be using about 50Mb. This
is because the pre-filtered view is still stored in memory. Here's a small
scale example of the implications of both soft reconfig:
PC--R1--R2
The PC is running Nantech TrafficGen, a BGP route injector program
for windows. This app is peering BGP with R1, and generating around 1900
prefixes.
Rack1R1#show ip bgp sum | in (Neighbor|172.16.2.2)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
172.16.2.2 4 65001 17002 62 1987 0 0 00:25:28 1919
R1 is peering with R2. The measurements of memory usage will be
taken on R2. First let's take a look at R2's memory usage without any
filtering:
Rack1R2#sh ip bgp sum
BGP router identifier 2.2.2.2, local AS number 100
BGP table version is 1, main routing table version 1
1918 network entries using 193718 bytes of memory
1918 path entries using 92064 bytes of memory
482 BGP path attribute entries using 28920 bytes of memory
443 BGP AS-PATH entries using 12056 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 326758 total bytes of memory <------- 320Kb total
BGP activity 1918/0 prefixes, 1918/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
204.12.1.1 4 100 506 4 1 0 0 00:00:40 1918
Rack1R2#sh proc mem | in (PID|BGP)
PID TTY Allocated Freed Holding Getbufs Retbufs Process
101 0 283144 0 276168 0 0 BGP Router
102 0 0 0 6944 0 0 BGP I/O
103 0 0 0 9916 0 0 BGP Scanner
We can see that R2 peering with R1 (204.12.1.1), receiving just over
1900 prefixes, and using about 320Kb for BGP.
Next let's apply a filter to this view. The filter will permit
prefixes originated by our directly connected neighbors and their customers.
Rack1R2(config)#ip as-path access-list 1 permit ^[0-9]+_[0-9]+$
Rack1R2(config-router)#nei 204.12.1.1 filter-list 1 in
Rack1R2#clear ip bgp * in
Rack1R2#sh ip bgp sum
BGP router identifier 2.2.2.2, local AS number 100
BGP table version is 1, main routing table version 1
1918 network entries using 193718 bytes of memory
28 path entries using 1344 bytes of memory
9 BGP path attribute entries using 28920 bytes of memory
443 BGP AS-PATH entries using 12056 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
482 BGP filter-list cache entries using 5784 bytes of memory
BGP using 241822 total bytes of memory <--- now using 240Kb total
BGP activity 1918/0 prefixes, 1918/1890 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
204.12.1.1 4 100 1001 8 1 0 0 00:03:46 28
PID TTY Allocated Freed Holding Getbufs Retbufs Process
101 0 297856 67836 223044 0 0 BGP Router
102 0 0 0 6944 0 0 BGP I/O
103 0 0 0 9916 0 0 BGP Scanner
As we can see the view has been reduced significantly from about
1900 to about 30 prefixes. Memory utilization has reduced from 320Kb to
240Kb. Note that R2 is not saving the prefixes that it is filtering out.
It is receiving them, processing them, then throwing them away. Now let's
apply soft reconfig inbound to R1.
Rack1R2(config)#router bgp 100
Rack1R2(config-router)#nei 204.12.1.1 soft-reconfiguration inbound
Rack1R2#clear ip bgp * in
Rack1R2#sh ip bgp sum
BGP router identifier 2.2.2.2, local AS number 100
BGP table version is 1, main routing table version 1
1918 network entries using 193718 bytes of memory
1918 path entries using 92064 bytes of memory
482 BGP path attribute entries using 28920 bytes of memory
443 BGP AS-PATH entries using 12056 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
482 BGP filter-list cache entries using 5784 bytes of memory
BGP using 332542 total bytes of memory <--- about 330Kb used now
1890 received paths for inbound soft reconfiguration
BGP activity 5726/3808 prefixes, 5726/3808 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
204.12.1.1 4 100 1993 17 1 0 0 00:00:32 28
Rack1R2#sh proc mem | in (PID|BGP)
PID TTY Allocated Freed Holding Getbufs Retbufs Process
101 0 847504 332412 289692 0 0 BGP Router
102 0 0 0 6944 0 0 BGP I/O
103 0 0 211452 9916 0 0 BGP Scanner
From the above output we can see that the prefixes are still
filtered out, however now we're using *more* memory than the original
unfiltered view. This is because the full table is still sitting in memory,
plus the extra overhead of running the soft-reconfig process. Now let's
compare the three:
1. full view, no filter
2. filtered view, no soft reconfig
3. filtered view, soft reconfig
PID TTY Allocated Freed Holding Getbufs Retbufs Process
1. 101 0 283144 0 276168 0 0 BGP Router
2. 101 0 297856 67836 223044 0 0 BGP Router
3. 101 0 847504 332412 289692 0 0 BGP Router
Make more sense now? The memory savings of running route-refresh
instead of soft-reconfig is that you don't have to keep the full view after
your filter. The largest savings of all of them however is going to be what
Howard recommended, and is Outbound Route Filtering (ORF). This is because
the downstream device does not have to process the routes before they are
thrown away. The upstream device filters them out before they even get
downstream.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 708-362-1418 (Outside the US and Canada)
This archive was generated by hypermail 2.1.4 : Fri Dec 12 2003 - 12:29:19 GMT-3