headers
raja naresh | 2 Apr 2012 19:07
Picon

[quagga-dev 9159] BGP lookup

Hello everyone,

I've been searching and reading bits and pieces of code relevant to bgp nexthop lookup. What I really am trying to do is spot the sections of code responsible for the lookup and forwarding of a packet to it's next hop at any given router.

I have spotted most of the functions that are responsible for these and have read them but I have no idea as to where in the code base are these functions called when a packet arrives and a nexthop lookup has to be done.

So far I have understood in a partial nitty gritty way that there is obviously some kind of prefix tree implementation (which one?) for the routing tables. I couldn't fully grasp the bgp_nexthop_cache struct especially the purpose of it's members such as u_char nexthop_num and struct nexthop *nexthop although i could follow the it's associated functions, unless i know why is there a linked list of *nexthop i wouldn't understand the purpose of the functions.

I have certainly done more research than the above and I understand there is a lot more to do but it would be great if anyone could give me a direction as to where to start to understand and ask questions as i go through code. I have started in a very unstructured way and I am definitely not able to see the flow of nexthop lookup and forwarding as of now. Thank you

Regards
Raja Naresh

<div><p>Hello everyone, <br><br>I've been searching and reading bits and pieces of code relevant to bgp nexthop lookup. What I really am trying to do is spot the sections of code responsible for the lookup and forwarding of a packet to it's next hop at any given router. <br><br>I have spotted most of the functions that are responsible for these and have read them but I have no idea as to where in the code base are these functions called when a packet arrives and a nexthop lookup has to be done. <br><br>So far I have understood in a partial nitty gritty way that there is obviously some kind of prefix tree implementation (which one?) for the routing tables. I couldn't fully grasp the <span>bgp_nexthop_cache</span> struct especially the purpose of it's members such as <span>u_char nexthop_num</span> and <span>struct nexthop *nexthop</span> although i could follow the it's associated functions, unless i know why is there a linked list of <span>*nexthop</span> i wouldn't understand the purpose of the functions. <br><br>I have certainly done more research than the above and I understand there is a lot more to do but it would be great if anyone could give me a direction as to where to start to understand and ask questions as i go through code. I have started in a very unstructured way and I am definitely not able to see the flow of nexthop lookup and forwarding as of now. Thank you <br><br>Regards<br>Raja Naresh<br></p></div>
Permalink | Reply | 0 comments |
headers
G.Balaji | 2 Apr 2012 20:01
Picon

[quagga-dev 9160] [PATCH 1/2] zebra: Connected route addition to the MRIB

From: "G.Balaji" <balajig81 <at> gmail.com>

Connected routes should be installed in the MRIB so that the nexthop lookup
does not fail

Signed-off-by: G.Balaji <balajig81 <at> gmail.com>
---
 zebra/connected.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/zebra/connected.c b/zebra/connected.c
index f699b14..427e2f7 100644
--- a/zebra/connected.c
+++ b/zebra/connected.c
 <at>  <at>  -191,6 +191,9  <at>  <at>  connected_up_ipv4 (struct interface *ifp, struct connected *ifc)
   rib_add_ipv4 (ZEBRA_ROUTE_CONNECT, 0, &p, NULL, NULL, ifp->ifindex,
 	RT_TABLE_MAIN, ifp->metric, 0, SAFI_UNICAST);

+  rib_add_ipv4 (ZEBRA_ROUTE_CONNECT, 0, &p, NULL, NULL, ifp->ifindex,
+	RT_TABLE_MAIN, ifp->metric, 0, SAFI_MULTICAST);
+
   rib_update ();
 }

--

-- 
1.7.5.4
Permalink | Reply | 2 comments |
headers
G.Balaji | 2 Apr 2012 20:01
Picon

[quagga-dev 9161] [PATCH 2/2] zebra: Connected route deletion from MRIB

From: "G.Balaji" <balajig81 <at> gmail.com>

Signed-off-by: G.Balaji <balajig81 <at> gmail.com>
---
 zebra/connected.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/zebra/connected.c b/zebra/connected.c
