Re: [Vyatta-users] Soft lockup detected on CPU#0

2007-12-20 Thread David Nalley
Ben Strum wrote:
> We are running VC2 on a server with 2 NICs.  The system had been 
> function fine, but recently, we have started to see the machine freeze 
> with a message saying "Soft lockup detected on CPU#0".  I looked into 
> this message couldn't find any resolutions.  Does anyone know anything 
> about this?
>  
> Thanks,
>  
> Ben Strum
Historically such messages tend to problems with softirq managers like 
irqbalance.

Usual stuff to try is disabling ioapic, disabling ACPI, checking for BIOS
updates that mention ACPI fixes or Interrupt table fixes or $PIR fixes. Possibly
also disabling MSI if its in use. Sometimes even changing the the slot a card 
is plugged into. 



___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] Possible Memory Leak

2007-12-17 Thread David Nalley
Well, it probably should - but it's one of those things that if you have
been around unix-like systems for a long time you do the calculations
automatically in your head, and don't think about it. Just like normal
users never think about how filesystems are mounted or dns works, but
people who use them all of the time assume that knowledge if they pass
information on to them. (I have that problem alot - I get so used to
talking to other propeller heads that I forget people don't talk that
way in real life.) To illustrate this point - the man page for free
doesn't even tell you what -m does.

Yet another good enhancement request - Vyattans - will you modify
mailman to either use reply to all or reply to list?


David Nalley


