In an F5 bigIP LTM with sw version 11.4.1, is it possible to have multiple sources addresses for a virtual server?
The objective is to limit the number of sources from where the virtual server can be reached. This virtual server balances an ftp server which will only be used from a few remote ip addresses and I want to prohibit other ip addresses to try to login to this server.
Server A has a public ip and a private ip, each on another vlan and thus on another virtual interface.
How can I enable scp only on the public ip and ssh only on the private IP, for all users.
Kind regards
Hannes De Bondt
Since a few hours, my xen VM does not want to be created.
The VM is quite unstable so I need to destroy and create is quite often. This morning I was able to do such a destroy-create cycle. A few hours later, the destroy - create cycle failed with following error: The error
~: xm create /etc/xen/buildbox03.cfg -c Using config file "/etc/xen/buildbox03.cfg". Error: Creating domain failed: name=buildbox03
errorlogs in /var/log/xen/xend.log:
[2013-05-14 14:11:34 3735] DEBUG (XendDomainInfo:84) XendDomainInfo.create(['vm', ['name', 'buildbox03'], ['memory', '3072'], ['on_poweroff', 'destroy'], ['on_reboot', 'restart'], ['on_crash', 'restart'], ['vcpus', 3], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['image', ['linux', ['kernel', '/boot/vmlinuz-2.6.34-1- netlog'], ['ip', ':1.2.3.4::::eth0:dhcp'], ['root', '/dev/xvda1 ro']]], ['device', ['vbd', ['uname', 'phy:/dev/ lvmpool/buildbox03-root'], ['dev', 'xvda1'], ['mode', 'w']]], ['device', ['vbd', ['uname', 'phy:/dev/lvmpool/ buildbox03-swap'], ['dev', 'xvda2'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'br0'], ['mac', '00:16:3E:99:7F: A1']]], ['device', ['vif', ['bridge', 'br2'], ['mac', '00:16:3E:99:7F:A2']]]])
[2013-05-14 14:11:34 3735] DEBUG (XendDomainInfo:1618) XendDomainInfo.constructDomain
[2013-05-14 14:11:34 3735] DEBUG (balloon:132) Balloon: 11813504 KiB free; need 2048; done.
[2013-05-14 14:11:34 3735] ERROR (XendDomainInfo:440) VM start failed
Traceback (most recent call last):
File "/usr/lib/xen-3.2-1/bin/../lib/python/xen/xend/XendDomainInfo.py", line 419, in start
XendTask.log_progress(0, 30, self._constructDomain)
File "/usr/lib/xen-3.2-1/bin/../lib/python/xen/xend/XendTask.py", line 209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib/xen-3.2-1/bin/../lib/python/xen/xend/XendDomainInfo.py", line 1656, in _constructDomain
self.info['name_label'])
VmError: Creating domain failed: name=buildbox03
[2013-05-14 14:11:34 3735] DEBUG (XendDomainInfo:1897) XendDomainInfo.destroy: domid=None
[2013-05-14 14:11:34 3735] ERROR (XendDomainInfo:89) Domain construction failed
Traceback (most recent call last):
File "/usr/lib/xen-3.2-1/bin/../lib/python/xen/xend/XendDomainInfo.py", line 87, in create
vm.start()
File "/usr/lib/xen-3.2-1/bin/../lib/python/xen/xend/XendDomainInfo.py", line 419, in start
XendTask.log_progress(0, 30, self._constructDomain)
File "/usr/lib/xen-3.2-1/bin/../lib/python/xen/xend/XendTask.py", line 209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib/xen-3.2-1/bin/../lib/python/xen/xend/XendDomainInfo.py", line 1656, in _constructDomain
self.info['name_label'])
VmError: Creating domain failed: name=buildbox03
[2013-05-14 14:11:34 3735] DEBUG (XendDomainInfo:1897) XendDomainInfo.destroy: domid=None
buildbox03 config in /etc/xen/buildbox03.cfg:
kernel = '/boot/vmlinuz-2.6.34-1'
memory = '3072'
vcpus = 3
root = '/dev/xvda1 ro'
disk = [
'phy:/dev/lvmpool/buildbox03-root,xvda1,w',
'phy:/dev/lvmpool/buildbox03-swap,xvda2,w',
]
name = 'buildbox03'
dhcp = 'dhcp'
vif = [ 'mac=xxxxxx,bridge=br0', 'mac=yyyyyyy,bridge=br2' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
Can you guide me to troubleshoot this problem a bit better?
Our Dell Powerconnect 62xx switches have a very high packetloss on the management interface. I presume this is caused by a new appliance which uses multicast for communication but I am not sure.
Our network setup is following:
servers a -> Dell PC6248 |
servers b -> Dell PC6248 |-> juniper core router
servers c -> Dell PC6248 |
What we see is that the multicast traffic arrives at all servers (but only the servers b use the multicast) and I fear that this multicast traffic floods the switch management interface.
The switches' management interfaces are reachable via vlan101, all other traffic is sent over other vlans. When I tcpdump on one of the 2 servers with a vlan 101 ip address, I only get a few arp requests but almost nothing. When I try to ping between these 2 servers, it works like a charm.
I would like to know what a good way is to troubleshoot this problem and maybe help me understand what is going wrong on that subnet.
In the network we have a few vlans but at the moment I was investigating vlan2 which carries the most traffic. When tcpdumping on the eth0.2 interface, I see a lot of packets arriving which are not addressed to, nor coming from the server. I checked this on several servers in the network and they all have the same issues.
In short, our switches don't switch the traffic but threat it like they are a hub. Can you tell me what settings on the dell poweredge 6248 should prevent this behaviour?
I added some traffic I captured from the host. The ip address of the host is 192.168.3.232
192.168.3.248.80 > 192.168.62.102.26590:
192.168.3.232.35311 > 192.168.41.246.11211:
192.168.3.232.13412 > 192.168.19.200.3306:
192.168.3.232.35311 > 192.168.41.246.11211:
192.168.3.232.35311 > 192.168.41.246.11211:
192.168.3.234.12958 > 192.168.42.27.11211:
192.168.14.32.34077 > 192.168.19.200.3306:
192.168.3.232.36489 > 192.168.41.246.11211:
192.168.14.32.34077 > 192.168.19.200.3306:
192.168.14.9.42221 > 192.168.14.1.9312:
192.168.14.9.42221 > 192.168.14.1.9312:
192.168.14.9.42221 > 192.168.14.1.9312:
192.168.3.247.48542 > 192.168.41.37.11211:
192.168.3.235.9739 > 192.168.19.200.3306:
192.168.41.246.11211 > 192.168.3.232.36489:
192.168.3.232.36489 > 192.168.41.246.11211:
192.168.3.234.59715 > 192.168.41.199.11211:
192.168.14.32.34077 > 192.168.19.200.3306:
192.168.3.235.18919 > 192.168.42.12.11211:
192.168.25.122.7000 > 225.0.10.105.7000:
192.168.3.232.36489 > 192.168.41.246.11211:
192.168.3.236.43098 > 192.168.42.9.11211:
192.168.14.32.34077 > 192.168.19.200.3306:
192.168.3.236.43098 > 192.168.42.9.11211:
192.168.3.236.43098 > 192.168.42.9.11211:
192.168.11.84.4730 > 192.168.10.19.44335:
192.168.3.236.28328 > 192.168.42.11.11211:
There are 2 servers:
server1 - eth0 10.129.76.16 eth0.2 192.168.0.103
server2 - eth0 10.129.79.1 eth0.2 192.168.62.101
The 192.x.x.x addresses are connected to the same vlan (vlan2) and are able to see eachother. The 10.x.x.x addresses are connected to different vlan's which are not able to see eachother.
on request of David Swartz: the routing table on server 1 is:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.129.76.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
0.0.0.0 192.168.61.254 0.0.0.0 UG 100 0 0 eth0.2
the routing table on server 2 is:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <public IP gw> 0.0.0.0 UG 100 0 0 eth0.11
10.129.79.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
<public IP> 0.0.0.0 255.255.255.128 U 0 0 0 eth0.11
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
When I ping from server 1 to server 2, it seems no packets are arriving and vice versa. When I check the routes (route -n) I see the default gw uses eth0.2 on both servers. But when I use arping, I get a response one way (from server 2 to server 1) but no response vice versa.
arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)
As you can see it uses the 10.x.x.x address instead of the 192.x.x.x. And as I told before, the 10.x.x.x address is unreachable from the other server.
When I force arping to use eth0.2, it does work.
I don't have any problems with ping'ing other servers from any of those 2 servers.
I did see this in the arp tables:
~# arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
and
~# arp -n | grep 192.168.62.101
quite obvious... How can I make these servers see each other again?
clear the apropriate entries in the arptable and tried to get rid of the (incomplete) But I think the biggest problem is that eth0 is used instead of eth0.2 for the packets from server 1 to server 2
Because of David Swartz' remark about the routing tables, I added a route in there defining the host. I added
192.168.0.103 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
and
192.168.62.101 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
to the appropriate servers but this didn't solve the problem so I presume the problem is not in the routing.
I guess the problem lies in the following.
~$ arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
but I'm unable to remove this entry. (arp -d 192.168.0.103 has no effect)
Thanks for reading and even more thanks for answering!
In our setup, we manage our servers using puppet. Since a few days I saw the puppet client running very slow. When stracing the puppet process I get loads of
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
Can anyone tell me what is going wrong? What is this process waiting for?