index 427e2f7..05538c5 100644
--- a/zebra/connected.c
+++ b/zebra/connected.c
 <at>  <at>  -300,6 +300,8  <at>  <at>  connected_down_ipv4 (struct interface *ifp, struct connected *ifc)
   /* Same logic as for connected_up_ipv4(): push the changes into the head. */
   rib_delete_ipv4 (ZEBRA_ROUTE_CONNECT, 0, &p, NULL, ifp->ifindex, 0, SAFI_UNICAST);

+  rib_delete_ipv4 (ZEBRA_ROUTE_CONNECT, 0, &p, NULL, ifp->ifindex, 0, SAFI_MULTICAST);
+
   rib_update ();
 }

--

-- 
1.7.5.4
Permalink | Reply | 1 comment |
headers
David Lamparter | 1 Apr 2012 07:55
Gravatar

[quagga-dev 9162] Re: [PATCH 1/2] lib: fix endianness bug in prefix.c

On Mon, Mar 26, 2012 at 06:18:47PM +0400, Denis Ovsienko wrote:
> 26.03.2012, 17:22, "Renato Westphal" <renatowestphal <at> gmail.com>:
> > 2012/3/24 David Lamparter <equinox <at> diac24.net>:
> >
> >>  The previous code didn't account for broken masks, so we don't need to
> >>  either.
> >
> > Yes, the previous code didn't account for broken masks, but I think it
> > should. If someone tries to create a route using "ip route 10.0.30.0
> > 255.255.233.0 eth0" I think zebra should warn the user with something
> > like "% Inconsistent address and mask" instead of creating an
> > erroneous route...
> 
> Yes, exactly. I am glad to see the thread got beyond ffs().
> Non-contiguous netmasks are the real problem, I've been studying it
> for some time. The solution is on its way.

Yes, non-continguous netmask are invalid input. That kind of invalid
input, however, needs handling by the routing daemons in question.

Changing the helper functions and adding a "broken mask" return value
may be _part_ of a solution. Then, all callers need to be adapted to
this and then take appropriate action (drop peer/neighbor, ignore route,
whatever appropriate for the occasion...).
The cleanest way to do it is probably to add a separate
"ip_masklen_verify" function and then incrementally update callers. Or,
even simpler, check "masklen2ip(ip_masklen) == mask"?

The addition of an "invalid" return value to ip_masklen on its own is a
big danger for bugs (or even security issues). The existing code does
not expect this and may behave undefinedly.

-David

On Mon, Mar 26, 2012 at 06:18:47PM +0400, Denis Ovsienko wrote:
> 26.03.2012, 17:22, "Renato Westphal" <renatowestphal <at> gmail.com>:
> > 2012/3/24 David Lamparter <equinox <at> diac24.net>:
> >
> >>  The previous code didn't account for broken masks, so we don't need to
> >>  either.
> >
> > Yes, the previous code didn't account for broken masks, but I think it
> > should. If someone tries to create a route using "ip route 10.0.30.0
> > 255.255.233.0 eth0" I think zebra should warn the user with something
> > like "% Inconsistent address and mask" instead of creating an
> > erroneous route...
> 
> Yes, exactly. I am glad to see the thread got beyond ffs().
> Non-contiguous netmasks are the real problem, I've been studying it
> for some time. The solution is on its way.

Yes, non-continguous netmask are invalid input. That kind of invalid
input, however, needs handling by the routing daemons in question.

Changing the helper functions and adding a "broken mask" return value
may be _part_ of a solution. Then, all callers need to be adapted to
this and then take appropriate action (drop peer/neighbor, ignore route,
whatever appropriate for the occasion...).
The cleanest way to do it is probably to add a separate
"ip_masklen_verify" function and then incrementally update callers. Or,
even simpler, check "masklen2ip(ip_masklen) == mask"?

The addition of an "invalid" return value to ip_masklen on its own is a
big danger for bugs (or even security issues). The existing code does
not expect this and may behave undefinedly.