Shane McKinley wrote:
> Shouldn't the command 'show system memory' be mapped to run through
> 'free -m' then? I would consider this as a feature enhancement.
>
> I am also in a state of confusion as to why this list insists on sending
> the reply address as the sender of the last message..I have to manually
> copy and paste the '[EMAIL PROTECTED]' email address into the To..
> box everytime I reply to a message.
>
> Thanks, 
>
> Shane McKinley
> Habersham EMC
>
> -Original Message-
> From: David Nalley [mailto:[EMAIL PROTECTED] 
> Sent: Monday, December 17, 2007 1:08 PM
> To: Nick Davey; [EMAIL PROTECTED]
> Subject: Re: [Vyatta-users] Possible Memory Leak
>
> To people who aren't used to dealing with Unix-like systems this is a
> common complaint.
> What show system memory is really doing is running free.
>
> BTW Vyattans - to avoid this in the future, please consider this a
> enhancement request to alias 'show system memory' to 'free -m'
>
> In olden days, RAM was expensive, but it's also very fast; far faster
> than disk, so Linux would buffer and cache items to RAM that it
> 'thought' it would use, and keep it near full all of the time, because
> it was mere nanoseconds to dump and fill with something else. The
> thought was that you paid oodles for this expenseive RAM, might as well
> use it to speed the system up even if you don't have a lot of use for it
> as RAM, maybe we can use it as a tertiary level CPU cache, or a nice
> disk buffer. To really see what is 'freeable' it should look at free ram
> as the free column plus buffers and cache.
>
> If you use free -m from the comand line you will see something akin to:
> vyatta:~# free -m
>  total   used   free sharedbuffers
> cached
> Mem:  1011995 16  0467
> 427
> -/+ buffers/cache:100911
> Swap:0  0  0
>
>
> Which shows that the system is really consuming only 100 Megs of RAM but
> has almost 900 cached.
>
>
> Nick Davey wrote:
>   
>> Hi All,
>> I've noticed some pretty intense memory usage out of my Vyatta router:
>>
>> [EMAIL PROTECTED]> show system memory
>>   total   used   free sharedbuffers
>> 
> cached
>   
>> Mem:255268 250956   4312  0 142652
>> 
> 32900
>   
>> Swap:0  0  0
>> Total:  255268 250956   4312
>>
>> I know the spacing is a bit off, but free memory is only 4312 bytes.
>> Examining the process memory usage under the shell shows that the xorp
>> 
>
>   
>> daemons are using the lions share of the memory:
>>
>> core:~# ps aux | more
>> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME
>> 
> COMMAND
>   
>> root 1  0.0  0.2   1948   636 ?Ss   Oct31   0:03 init
>> 
> [2]
>   
>> root 2  0.0  0.0  0 0 ?SOct31   0:00
>> [migration/0]
>> root 3  0.0  0.0  0 0 ?SN   Oct31   0:00
>> [ksoftirqd/0]
>> root 4  0.0  0.0  0 0 ?SOct31   0:00
>> [watchdog/0]
>> root 5  0.0  0.0  0 0 ?S<   Oct31   0:00
>> [events/0]
>> root 6  0.0  0.0  0 0 ?S<   Oct31   0:00
>> 
> [khelper]
>   
>> root 7  0.0  0.0  0 0 ?S<   Oct31   0:00
>> 
> [kthread]
>   
>> root31  0.0  0.0  0 0 ?S<   Oct31   0:00
>> [kblockd/0]
>> root52  0.0  0.0  0 0 ?S<   Oct31   0:00
>> 
> [kseriod]
>   
>> root86  0.0  0.0  0 0 ?SOct31   0:00
>> 
> [pdflush]
>   
>> root87  0.0  

Re: [Vyatta-users] Possible Memory Leak

2007-12-17 Thread David Nalley
To people who aren't used to dealing with Unix-like systems this is a
common complaint.
What show system memory is really doing is running free.

BTW Vyattans - to avoid this in the future, please consider this a
enhancement request to alias 'show system memory' to 'free -m'

In olden days, RAM was expensive, but it's also very fast; far faster
than disk, so Linux would buffer and cache items to RAM that it
'thought' it would use, and keep it near full all of the time, because
it was mere nanoseconds to dump and fill with something else. The
thought was that you paid oodles for this expenseive RAM, might as well
use it to speed the system up even if you don't have a lot of use for it
as RAM, maybe we can use it as a tertiary level CPU cache, or a nice
disk buffer. To really see what is 'freeable' it should look at free ram
as the free column plus buffers and cache.

If you use free -m from the comand line you will see something akin to:
vyatta:~# free -m
 total   used   free sharedbuffers cached
Mem:  1011995 16  0467427
-/+ buffers/cache:100911
Swap:0  0  0


Which shows that the system is really consuming only 100 Megs of RAM but
has almost 900 cached.


Nick Davey wrote:
> Hi All,
> I've noticed some pretty intense memory usage out of my Vyatta router:
>
> [EMAIL PROTECTED]> show system memory
>   total   used   free sharedbuffers cached
> Mem:255268 250956   4312  0 142652  32900
> Swap:0  0  0
> Total:  255268 250956   4312
>
> I know the spacing is a bit off, but free memory is only 4312 bytes.
> Examining the process memory usage under the shell shows that the xorp
> daemons are using the lions share of the memory:
>
> core:~# ps aux | more
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> root 1  0.0  0.2   1948   636 ?Ss   Oct31   0:03 init [2]
> root 2  0.0  0.0  0 0 ?SOct31   0:00
> [migration/0]
> root 3  0.0  0.0  0 0 ?SN   Oct31   0:00
> [ksoftirqd/0]
> root 4  0.0  0.0  0 0 ?SOct31   0:00
> [watchdog/0]
> root 5  0.0  0.0  0 0 ?S<   Oct31   0:00
> [events/0]
> root 6  0.0  0.0  0 0 ?S<   Oct31   0:00 [khelper]
> root 7  0.0  0.0  0 0 ?S<   Oct31   0:00 [kthread]
> root31  0.0  0.0  0 0 ?S<   Oct31   0:00
> [kblockd/0]
> root52  0.0  0.0  0 0 ?S<   Oct31   0:00 [kseriod]
> root86  0.0  0.0  0 0 ?SOct31   0:00 [pdflush]
> root87  0.0  0.0  0 0 ?SOct31   0:00
> [pdflush]
> root88  0.0  0.0  0 0 ?S<   Oct31   0:00 [kswapd0]
> root89  0.0  0.0  0 0 ?S<   Oct31   0:00 [aio/0]
> root  1494  0.0  0.0  0 0 ?S<   Oct31   0:00 [khubd]
> root  1580  0.0  0.0  0 0 ?S<   Oct31   0:00 [ata/0]
> root  1581  0.0  0.0  0 0 ?S<   Oct31   0:00 [ata_aux]
> root  1843  0.0  0.0  0 0 ?S<   Oct31   0:09
> [kjournald]
> root  2006  0.0  0.2   2176   612 ?S --daemon
> root  2835  0.0  0.0  0 0 ?S<   Oct31   0:00
> [kpsmoused]
> root  2930  0.0  0.0  0 0 ?S<   Oct31   0:00
> [kgameportd]
> root  3118  0.0  0.0  0 0 ?S<   Oct31   0:00
> [kmirrord]
> root  3123  0.0  0.0  0 0 ?S<   Oct31   0:00 [ksnapd]
> root  3150  0.0  0.0  0 0 ?S<   Oct31   0:00
> [kjournald]
> root  3543  0.0  0.1   1584   384 ?Ss   Oct31   0:00
> /sbin/klogd -x
> root  3738  0.0  0.2   2196   752 ?Ss   Oct31   0:00
> /usr/sbin/cron
> root  3904  0.5  5.7  28840 14636 ?Ss   Oct31 376:11
> /opt/vyatta/sbin/xorp_rtrmgr -b /opt/vyatta/etc/config/config.boot
> root  3909  0.0  2.3  19972  6032 ?SOct31  36:38
> xorp_rl_firewall
> root  3923  0.0  0.0  0 0 ?S<   Oct31   0:00
> [unionfs_siod/0]
> root  4083  0.0  4.2  24492 10752 ?SOct31  35:04 xorp_fea
> root  4213  0.0  3.2  21600  8324 ?SOct31   9:37 xorp_rib
> root  4216  0.0  2.3  19928  6080 ?SOct31   4:03
> xorp_rl_protocols
> root  4229  0.0  2.7  18520  7008 ?SOct31  32:59
> /usr/sbin/snmpd -p /var/run/snmpd.pid
> root  4230  0.0  2.3  20036  6104 ?SOct31   4:12
> xorp_rl_service
> root  4886  0.0  0.6   2656  1620 ?Ss   Oct31   0:02
> /opt/vyatta/bin/dhcpd -f -pf /var/run/dhcpd-unused.pid -cf
> /opt/vyatta/etc/dhcpd.conf -lf /v
> ar/log/dhcpd.leases
> root  4901  0.0  0.4   4928  1096 ?Ss   Oct31   0:00
> /usr/sbin/sshd -o HostKey=/etc/ssh/ssh_host_key -o Protocol=2 -p 2

Re: [Vyatta-users] Running Vyatta in RAID1setup? P erformancemonitoring?

2007-10-25 Thread David Nalley
This may not be the problem - but does the Vyatta initrd load md support (or 
is it monolithically compiled into the kernel?) I don't know the answer to 
that question. 
If not you may have to make your own initrd. 
Obviously you get to grub, and grub tries to load the jernel - how about 
pasting the last 30 or so lines of the boot failure, would help us a lot more 
in pointing you in the right direction. 




On Wednesday 24 October 2007 23:34:44 Daren Tay wrote:
> anyone did raiding with their vyatta before?
> so far, I am trying with VC2.2 and after reboot, the system can't boot
> properly. GRUB is installed in one of the harddisk.
> Not sure if that's the case.


___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] Interface name preservation

