From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Sun Nov 30 2003 - 21:42:14 GMT-3
Jim,
I haven't used the other traffic generation features of nantech, but
it's an excellent way to inject BGP routes into your lab. Additionally you
can cause routes to flap to test route dampening.
See www dot nantech dot com for more info.
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)
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Jim Devane
> Sent: Sunday, November 30, 2003 6:34 PM
> To: 'Brian McGahan'; ccielab@groupstudy.com
> Subject: RE: Why Disabling BPG soft-reconfig did not reclaim Memory?
>
> Brian,
>
> Excellent example. I really appreciate you taking the time and energy to
> clearly lay this out for us. I understand it now, which makes me a better
> part of the Internet community.
>
> Thank you again.
> Jim
>
> As an aside, what are your thoughts one way or the other about the
> Nantech?
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Brian McGahan
> Sent: Sunday, November 30, 2003 4:12 PM
> To: ccielab@groupstudy.com
> Subject: RE: Why Disabling BPG soft-reconfig did not reclaim Memory?
>
> 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)
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 12 2003 - 12:29:19 GMT-3