-David
Permalink | Reply | 2 comments |
headers
Denis Ovsienko | 4 Apr 2012 15:34
Picon
Favicon
Gravatar

[quagga-dev 9163] Re: [PATCH 1/2] lib: fix endianness bug in prefix.c


>>  Yes, exactly. I am glad to see the thread got beyond ffs().
>>  Non-contiguous netmasks are the real problem, I've been studying it
>>  for some time. The solution is on its way.
>
> Yes, non-continguous netmask are invalid input. That kind of invalid
> input, however, needs handling by the routing daemons in question.

This is true.

>
> Changing the helper functions and adding a "broken mask" return value
> may be _part_ of a solution. Then, all callers need to be adapted to
> this and then take appropriate action (drop peer/neighbor, ignore route,
> whatever appropriate for the occasion...).
> The cleanest way to do it is probably to add a separate
> "ip_masklen_verify" function and then incrementally update callers. Or,
> even simpler, check "masklen2ip(ip_masklen) == mask"?

This is also true.

>
> The addition of an "invalid" return value to ip_masklen on its own is a
> big danger for bugs (or even security issues). The existing code does
> not expect this and may behave undefinedly.

And this is true.

It took several weeks to map the problem appropriately. By now the solution is, to my imperfect knowledge,
complete, but I would be interested in seeing any evidence of the opposite.

It has been smoketested and committed to RE-testing-0.99 branch.

--

-- 
    Denis Ovsienko
_______________________________________________
Quagga-dev mailing list
Quagga-dev <at> lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
Permalink | Reply | 1 comment |
headers
David Lamparter | 4 Apr 2012 20:52
Gravatar

[quagga-dev 9164] Re: [PATCH 1/2] lib: fix endianness bug in prefix.c

On Wed, Apr 04, 2012 at 05:34:47PM +0400, Denis Ovsienko wrote:
> > The addition of an "invalid" return value to ip_masklen on its own is a
> > big danger for bugs (or even security issues). The existing code does
> > not expect this and may behave undefinedly.
> 
> And this is true.
> 
> It took several weeks to map the problem appropriately. By now the
> solution is, to my imperfect knowledge, complete, but I would be
> interested in seeing any evidence of the opposite.
> 
> It has been smoketested and committed to RE-testing-0.99 branch.

I've scrolled over it and it seems to be the right thing to do. I'll
do some proper review and figure out how I can merge it.

-David

On Wed, Apr 04, 2012 at 05:34:47PM +0400, Denis Ovsienko wrote:
> > The addition of an "invalid" return value to ip_masklen on its own is a
> > big danger for bugs (or even security issues). The existing code does
> > not expect this and may behave undefinedly.
> 
> And this is true.
> 
> It took several weeks to map the problem appropriately. By now the
> solution is, to my imperfect knowledge, complete, but I would be
> interested in seeing any evidence of the opposite.
> 
> It has been smoketested and committed to RE-testing-0.99 branch.

I've scrolled over it and it seems to be the right thing to do. I'll
do some proper review and figure out how I can merge it.

-David
Permalink | Reply | 0 comments |
headers
Joakim Tjernlund | 7 Apr 2012 14:58
Picon