2007-10-24 Thread David Nalley
I think (emphasis on the think part) that somewhere along 2.0 the conf 
files changed so that it identified interfaces by the mac address and 
used that to preserve the device name to real hardware mapping.



Aubrey Wells wrote:
> Is there any mechanism in vyatta to protect interface names if there 
> is a new NIC added to the box? I have a new project starting and I'm 
> waiting on some hardware to come in. I'm planning on adding 5 
> quad-port ethernet cards to the box - right now I only have a DS3 
> interface, and a single quad-port ethernet card, plus the two onboard 
> nics. I'm worried that if I go forward now and then add the new 
> interfaces, Linux will rename all the interfaces and my config will be 
> hosed while I try to sort out what became what. All the interfaces are 
> Intel cards, except the onboard (broadcom) and the DS3 (Sangoma).
>
> I've discovered in the past that if you swap an interface out, 
> rtrmanager will choke and not start until you manually delete all the 
> hardware-id lines from the config file with vi and reboot so it can 
> sort out the MACs. 
>
> So should I put the project on hold, or try to accelerate the arrival 
> of my ethernet cards, or should I be ok?
>
> TIA
> *
> *
> *--*
> *Aubrey Wells*
> /Senior Engineer/
> Shelton | Johns Technology Group
> A Vyatta Ready Partner
> www.sheltonjohns.com
>
>
>
>
> 
>
> ___
> Vyatta-users mailing list
> Vyatta-users@mailman.vyatta.com
> http://mailman.vyatta.com/mailman/listinfo/vyatta-users
>   

