http://blog.gmane.org/gmane.network.quagga.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.quagga.user/12608 <pre>Hi Harini, Give: --disable-pie flag while cross compiling . Then try... On Thu, May 24, 2012 at 3:23 PM, Harini Gopalakrishnan &lt; Harini.Gopalakrishnan-oonXi/34qI7c+919tysfdA&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Quagga-users mailing list Quagga-users-UOy77sIEA+cAd7ICUelF/Q&lt; at &gt;public.gmane.org http://lists.quagga.net/mailman/listinfo/quagga-users </pre> arvind ratnu 2012-05-24T10:52:41 http://permalink.gmane.org/gmane.network.quagga.user/12606 <pre> micah anderson &lt;micah-sGOZH3hwPm2sTnJN9+BGXg&lt; at &gt;public.gmane.org&gt; writes: Hm, I think peer-groups are intended for BGP peers that have the same outbound policy, so that is probably why things did not work as I expected. </pre> micah anderson 2012-05-21T18:15:44 http://permalink.gmane.org/gmane.network.quagga.user/12605 <pre> I created a peer-group, but found that it wasn't allowing me to add additional prefix-lists to different neighbors, only the prefix-list that was defined for the peer-group was getting applied. In the below example, I found that the prefix-list called 'peera-allowed-out' was not applied to that peer, only the peer-group prefix-list. First I created a peer-group and set a prefix-list to be applied to every member of that peer-group: ! define an 'upstream' peer-group and set it so the prefix-list ! 'allowed-in' is applied to all of them neighbor upstream peer-group neighbor upstream prefix-list allowed-in in ! !Then I defined a neighbor: ! ! BGP peerA neighbor 192.168.0.1 remote-as 16652 ! then I set a specify prefix-list for outbound: neighbor 192.168.0.1 prefix-list peera-allowed-out out neighbor 192.168.0.1 peer-group upstream neighbor 192.168.0.1 description PeerA neighbor 192.168.0.1 update-source 192.168.0.2 ! ! here is that specific prefix-list: ip prefix-list peera-allowed-out permit 10.0.0.0/24 ip prefix-list peera-allowed-out deny any ! ! and then the prefix-list for the peer-group ip prefix-list allowed-in deny 0.0.0.0/0 ! localhost ip prefix-list allowed-in deny 127.0.0.0/8 ip prefix-list allowed-in deny 10.0.0.0/24 ip prefix-list allowed-in permit any Can someone clue me in to what I dont understand about peer-group configuration? thanks, micah </pre> micah anderson 2012-05-21T15:23:27 http://permalink.gmane.org/gmane.network.quagga.user/12604 <pre>Hi, I was checking in VTYSH that the desabiliar any of the daemons, the commands available in the same continues VTYSH. Would have any way to disable it, the compilation, according to the daemons that I'm enabling? Regards, Marco Túlio _______________________________________________ Quagga-users mailing list Quagga-users-UOy77sIEA+cAd7ICUelF/Q&lt; at &gt;public.gmane.org http://lists.quagga.net/mailman/listinfo/quagga-users </pre> Marco Tulio R Braga 2012-05-18T11:52:23 http://permalink.gmane.org/gmane.network.quagga.user/12603 <pre>[...] And in another mail you mentioned that the routes are chosen per flow. Is this per-flow routing symmetric? Consider this scenario: C . . . R / \ / \ F1 F2 \ / \ / S R is router, F1 and F2 are firewalls (routers with packet filters), S is a server. The links between R, F1, F2 and S all have the same cost. A Client C tries to establish a TCP connection to S. The SYN packet arrives at R which chooses to forward the packet to F1 which in turn forwards it S. S then replies with a SYN-ACK packet. How does it determine where the send this packet? 1) By receiving the SYN packet from F1 a flow was established. The SYN-ACK packet belongs to the same flow, so it is sent to F1. 2) This is the first packet to be sent in this connection, so no flow has been established yet. The packet will be sent to either F1 or F2 with equal probability. If F1 and F2 are stateful packet filters, only case 1 would work (unless F1 and F2 have a way to share state). hp PS: Does it matter whether S can reach F1 through the same or different interfaces? </pre> Peter J. Holzer 2012-05-18T09:35:31 http://permalink.gmane.org/gmane.network.quagga.user/12602 <pre>Hi All, We are exercising quagga0.99.20-quagga-ripd.  keychain  configuration commands in the below mentioned scenario leads to quagg-ripd crash. Did anybody observe this ? Please share any patch/fix for this issue. ============== steps to arrive the issue ============ telnet 127.1 2602 &lt;&lt;zebra, login password ripd$enable ripd#conf term .. .. ripd(config-keychain)# do sh run Current configuration: ! hostname ripd password zebra log stdout ! key chain testing key 14  key-string testing  accept-lifetime 09:33:15 May 18 2012 duration 120 ! router rip network eth0 ! line vty ! end ripd(config-keychain)# no ke ripd(config-keychain)# no key 14 ripd(config-keychain)# ke ripd(config-keychain)# key 14 ripd(config-keychain-key)# ac ripd(config-keychain-key)# accept-lifetime 09:33:15 May 18 2012 duration 120 ripd(config-keychain-key)# ke ripd(config-keychain-key)# key-st ripd(config-keychain-key)# key-string st ripd(config-keychain-key)# key-string testing ripd(config-keychain-key)# ripd# conf ter ripd(config)# i interface  ip         ipv6 ripd(config)# in ripd(config)# interface eth0 ripd(config-if)# ip rip au ripd(config-if)# ip rip authentication m ripd(config-if)# ip rip authentication mode m ripd(config-if)# ip rip authentication mode md5 ripd(config-if)# ip ri ripd(config-if)# ip rip au ripd(config-if)# ip rip authentication k ripd(config-if)# ip rip authentication key-chain testing ripd(config-if)# k ripd(config-if)# ip rip sp ripd(config-if)# ip rip split-horizon p ripd(config-if)# ip rip split-horizon poisoned-reverse ripd(config-if)# ip rip ripd(config-if)# ip rip se ripd(config-if)# ip rip send ver ripd(config-if)# ip rip send version 2 ripd(config-if)# ip ri ripd(config-if)# ip rip r ripd(config-if)# ip rip receive ver ripd(config-if)# ip rip receive version 2 ripd(config-if)# exit ripd(config)# ke ripd(config)# key ch ripd(config)# key chain test ripd(config)# do sh ip rip Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP Sub-codes:      (n) - normal, (s) - static, (d) - default, (r) - redistribute,      (i) - interface     Network            Next Hop         Metric From            Tag Time C(i) 192.168.1.0/24     0.0.0.0               1 self              0 ripd(config)# ke ripd(config)# key c ripd(config)# key chain testing ripd(config-keychain)# no ke ripd(config-keychain)# no key 14 ripd(config-keychain)# ke ripd(config-keychain)# key 14 ripd(config-keychain-key)# ac ripd(config-keychain-key)# accept-lifetime 09:33:15 May 18 2012 duration 120Connection closed by foreign host. root&lt; at &gt;linux:~# /* Here the ripd got crashed, hence quagga-ripd  shell is closed */ ============== steps to arrive the issue ============ </pre> Ganesh Reddy K 2012-05-17T06:04:08 http://permalink.gmane.org/gmane.network.quagga.user/12601 <pre> There are circumstances (basically, extremely asymmetric or variable flows, generally coupled with narrow pipes) where that's not true, so it's good to have the option. But yes, most of the time it would cause way more harm than good. /a </pre> Alexis Rosen 2012-05-17T01:17:21 http://permalink.gmane.org/gmane.network.quagga.user/12600 <pre> That's good. Per packet was a bad idea (made out of order packets much more frequent and made link failures affect all flows rather than just some). </pre> Lennart Sorensen 2012-05-16T21:29:06 http://permalink.gmane.org/gmane.network.quagga.user/12599 <pre> Last time I looked, which was admittedly quite a long time ago, Ciscos would only do per-flow, if you were running CEF. Asking a Cisco to do per-packet would cause the packets to be process-switched. So the Linux behavior is the same as the standard Cisco behavior. /a </pre> Alexis Rosen 2012-05-16T20:04:59 http://permalink.gmane.org/gmane.network.quagga.user/12598 <pre> Make sure to turn off rp_filter when using multipath. Otherwise the kernel will drop incoming traffic in many cases. </pre> Lennart Sorensen 2012-05-16T17:32:51 http://permalink.gmane.org/gmane.network.quagga.user/12597 <pre>Thanks Lennart and Thomas for taking the time to reply. </pre> Steve Clark 2012-05-16T17:14:23 http://permalink.gmane.org/gmane.network.quagga.user/12596 <pre>I know that if the interface speeds are the same and you don't have a manually defined cost (IE, Quagga derives the same cost on multiple interface), Quagga will add the route on both interfaces, but with identical weights and metrics. The kernel should do some kind of load balancing (not perfectly) in this scenario (as far as I know, someone feel free to correct me) 192.168.1.0/30 dev eth0 proto kernel scope link src 192.168.1.1 192.168.1.4/30 dev eth1 proto kernel scope link src 192.168.1.5 10.1.17.0/24 proto zebra metric 20 nexthop via 192.168.1.2 dev eth0 weight 1 nexthop via 192.168.1.6 dev eth1 weight 1 10.1.1.0/24 proto zebra metric 20 nexthop via 192.168.1.2 dev eth0 weight 1 nexthop via 192.168.1.6 dev eth1 weight 1 169.254.0.0/16 dev eth0 scope link metric 1002 169.254.0.0/16 dev eth1 scope link metric 1003 In my lab (where I was coincidentally testing this very thing), router 1 has this routing table. Router 2 has 10.1.1.0/24 and 10.1.17.0/24 attached. Both of the links here are gigabit with no manual costing involved. Router 1 isn't distributing any routes. Also, this is RHEL 6.2 with 00.99.15. From: quagga-users-bounces-UOy77sIEA+cAd7ICUelF/Q&lt; at &gt;public.gmane.org [mailto:quagga-users-bounces-UOy77sIEA+cAd7ICUelF/Q&lt; at &gt;public.gmane.org] On Behalf Of Steve Clark Sent: Wednesday, May 16, 2012 12:16 PM To: Quagga Users Lists Subject: [quagga-users 12893] ospf load balancing Hello List. Cisco says that with their OSPF implementation if the route cost are the same they do CEF, Does quagga on Linux 2.6.32 or later do any kind of load balancing if the costs are the same? Thanks for any info. </pre> Thomas York 2012-05-16T16:59:25 http://permalink.gmane.org/gmane.network.quagga.user/12595 <pre> quagga on linux will create multipath routes if you have equal cost routes to the same place. Linux will then pick one route for each flow (where as I believe cisco does per packet multipath routing). It works quite well. </pre> Lennart Sorensen 2012-05-16T16:49:46 http://permalink.gmane.org/gmane.network.quagga.user/12594 <pre>Hello List. Cisco says that with their OSPF implementation if the route cost are the same they do CEF, Does quagga on Linux 2.6.32 or later do any kind of load balancing if the costs are the same? Thanks for any info. </pre> Steve Clark 2012-05-16T16:15:51 http://permalink.gmane.org/gmane.network.quagga.user/12593 <pre>Yeah, I actually didnt realize that NSAP address is something like IP address and needs to be distinct between nodes. I have confirmed that now it doesn't crash. It seemed strange that I was the only one coming up with this error straight from startup. Also, I cloned from the savannah git so thats where its coming from. Thanks so much for the helpful advice! Ill also make sure to update my checkout once the bug fixes become available in mainline. - Hristo On May 15, 2012, at 9:37 PM, Martin Winter wrote: </pre> Hristo Asenov 2012-05-16T02:21:17 http://permalink.gmane.org/gmane.network.quagga.user/12592 <pre>Hristo, I think I found a way to reproduce the issue. We'll look into it. However, can you confirm something for me? It only happens in my lab if I set the same NSAP on both ISIS routers. ie you show router isis Test1 net 51.0000.0000.0116.00 on host_01 and I believe you use the same NSAP on the 2nd isis router. At least in my lab this is the way to reproduce it. Still shouldn't crash ISIS, but don't expect ISIS to work either. If the 2nd host has a different NSAP, ie router isis Test1 net 51.0000.0000.0117.00 then it seems to work. (This is with ISIS from savannah git) - Martin On May 15, 2012, at 7:34 AM, Hristo Asenov wrote: </pre> Martin Winter 2012-05-16T01:37:53 http://permalink.gmane.org/gmane.network.quagga.user/12591 <pre>Martin, We are using the same zebra and isis configs on both sides. Also here is my isisd config: http://pastebin.ca/2149006. The zebra config on the other side just differs by the static ip addresses that are assigned to it. Here is the config for it: http://pasebin.ca/2149012. The other eth2 interfaces currently have no routing protocol running on them. I also built the program with ./configure --enable-vtysh --enable-isisd --enable-multipath=0 - Hristo On May 15, 2012, at 3:18 AM, Martin Winter wrote: _______________________________________________ Quagga-users mailing list Quagga-users-UOy77sIEA+cAd7ICUelF/Q&lt; at &gt;public.gmane.org http://lists.quagga.net/mailman/listinfo/quagga-users </pre> Hristo Asenov 2012-05-15T14:34:05 http://permalink.gmane.org/gmane.network.quagga.user/12590 <pre>Hello! I've this error during compile with --disable-ipv6 gcc -DHAVE_CONFIG_H -DSYSCONFDIR=\"/etc/quagga/\" -DMULTIPATH_NUM=0 -I. -I.. -I.. -I.. -I../lib -fPIE -Os -fno-omit-frame-pointer -g -std=gnu99 -Wall -Wsign-compare -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wchar-subscripts -Wcast-qual -MT zebra_rib.o -MD -MP -MF .deps/zebra_rib.Tpo -c -o zebra_rib.o zebra_rib.c mv -f .deps/zebra_rib.Tpo .deps/zebra_rib.Po gcc -DHAVE_CONFIG_H -DSYSCONFDIR=\"/etc/quagga/\" -DMULTIPATH_NUM=0 -I. -I.. -I.. -I.. -I../lib -fPIE -Os -fno-omit-frame-pointer -g -std=gnu99 -Wall -Wsign-compare -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wchar-subscripts -Wcast-qual -MT interface.o -MD -MP -MF .deps/interface.Tpo -c -o interface.o interface.c In file included from interface.c:37: ../zebra/rtadv.h:33: error: field âprefixâ has incomplete type make[2]: *** [interface.o] Error 1 make[2]: Leaving directory `/usr/local/src/quagga-0.99.21/zebra' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/quagga-0.99.21' make: *** [all] Error 2 All other version are compiled correctly Thanks --- Sim </pre> Sim 2012-05-15T13:26:58 http://permalink.gmane.org/gmane.network.quagga.user/12589 <pre>Hristo, On May 14, 2012, at 8:00 PM, Hristo Asenov wrote: Feel free to try, but keep in mind that things may be even more broken (or fixed). Code is public on Github as mentioned before. However if you can wait a few days, then you may be better off - I'm in the process to test the fixes (and then move on to the next bugs - many more to work on). I've looked at the pastbin's but I can't see the ISIS config. Only the Interface config (zebra config) and only one side. Are you using the same Quagga on both sides? If yes, can you give me the full Quagga config? Or let me know what's on the other side (with the config). Does the crash happen immediately when the neighbors are built or some time later (triggered by some change?) - Martin </pre> Martin Winter 2012-05-15T07:18:36 http://permalink.gmane.org/gmane.network.quagga.user/12588 <pre>Hi. I'm using quagga to handle ipv6 routes in my network. I have the following setup: router A &lt;---ethernet---&gt; router B &lt;----WAN gre tunnels----&gt; multiple ospf routers The problem is that quagga on router A reriodically loses (I'd say 'deletes', because in debug mode it's clear that router A quagga does that) routes received by the router B from multiple other routers and announced to the A. The following output will show it more clearly: Router B table: wizard.hq.norma.perm.ru# sh ipv6 route ospf Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. O&gt;* 2001:470:1f08:14c0::1/128 [110/1] via fe80::21a:64ff:fec6:a87c, vlan1, 00:21:45 O 2001:470:1f09:14c0::/120 [110/1] via fe80::202:b3ff:fee9:8d0e, vlan1, 07w2d06h O&gt;* 2a00:5cc0:c::/64 [110/2] via fe80::21a:64ff:fe21:9489, gre6, 03:13:14 O&gt;* fd00::/120 [110/2] via fe80::21a:64ff:fe21:910e, gre1, 01w0d03h O fd00::300/120 [110/1] is directly connected, vlan1, 09w5d02h O&gt;* fd00::700/120 [110/1] via fe80::202:b3ff:fee9:8d0e, vlan1, 09w4d18h O&gt;* fd00::d00/120 [110/2] via fe80::21a:64ff:fe21:9489, gre6, 03:10:25 O&gt;* fd00::b400/120 [110/2] via fe80::21a:64ff:fe21:962d, gre2, 2d03h56m Router A table after ospf6d is launched: taiga# sh ipv6 route ospf Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. O 2001:470:1f09:14c0::/120 [110/1] via fe80::202:b3ff:fee9:8d0e, vlan1, 00:00:29 O&gt;* 2a00:5cc0:c::/64 [110/2] via fe80::21a:64ff:fe21:8e80, vlan1, 00:00:29 O&gt;* fd00::/120 [110/3] via fe80::21a:64ff:fe21:8e80, vlan1, 00:00:29 O fd00::300/120 [110/1] is directly connected, vlan1, 00:00:30 O fd00::700/120 [110/1] via fe80::202:b3ff:fee9:8d0e, vlan1, 00:00:29 O&gt;* fd00::d00/120 [110/4] via fe80::21a:64ff:fe21:8e80, vlan1, 00:00:29 O&gt;* fd00::b400/120 [110/2] via fe80::21a:64ff:fe21:8e80, vlan1, 00:00:29 O fe80::/64 [110/1] via fe80::21a:64ff:fe21:8e80, vlan1, 00:00:29 Router A table after some time: taiga# sh ipv6 route ospf Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. O 2001:470:1f09:14c0::/120 [110/1] via fe80::202:b3ff:fee9:8d0e, vlan1, 00:23:20 O&gt;* fd00::/120 [110/3] via fe80::21a:64ff:fe21:8e80, vlan1, 00:23:20 O fd00::300/120 [110/1] is directly connected, vlan1, 00:23:21 O fd00::700/120 [110/1] via fe80::202:b3ff:fee9:8d0e, vlan1, 00:23:20 O&gt;* fd00::d00/120 [110/4] via fe80::21a:64ff:fe21:8e80, vlan1, 00:23:20 Notice the fd00::b400/120 route is gone. However, it's still present in the router B table. This isn't specific to quagga version. I observed this on like 5 last versions. How can this be solved ? Is this some error in my ospf setup ? By the way, can I use the same OSPF area numbers in OSPF6 as in OSPF4 (I use the same) ? Thanks. Eugene. </pre> Eugene M. Zheganin 2012-05-15T04:32:15 http://permalink.gmane.org/gmane.network.quagga.user/12587 <pre>Martin, can I try to run the separate branch you guys made for a few ISIS fixes? Maybe it somehow may change the behavior of crash I am getting. To be more precise, the configuration we are running is on a LAN with Ubuntu VM images, however we have only two addresses per subnet, so we are using the links as if they were point-to-point but are using Ethernet protocol. It is something like host_01 (eth1: 10.100.2.1) &lt;-------------&gt; (eth1: 10.100.2.2) host_02 where eth1 on both interfaces is under the subnet 10.100.2.0/30 and they are connected to out-of-band network so we can control them remotely. I ran the code with EXTREME_DEBUG enabled and debugging of adjacency packets enabled one more time. Here is the output I got: http://pastebin.ca/2148465. Also the stack trace from gdb: http://pastebin.ca/2148471. These are the configs we use for zebra: http://pastebin.ca/2148473. Let me know if there is more information I could provide. Thanks, - Hristo On May 14, 2012, at 9:17 PM, Martin Winter wrote: _______________________________________________ Quagga-users mailing list Quagga-users-UOy77sIEA+cAd7ICUelF/Q&lt; at &gt;public.gmane.org http://lists.quagga.net/mailman/listinfo/quagga-users </pre> Hristo Asenov 2012-05-15T03:00:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.quagga.user