[quagga-dev 9165] zebra: fix ifindex test condition (BZ#487)


http://git.savannah.gnu.org/cgit/quagga.git/commit/?id=4f1735fd6ac5d0881bafa9bd421e00645b6c60fd

Was browsing Quagga repo to see the latest fixes and found the above commit.
Sadly that commit does not fix much, it only deals with ifindex for connected routes.
Either have a look at my patch I sent long ago(Don't delete too many routes) or
slap a
if (ifindex && ifindex != nexthop->ifindex)
		continue; /* ifindex doesn't match */
before testing anything else

Havn't been following Q lately but other that moving the Q repo to savannah I don't
see much maintaince going on, at least not picking off the vast number of
patches in patchwork.

 Jocke
Permalink | Reply | 1 comment |
headers
Milen Bogunski | 9 Apr 2012 13:52
Picon
Favicon

[quagga-dev 9166] quagga/bgpd: memory leak? any ideas?

In last two weeks i have strange memory problems with quagga/bgpd on some of our routers

After about a day bgpd eats all of router memory (2G, 3G) on different routers with different quagga
versions. (0.99.15,0.99.18 and 0.99.20)

All of the routers are connected to TWO Internet borders with FULL bgp ~400k routes 

all are 32bit architecture
CPU Quad Core Q9550 
             total       used       free     shared    buffers     cached
Mem:          1954       1574        380          0         18         19
-/+ buffers/cache:       1536        418
Swap:         1953          3       1949

quagga    8185  0.0  3.9  82952 79004 ?        Ss   Apr08   1:29 /usr/sbin/zebra -d -f /etc/quagga/zebra.conf -l 255
--pid_file /var/run/quagga/zebra.pid
quagga    8200  4.3 66.3 1332408 1328320 ?     Rs   Apr08  68:52 /usr/sbin/bgpd -d -f /etc/quagga/bgpd.conf
--pid_file /var/run/quagga/bgpd.pid

After i reset bgpd process it frees all the memory and work fine for 1 or 2 days.

i tried community delete,extra attributes and couple of memory leak patches with no effect.

What that temporary memory mean and why it is so high ?

They all worked for about an year with no problems, but in last week i reset them every couple of days
updated some of routers to last quagga version but with no effect..

Any ideas how to fix this strange memory issue ?

15hours since bgpd reset:
Hello, this is Quagga (version 0.99.18).

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  799 MiB
  Holding block headers: 132 KiB
  Used small blocks:     0 bytes
  Used ordinary blocks:  766 MiB
  Free small blocks:     16 bytes
  Free ordinary blocks:  33 MiB
  Ordinary blocks:       838464
  Small blocks:          1
  Holding blocks:        1
(see system documentation for 'mallinfo' for meaning)
-----------------------------
Temporary memory              :   26572077
String vector                 :       9444
Vector                        :       4924
Vector index                  :       4924
Link List                     :         46
Link Node                     :         77
Thread                        :        236
Thread master                 :          1
Thread stats                  :         17
Thread function name          :        137
VTY                           :          3
Interface                     :         38
Connected                     :         18
Buffer                        :          3
Buffer data                   :          1
Stream                        :         41
Stream data                   :         41
Stream FIFO                   :         18
Prefix                        :         34
Hash                          :        151
Hash Bucket                   :     389931
Hash Index                    :        151
Access List                   :          6
Access List Str               :          6
Access Filter                 :         38
Prefix List                   :          1
Prefix List Entry             :          4
Prefix List Str               :          1
Route map                     :         23
Route map name                :         23
Route map index               :         25
Route map rule                :         41
Route map rule str            :         41
Route map compiled            :         44
Command desc                  :       4732
Socket union                  :         32
Logging                       :          1
Zclient                       :          2
Work queue                    :          2
Work queue name string        :          2
Host config                   :          5
-----------------------------
Nexthop                       :          8
-----------------------------
BGP instance                  :          1
BGP listen socket details     :          1
BGP peer                      :         18
BGP peer hostname             :         18
Peer description              :         17
BGP attribute                 :     268345
BGP extra attributes          :      32039
BGP aspath                    :     121493
BGP aspath seg                :     121621
BGP aspath segment data       :     121621
BGP aspath str                :     121493
-----------------------------
BGP table                     :         28
BGP node                      :     737784
BGP route                     :     815231
BGP ancillary route info      :     815127
BGP connected                 :         17
BGP static                    :         25
BGP synchronise               :        144
BGP adj in                    :     815226
BGP adj out                   :        723
-----------------------------
community                     :         73
community val                 :         73
community str                 :         67
-----------------------------
extcommunity                  :         16
extcommunity val              :         16
extcommunity str              :         16
-----------------------------
community-list                :          6
community-list name           :          6
community-list entry          :          9
community-list config         :          3
community-list handler        :          1
-----------------------------
BGP nexthop                   :          8
BGP peer update interface     :         16
BGP regexp                    :          3

Hello, this is Quagga (version 0.99.15).
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  804 MiB
  Holding block headers: 132 KiB
  Used small blocks:     0 bytes
  Used ordinary blocks:  770 MiB
  Free small blocks:     16 bytes
  Free ordinary blocks:  34 MiB
  Ordinary blocks:       735123
  Small blocks:          1
  Holding blocks:        1
(see system documentation for 'mallinfo' for meaning)
-----------------------------
Temporary memory              :   26703688
String vector                 :       9434
Vector                        :       4919
Vector index                  :       4919
Link List                     :         94
Link Node                     :        161
Thread                        :         72
Thread master                 :          1
Thread stats                  :         16
Thread function name          :         80
VTY                           :          3
Interface                     :         85
Connected                     :         50
Buffer                        :          3
Buffer data                   :          1
Stream                        :         49
Stream data                   :         49
Stream FIFO                   :         22
Prefix                        :         79
Hash                          :        183
Hash Bucket                   :     390782
Hash Index                    :        183
Access List                   :          5
Access List Str               :          5
Access Filter                 :         15
Prefix List                   :          2
Prefix List Entry             :          6
Prefix List Str               :          2
Route map                     :         22
Route map name                :         22
Route map index               :         29
Route map rule                :         55
Route map rule str            :         55
Route map compiled            :         66
Command desc                  :       4728
Socket union                  :         32
Logging                       :          1
Zclient                       :          2
Work queue                    :          3
Work queue name string        :          3
Host config                   :          4
-----------------------------
Nexthop                       :         11
-----------------------------
BGP instance                  :          1
BGP listen socket details     :          1
BGP peer                      :         22
BGP peer hostname             :         22
Peer description              :         21
BGP attribute                 :     269157
BGP extra attributes          :      32197
BGP aspath                    :     121495
BGP aspath seg                :     121623
BGP aspath segment data       :     121623
BGP aspath str                :     121495
-----------------------------
BGP table                     :         28
BGP node                      :     739280
BGP route                     :     815224
BGP ancillary route info      :     815078
BGP static                    :         91
BGP adv attr                  :         34
BGP adv                       :        216
BGP synchronise               :        176
BGP adj in                    :      21938
BGP adj out                   :     798863
-----------------------------
community                     :         79
community val                 :         79
community str                 :         72
-----------------------------
extcommunity                  :         16
extcommunity val              :         16
extcommunity str              :         16
-----------------------------
community-list                :          8
community-list name           :          8
community-list entry          :          8
community-list handler        :          1
-----------------------------
BGP nexthop                   :         11
BGP peer update interface     :         13

3hours since reset and rising
Hello, this is Quagga (version 0.99.20).
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  316 MiB
  Holding block headers: 132 KiB
  Used small blocks:     0 bytes
  Used ordinary blocks:  283 MiB
  Free small blocks:     16 bytes
  Free ordinary blocks:  34 MiB
  Ordinary blocks:       169512
  Small blocks:          1
  Holding blocks:        1
(see system documentation for 'mallinfo' for meaning)
-----------------------------
Temporary memory              :    6383569
...
after ~5 minutes while i'm writing this mail
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  322 MiB
  Holding block headers: 132 KiB
  Used small blocks:     0 bytes
  Used ordinary blocks:  289 MiB
  Free small blocks:     16 bytes
  Free ordinary blocks:  33 MiB
  Ordinary blocks:       176424
  Small blocks:          1
  Holding blocks:        1
(see system documentation for 'mallinfo' for meaning)
-----------------------------
Temporary memory              :    6647621
Permalink | Reply | 8 comments |
headers
Jorge Boncompte [DTI2] | 9 Apr 2012 14:19

[quagga-dev 9167] Re: quagga/bgpd: memory leak? any ideas?

El 09/04/2012 13:52, Milen Bogunski escribió:
> In last two weeks i have strange memory problems with quagga/bgpd on some of
> our routers
> 
> After about a day bgpd eats all of router memory (2G, 3G) on different
> routers with different quagga versions. (0.99.15,0.99.18 and 0.99.20)

	Can you post your configuration for bgpd?
Permalink | Reply | 2 comments |
headers
Milen Bogunski | 9 Apr 2012 14:43
Picon
Favicon

[quagga-dev 9168] Re: quagga/bgpd: memory leak? any ideas?

GW3-Pop# sh runn
Building configuration...

Current configuration:
!
log file /var/log/zebra.log
log file /var/log/bgpd.log
log syslog
!
password zgwqwe
enable password zgwqwe
!
interface eth0
!
interface eth1
!
interface lo
!
interface vlan4
!
interface vlan58
!
interface vlan59
!
interface vlan60
!
interface vlan61
!
interface vlan78
!
interface vlan133
!
interface vlan405
!
router bgp ASNXXX
 bgp router-id xx.xx.xx.11
 bgp log-neighbor-changes
 bgp always-compare-med
 network yy.yy.yy.216/30 route-map my_ptp_space
 network yy.yy.yy.220/30 route-map my_ptp_space
 network yy.yy.yy.224/30 route-map my_ptp_space
 network yy.yy.yy.228/30 route-map my_ptp_space
 network xx.xx.xx.166/32 route-map my_ptp_space
 network xx.xx.xx.201/32 route-map my_ptp_space
 neighbor yy.yy.yy.217 remote-as ASNXXX
 neighbor yy.yy.yy.217 description Internet1
 neighbor yy.yy.yy.217 update-source yy.yy.yy.218
 neighbor yy.yy.yy.217 next-hop-self
 neighbor yy.yy.yy.217 prefix-list ignore_default in
 neighbor yy.yy.yy.217 prefix-list les24 out
 neighbor yy.yy.yy.217 route-map int_rilon_in in
 neighbor yy.yy.yy.221 remote-as ASNXXX
 neighbor yy.yy.yy.221 description Peering1
 neighbor yy.yy.yy.221 update-source yy.yy.yy.222
 neighbor yy.yy.yy.221 next-hop-self
 neighbor yy.yy.yy.221 soft-reconfiguration inbound
 neighbor yy.yy.yy.221 prefix-list les24 out
 neighbor yy.yy.yy.221 route-map peer_rilon_in in
 neighbor yy.yy.yy.225 remote-as ASNXXX
 neighbor yy.yy.yy.225 description Internet2
 neighbor yy.yy.yy.225 update-source yy.yy.yy.226
 neighbor yy.yy.yy.225 next-hop-self
 neighbor yy.yy.yy.225 soft-reconfiguration inbound
 neighbor yy.yy.yy.225 prefix-list ignore_default in
 neighbor yy.yy.yy.225 prefix-list les24 out
 neighbor yy.yy.yy.225 route-map int_office_in in
 neighbor yy.yy.yy.229 remote-as ASNXXX
 neighbor yy.yy.yy.229 description Peering2
 neighbor yy.yy.yy.229 update-source yy.yy.yy.230
 neighbor yy.yy.yy.229 next-hop-self
 neighbor yy.yy.yy.229 soft-reconfiguration inbound
 neighbor yy.yy.yy.229 prefix-list les24 out
 neighbor yy.yy.yy.229 route-map peer_office_in in
 neighbor xx.xx.xx.4 remote-as ASNXXX
 neighbor xx.xx.xx.4 description PPeer
 neighbor xx.xx.xx.4 update-source vlan4
 neighbor xx.xx.xx.4 soft-reconfiguration inbound
 neighbor xx.xx.xx.4 prefix-list les24 out
 neighbor xx.xx.xx.4 route-map ppeer_rilon_in in
 neighbor xx.xx.xx.5 remote-as ASNXXX
 neighbor xx.xx.xx.5 description GW-Rilon
 neighbor xx.xx.xx.5 update-source vlan4
 neighbor xx.xx.xx.5 next-hop-self
 neighbor xx.xx.xx.5 soft-reconfiguration inbound
 neighbor xx.xx.xx.10 remote-as ASNXXX
 neighbor xx.xx.xx.10 description GW2-Office
 neighbor xx.xx.xx.10 update-source vlan4
 neighbor xx.xx.xx.10 next-hop-self
 neighbor xx.xx.xx.10 soft-reconfiguration inbound
!
ip prefix-list ignore_default seq 10 deny 0.0.0.0/0
ip prefix-list ignore_default seq 20 permit any
ip prefix-list les24 seq 1 deny 192.168.0.0/16 le 32
ip prefix-list les24 seq 2 deny 10.0.0.0/8 le 32
ip prefix-list les24 seq 3 deny 172.16.0.0/12 le 32
ip prefix-list les24 seq 4 permit 0.0.0.0/0 le 24
!
!
route-map ppeer_rilon_in permit 10
 set ip next-hop peer-address
 set local-preference 140
!
route-map int_office_in permit 10
 set ip next-hop peer-address
!
route-map int_rilon_in permit 10
 set ip next-hop peer-address
!
route-map my_ptp_space permit 10
 set community ASNXXX:9 ASNXXX:93
 set local-preference 200
!
route-map peer_office_in permit 10
 set ip next-hop peer-address
!
route-map peer_rilon_in permit 10
 set ip next-hop peer-address
!
ip forwarding
!
line vty
 access-class 1
 exec-timeout 0 0
!
end

GW3-Pop ~ # vtysh 

Hello, this is Quagga (version 0.99.20).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

GW3-Pop# sh ip bgp summ
BGP router identifier xx.xx.xx.11, local AS number ASNXXX
RIB entries 737710, using 39 MiB of memory
Peers 7, using 17 KiB of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
yy.yy.yy.217    4 ASNXXX 2888125     250        0    0    0 04:06:46   398713
yy.yy.yy.221    4 ASNXXX    7698    1217        0    0    0 20:13:50    13777
yy.yy.yy.225    4 ASNXXX  140855    1217        0    0    0 20:13:47   394751
yy.yy.yy.229    4 ASNXXX    2532    1217        0    0    0 20:13:51     5642
xx.xx.xx.4      4 ASNXXX    1697    1217        0    0    0 20:13:48     2275
xx.xx.xx.5      4 ASNXXX    1220    1217        0    0    0 20:13:53       14
xx.xx.xx.10     4 ASNXXX    1233    1220        0    0    0 16:01:31      144

Total number of neighbors 7

still increasing memory usage...

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  354 MiB
  Holding block headers: 132 KiB
  Used small blocks:     0 bytes
  Used ordinary blocks:  321 MiB
  Free small blocks:     16 bytes
  Free ordinary blocks:  33 MiB
  Ordinary blocks:       217437
  Small blocks:          1
  Holding blocks:        1
(see system documentation for 'mallinfo' for meaning)
-----------------------------
Temporary memory              :    8010188

----- Original Message -----
From: Jorge Boncompte [DTI2]
[mailto:jorge <at> dti2.net]
To: Quagga development list
[mailto:quagga-dev <at> lists.quagga.net]
Sent: Mon, 09 Apr 2012 15:19:01
+0300
Subject: [quagga-dev 9167] Re: quagga/bgpd: memory leak? any ideas?

> El 09/04/2012 13:52, Milen Bogunski escribió:
> > In last two weeks i have strange memory problems with quagga/bgpd on some
> of
> > our routers
> > 
> > After about a day bgpd eats all of router memory (2G, 3G) on different
> > routers with different quagga versions. (0.99.15,0.99.18 and 0.99.20)
> 
> 	Can you post your configuration for bgpd?
> 
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev <at> lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev
> 

_______________________________________________
Quagga-dev mailing list
Quagga-dev <at> lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
Permalink | Reply | 1 comment |

Gmane