___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] IPSec VPN - almost working! Help please...

2007-10-22 Thread David Nalley
Sorry that is what I get for reading something last night and thinking 
that I would remember today.

Regardless if it's getting across then the problem 'probably' isn't in 
the VPN.
So if V to N works, but N to V doesn't - does your Netgear filter 
outbound? Is that the problem. Does the netgear device know the route 
path (I know you said you created a static route, but don't recall(the 
fact that traffic returned suggests that it does.) )

tcpdump -i INTERFACENAME   OptionalFilterParameters

You won't see actual traffic, probably just the ESP packets, but at 
least you can compare the two points.




Dan Murray wrote:
> David,
>
> Just to be clear the pings are working from the VYATTA network to the 
> NETGEAR one. Not from netgear to vyatta.
>
> I am not familiar with tcpdump - how would I use this?
>
> Thanks for the help.
>
> Dan
>
> On 10/22/07, *David Nalley* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 
> wrote:
>
> Dan are you sure that the netgear isn't filtering (firewall) traffic?
> Pings work from the netgear network to vyatta, meaning it's
> leaving the
> netgear network traversing the tunnel hitting the destination and
> then
> returning to the netgear network. So bi-directional traffic is working
> just fine. What does tcpdump or tshark show you?
>
> Dan Murray wrote:
> > Hey Robyn,
> >
> > Yeah, I guess I didn't give you the whole story. The vyatta
> "machine"
> > is your VMWare image, which is behind a $50 firewall router. So the
> > 0.0.0.0/0 <http://0.0.0.0/0> <http://0.0.0.0/0> static route to
> 10.0.2.1 <http://10.0.2.1>
> > <http://10.0.2.1> is to go through that router before hitting the
> > internet. The VMware box is in the DMZ, so it seems like it
> should be
> > ok that way. But of course this complicates things in that
> everything
> > is going through eth0. Probably not the best way to do it but really
> > my only choice since it's not on dedicated hardware.
> >
> > I am confused as to why you have the vyatta and netgear both on the
> > same private subnet over the internet - shouldn't these be public
> > internet addresses in this case? That is the scenario.
> >
> > And to answer your question about the tunnel, traffic is definitely
> > going both ways. Doing a show sa stats does in fact prove this -
> I see
> > bytes both in and out. So I'm lead to believe that the tunnel itself
> > is just fine, and maybe even the vyatta machine is fine and for
> some
> > reason the netgear isn't routing over the tunnel. Maybe my static
> > route is screwed up?
> >
> > Anyway, beyond that I probably can't follow - I'm not too savvy
> about
> > routing. But like I said it definitely works one way. I can even
> pull
> > up web pages hosted on the remote network (.0.0) on the local
> network
> > (.2.0) with no problems whatsoever. Just can't do the same from the
> > remote network back. Confusing indeed.
> >
> > Thanks again for the help.
> >
> > Dan
> >
> > On 10/22/07, *Robyn Orosz* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
> >
> > Hi Dan,
> >
> > I'm not sure how you are able to ping the devices behind the
> > Netgear but it's most likely not via the VPN tunnel.  If traffic
> > is only passing one-way on a tunnel you normally wouldn't
> see the
> > return packets from your pings.  If you run a 'show vpn ipsec sa
> > statistics' on the Vyatta router, I'm thinking you'll see 0
> bytes
> > in and out but let me know.
> >
> > Normally a VPN network to network tunnel will look something
> like-->
> >
> >
> > Internet
> > Vyatta  eth1 Vyatta  eth0
> > - Netgear WAN
> > Netgear LAN
> > 10.0.2.0/24 <http://10.0.2.0/24>
> <http://10.0.2.0/24>  10.0.1.1/24 <http://10.0.1.1/24>
> > < http://10.0.0.0/24>
> >   10.0.1.2/24 <http://10.0.1.2/24>
> <http://10.0.2.0/24>
> > 10.0.0.0/24 <http://10.0.0.0/24> < http://10.0.0.0/24>
&

