1 Jan 2007 19:59
1 Jan 2007 22:21
[quagga-users 7892] Re: error in starting bgpd
On Monday 01 January 2007 20:59, Yi Wang wrote: > Hello, > > I'm new to Quagga. When I tried to run bgpd as root, I saw the following > error: > > BGP: Can't create pid lock file /var/run/bgpd.pid (Permission denied), > exiting > > Could anybody tell me the reason for this error? bgpd doesn't start as root: it run as user specified with -u command line option. Default is quagga. > > Thanks. > > Yi > _______________________________________________ > Quagga-users mailing list > Quagga-users@... > http://lists.quagga.net/mailman/listinfo/quagga-users
2 Jan 2007 08:25
[quagga-users 7893] limitation on the prefix length for OSPF network statement
In the quagga documentation, for the 'network' command, it says:
===============================================
| router ospf network 192.168.1.0/24 area 0.0.0.0 |
Prefix length in interface must be equal or bigger (ie. smaller network) than prefix length in network statement. For example statement above doesn't enable ospf on interface with address 192.168.1.1/23, but it does on interface with address 192.168.1.129/25.
===============================================
What's the reason for having such restriction on the prefix length? Why does the prefix length in the interface have to restrict the prefix length in the network statement? On Cisco routers, this doesn't seem to be the case.
Peter K.
_______________________________________________ Quagga-users mailing list Quagga-users@... http://lists.quagga.net/mailman/listinfo/quagga-users
4 Jan 2007 04:03
[quagga-users 7894] "no neighbor peer next-hop-self" doesn't work?
Hello, I configured a Quagga instance and a XORP instance on the same host to speak BGP to each other. The major part of my Quagga BGP configure file is as follows: "router bgp 64998 bgp router-id 66.66.66.66 no bgp enforce-first-as neighbor 127.0.0.1 remote-as 999 neighbor 192.168.2.2 remote-as 64999 no neighbor 192.168.2.2 next-hop-self no neighbor 127.0.0.1 next-hop-self" The Quagga instance uses address 127.0.0.1, and the XORP instance uses address 192.168.2.2. I used another prorgam to send BGP updates to the Quagga bgpd instance, which in turn send the updates to the XORP instance. But even if I specified in the bgpd configure file that it should not change the next-hop to its local address (127.0.0.1), it seemed to have no effect -- all the updates the XORP instances received have next-hop 127.0.0.1. Any ideas? Thanks, Yi
4 Jan 2007 09:13
[quagga-users 7895] Re: "no neighbor peer next-hop-self" doesn't work?
Hi Yi, On Wed, 3 Jan 2007, Yi Wang wrote: > "router bgp 64998 > bgp router-id 66.66.66.66 > no bgp enforce-first-as > neighbor 127.0.0.1 remote-as 999 > neighbor 192.168.2.2 remote-as 64999 > no neighbor 192.168.2.2 next-hop-self > no neighbor 127.0.0.1 next-hop-self" Setting nexthop to self is fundamental to eBGP. You can not 'unset' nexthop-self for eBGP, rather you can only cause nexthop-self to be applied where it otherwise would not, with this command (i.e. on iBGP sessions). What you want instead is: neighbor .... attribute-unchanged next-hop regards, -- -- Paul Jakma paul@... paul@... Key ID: 64A2FF6A Fortune: We come to bury DOS, not to praise it. (Paul Vojta, vojta@..., paraphrasing a quote of Shakespeare)
4 Jan 2007 14:48
[quagga-users 7896] ospf and a full ip_contrack table
Hi all,
We are having a little trouble with OSPF and ip_conntrack tables becoming full. Basically a router becomes offline when it’s conntrack table becomes full, but worse still other downstream routers do not reroute through alternate redundant paths when this happens. Whole sections of our network disappear.
This is causing instability in a large network but I can distil the situation down to a small example as follows:
Take four Linux routers connected in a ring. Call them A, B, C and D. All the links are DSL at 2Mbs.
A --------- B
| |
| |
| |
| |
| |
D-----------C
Sending a ping from A to C we find that normally it goes out through B and the replies comes back through D. This is easily seen by the DSL link lights flashing all around the ring in my lab set up.
Then I load the ip_conntrack kernel module into unit B and set the connection table maximum size to only 2 thus guaranteeing that it will be full.
Result is that the ping no longer makes it through unit B, the ping fails.
Basically we have lost communication with unit C (and B of course)
Increasing the size of the table back to 2048 allows the ping through B again and all is well.
This shows that a full conntrack table will prevent packet forwarding.
Now I set unit B's conntrack table back to 2, hence full, and wait a number of hours.
Result is that no routes change in any unit and the ping never works.
This shows that OSPF never realizes that unit B is no longer routing traffic. After all, all the links are up and running. Unit B and C drop off the net forever (Or at least for the three or four hours I have waited so far).
Hope I have explained this clearly. Is this expected OSPF behavior? Are there some ip_tables rules I could use to prevent this? Or do I have to rely on huge conntrack tables that won’t fill up?
Regards,
Michael Rychlik.
Ystävällisin terveisin / Best Regards
Michael Rychlik
Swarco Technology
Niittylänpolku 16
FIN-00620 Helsinki
Tel: +358 20 741 0325
Mobile: +358 40 822 8586
Fax: +358 9 777 3103
E-mail: Michael.Rychlik-xAkaozuzeH3QT0dZR+AlfA@public.gmane.org
This message contains information that may be privileged or confidential and is the property of Swarco. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you receive this message in error, please notify the sender immediately by reply e-mail and delete all copies of this message. Thank you for your cooperation
.
_______________________________________________ Quagga-users mailing list Quagga-users@... http://lists.quagga.net/mailman/listinfo/quagga-users
4 Jan 2007 16:03
[quagga-users 7897] Re: ospf and a full ip_contrack table
On Thu, Jan 04, 2007 at 02:48:59PM +0100, Rychlik, Michael - FI wrote:
> Hi all,
>
>
>
> We are having a little trouble with OSPF and ip_conntrack tables
> becoming full.
> [..]
>
> Hope I have explained this clearly. Is this expected OSPF behavior? Are
> there some ip_tables rules I could use to prevent this? Or do I have to
> rely on huge conntrack tables that won't fill up?
>
It is a _feature_ of ip_conntrack that it does not forward anymore
when the tables are full. If I remember this right, it is only
forwarding which stops, which is then why all OSPF keepalives etc.
continue to arrive, giving OSPF no chance to detect anything is wrong.
In this situation, it is clearly not OSPFs fault.
IMHO you have the options:
- do not use ip_conntrack at all
* if you have no firewall rules and do not do NAT in any
form you can chuck the ip_conntrack modules.
* Without nat, only needing firewalling, you can define
your firewall rules stateless (and not load the ip_conntrack
stuff). This is inherently inefficient but it works (you may
have to add some more rules). Caveat: protocols which
freely choose ports may give you a headache, need large
port ranges to be opened, or basically need an "all open"
policy (which may even prevent this approach).
- restrict ip_conntrack to track only the connections you really
need to track (this may or may not be possible in your setup,
depends on your rules).
- enlarge the tables enough so you are always in the green
* or write a script that increases the table
space on-the-fly whenever you use more than, e.g. 70% of the
available slots. From time to time you should then
check the current parameters (and increase the buckets when
max has been increased quite a lot) and ensure the current
values will be taken again after a reboot.
Kind regards,
Juergen.
--
--
Juergen Kammer Email: j.kammer@...
4 Jan 2007 16:05
[quagga-users 7898] Re: ospf and a full ip_contrack table
On Thu, 4 Jan 2007, Rychlik, Michael - FI wrote: > Result is that the ping no longer makes it through unit B, the ping > fails. > > Basically we have lost communication with unit C (and B of course) > This shows that a full conntrack table will prevent packet forwarding. That seems an issue to take up on the Linux network and/or iptables lists. > Now I set unit B's conntrack table back to 2, hence full, and wait > a number of hours. > Result is that no routes change in any unit and the ping never works. > This shows that OSPF never realizes that unit B is no longer > routing traffic. After all, all the links are up and running. Unit > B and C drop off the net forever (Or at least for the three or four > hours I have waited so far). That's not ideal. If I understand the situation correctly this is because OSPF is still working fine, still in contact with its neighbours, still seeing a full topology; but forwarding is broken. Correct? I'm not sure what ospfd could do here. You want some way to tie forwarding failure to OSPF, correct? As a quick interim hack, you could run a script on machine to stop OSPF as/when the conntrack table fills up. You could enable again if/when the conntrack table empties, but I suspect you'll just end up with oscillation. > Hope I have explained this clearly. Is this expected OSPF behavior? Are > there some ip_tables rules I could use to prevent this? Or do I have to > rely on huge conntrack tables that won't fill up? - Yes - OSPF knows nothing about conntrack, iptables or (generally) the state of forwarding. - no idea - "increase resources" is usually the first answer for resource starvation problems.. Other than that, it's something perhaps to enquire up on Linux iptables specific lists. regards. -- -- Paul Jakma paul@... paul@... Key ID: 64A2FF6A Fortune: I think... I think it's in my basement... Let me go upstairs and check. -- Escher
4 Jan 2007 16:09
[quagga-users 7899] Re: ospf and a full ip_contrack table
Rychlik, Michael - FI wrote: > > Hope I have explained this clearly. Is this expected OSPF behavior? Are > there some ip_tables rules I could use to prevent this? Or do I have to > rely on huge conntrack tables that won’t fill up? > The best way for linux routers with large number of connections passing through and limited amount of RAM is not to use connection tracking at all. Almost all iptables rules for TCP traffic (except for 'nat' chains) could be rewritten without using ip_conntrack. Avoid using 'state' match (use generic packet matching, look for 'RST SYN' in iptables manpage) an ip_conntrack will not be loaded into kernel. Yes, you'll loose some flexibility and security this way, but save your RAM. Or, if you only use 'INPUT' chain of 'filter' table, you may look for NOTRACK iptables match. This could require some kernel and iptables patching, but works like a charm. -- Vladislav Bogdanov
4 Jan 2007 21:16
[quagga-users 7900] how to know if tcp-md5 is working on quagga
Hello again, I'm trying to use quagga with my BGP peers, but I still have no success when the other peer requires a password.How can I check if the communication between the peers is using that TCP-MD5 "thing" I had to install (already recompiled kernel and recompiled quagga)? My config looks like: router bgp 65001 bgp router-id 192.168.255.221 network 192.168.254.0/24 neighbor 10.10.10.253 remote-as 65000 neighbor 10.10.10.253 password mypassword neighbor 10.10.10.253 soft-reconfiguration inbound Maybe there's a configuration error? tyrant.stech.net.br# show ip bgp summary ... Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd ... 10.10.10.253 4 65000 25 193 0 0 0 00:19:20 Active It is always in "Active" state, but that isn't right, right? :P TIA -- -- Atenciosamente, Felipe Grazziotin SouthTech Datacenter
RSS Feed