Re: [Vyatta-users] IPSec VPN - almost working! Help please...

2007-10-22 Thread David Nalley
  hash: "sha1"
>> }
>> mode: "tunnel"
>> lifetime: 28800
>> pfs: "enable"
>> compression: "disable"
>> }
>> site-to-site {
>> peer *netgear IP here* {
>> authentication {
>> mode: "pre-shared-secret"
>> pre-shared-secret: "SECRET IS HERE"
>> }
>> ike-group: "ike-1"
>> local-ip: 10.0.2.2 <http://10.0.2.2>
>> tunnel 1 {
>> local-subnet:  10.0.2.0/24
>> <http://10.0.2.0/24>
>> remote-subnet: 10.0.0.0/24
>> <http://10.0.0.0/24>
>> allow-nat-networks: "disable"
>> allow-public-networks: "disable"
>> esp-group: "esp-1"
>> }
>> }
>> }
>> }
>> }
>> rtrmgr {
>> config-directory: "/opt/vyatta/etc/config"
>> }
>>
>>
>> Any ideas? The netgear side does have a NAT. I guess the vyatta
>> side does too.
>>
>> Thanks in advance...
>>
>> Dan
>>
>>
>> On 10/22/07, * Robyn Orosz* <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>> wrote:
>>
>> Hi Dan,
>>
>> It's not clear to me which end can ping what from your
>> original message
>> but here's a few ideas...if your only purpose for creating a
>> firewall on
>> the Vyatta router was to allow packets to flow through the
>> VPN tunnel,
>> you don't need it.  You should delete the firewall or remove
>> it from the
>> interface until you get traffic passing as the firewall may
>> make this
>> issue more difficult to pinpoint.
>>
>> The Vyatta router allows all packets through by
>> default.  There is no
>> firewall unless you explicitly configure one.
>>
>> Are you using NAT on either device?  Because NAT has the
>> potential to
>> cause problems when passing traffic over a tunnel.  All
>> packets must
>> match the left and right subnets in order to enter the VPN
>> tunnel.  If
>> they are modified in any way by some sort of NAT rule, they
>> won't be
>> allowed to enter the tunnel.  So, if you're NAT'ing on the
>> Netgear
>> you'll need to find a way to exclude VPN packets from being
>> NAT'ted.  If
>> you're NAT'ing on the Vyatta router, you'll need to do the same.
>>
>> If it doesn't appear to be a NAT issue, you may want to post your
>> configs so we can make sure everything looks correct otherwise.
>>
>> Thanks!
>>
>> Robyn
>>
>> Dan Murray wrote:
>> > Yes, both tunnels are up. I doubt the tunnels are the
>> problem. As I
>>     > said I can use the tunnel just fine one way (pings go through to
>> > remote hosts and everything). However coming back toward the
>> vyatta
>> > net nothing gets through.
>> >
>> > I'll look into logging. I still feel like I'm missing a step
>> on the
>> > vyatta side. Normally with a cisco, after making the route
>> I'd have to
>> > make a policy to allow packets to that net, but I thought I
>> did that
>> > already with the firewall command. Maybe there's something
>> else I'm
>> > missing, routing maybe?
>> >
>> > Here's another question - the tunnel is on eth0. When I
>> allow the
>> > packets, I'm allowing them from eth0 to the local net -
>> which doesn't
>> > seem right but I don't know how else to do it. Is there
>> another way to
>> > refer to the tunnel when 

Re: [Vyatta-users] IPSec VPN - almost working! Help please...

2007-10-21 Thread David Nalley
Hey Dan, 

Just a thought, is it a firewall issue?


-Original Message-
From: [EMAIL PROTECTED] on behalf of Dan Murray
Sent: Sun 10/21/2007 6:21 PM
To: vyatta-users@mailman.vyatta.com
Subject: [Vyatta-users] IPSec VPN - almost working! Help please...
 
Hey guys,

I was impressed with myself, actually able to get an IPSec tunnel up and
running between vyatta and a Netgear router, but I must be missing a final
step. The tunnel works just fine, and I made a static route for that subnet
and can ping anything on the remote LAN just fine from the vyatta machine.
However, I cannot get from the other side of the network (the remote side)
back to the vyatta net. Is there anything I need to do on the vyatta end to
allow packets to come on through?

Thanks guys,

Dan M

___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


[Vyatta-users] question about openvpn + ofr

2007-10-16 Thread David Nalley
Hey guys,

I have been playing around with v2.2 and added openvpn, which appears to 
be running, and of course it creates a tun interface.
How are people handling firewalling the vpn clients from other segments 
of their network?? Are you able to do so via xorpsh?

It appears from the logfiles that xorp is trying to kill the tun interface:
  
Oct 16 14:25:58 localhost xorp_static_routes: IfMgrVifRemove::execute(), 
removing vif entry: tun0
Oct 16 14:25:58 localhost xorp_rib: IfMgrVifRemove::execute(), removing 
vif entry: tun0
Oct 16 14:25:58 localhost xorp_rib: [ 2007/10/16 14:25:58  ERROR 
xorp_rib:4574 RIB +330 
/home/autobuild/builds/OFR/2007-08-23-1113/ofr/xorp/xorp/rib/vifmanager.cc 
updates_made ] Cannot delete vif tun0 from the set of configured vifs: 
Failed to delete VIF "tun0" from Unicast IPv4 RIB, and failed to delete 
VIF "tun0" from Multicast IPv4 RIB, and failed to delete VIF "tun0" from 
Unicast IPv6 RIB, and failed to delete VIF "tun0" from Multicast IPv6 RIB

Thoughts?? I know I hear (and have for sometime) that a ton of people 
have been using vyatta and openvpn, but I see a dearth of documentation 
on such things. And while it seemed really simple, I can't help but 
imagine that there are pitfalls that I have yet to see, anyone have 
notes jotted down?

Thanks,

David Nalley


___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] Paid Support for Vyatta

2007-09-11 Thread David Nalley
I wouldn't say that the access to additional KB is worth the
subscription fee - the community is pretty good (even Vyatta employees)
are pretty good about answering questions.
Support is worth its weight in gold if you need help on the spot. And
the Vyatta support guys are great - spending hours helping me diagnose
problems that ended up being ISP related instead of router related, but
they stuck with me. Support is cheap given the application you seem to
have for an OFR, and it's a great value.


Daren Tay wrote:
> I'm considering requesting my company to get a paid subscription to Vyatta,
> so as to access more knowledge base information for our troubleshooting
> needs..
> 
> but.. I'm not sure how better to ask this, but is the community one
> sufficient? Or am I paying more for the response time?
> 
> Thanks!
> Daren
> 
> ___
> Vyatta-users mailing list
> Vyatta-users@mailman.vyatta.com
> http://mailman.vyatta.com/mailman/listinfo/vyatta-users

___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users