Just to add, in the database, the nics table: isolation_uri used to be set to "ec2://untagged" for vm_type="DomainRouter" of mode Dhcp.
This is no longer happening however, they are just set as NULL. I don't see a way to set this in the networks table however. How does this isolation_uri column get set, is it from the database or hard coded in the code? On Fri, Mar 27, 2015 at 10:02 AM, cs user <acldstk...@gmail.com> wrote: > Hi Again... :-) > > So it looks like the vif on the xenserver is not being setup correctly (or > has been removed). The following rule is defined on xen host which the > broken router is running on: > > Chain r-10864-VM (4 references) >> >> target prot opt source destination >> >> RETURN all -- anywhere anywhere PHYSDEV >>> match --physdev-in vif718.0 --physdev-is-bridged >> >> RETURN all -- anywhere anywhere PHYSDEV >>> match --physdev-in vif718.1 --physdev-is-bridged >> >> ACCEPT all -- anywhere anywhere >> >> >>> > The vif that is mentioned above is not present on the host. As below. But > on the working router, the vif in the iptable rule does exist. > > > On the host, we also see the following in the logs with the vif mentioned: > > Mar 26 14:04:31 xen011 script-vif: vif718.0: writing > backend/vif/718/0/hotplug-status=connected > Mar 26 14:04:31 xen011 scripts-vif: Setting vif718.1 MTU 1500 > Mar 26 14:04:31 xen011 scripts-vif: Adding vif718.1 to xapi4 with address > fe:ff:ff:ff:ff:ff > Mar 26 14:04:31 xen011 scripts-vif: Failed to ip link set vif718.1 address > fe:ff:ff:ff:ff:ff > Mar 26 14:04:31 xen011 python: > /opt/xensource/libexec/setup-vif-rules[3233] - ['/sbin/ip', 'link', 'set', > 'vif718.1', 'down'] > Mar 26 14:04:31 xen011 python: > /opt/xensource/libexec/setup-vif-rules[3233] - ['/sbin/ebtables', '-L', > 'FORWARD_vif718.1'] > Mar 26 14:04:31 xen011 python: > /opt/xensource/libexec/setup-vif-rules[3233] - ['/sbin/ip', 'link', 'set', > 'vif718.1', 'up'] > Mar 26 14:04:31 xen011 script-vif: vif718.1: writing > backend/vif/718/1/hotplug-status=connected > Mar 26 14:05:12 xen011 script-vif: vif718.1: removing > backend/vif/718/1/hotplug-status > Mar 26 14:05:12 xen011 script-vif: vif718.1: removing > /xapi/718/hotplug/vif/1/hotplug > Mar 26 14:05:12 xen011 scripts-vif: vif718.1 has been removed > Mar 26 14:05:12 xen011 python: > /opt/xensource/libexec/setup-vif-rules[4113] - ['/sbin/ip', 'link', 'set', > 'vif718.1', 'down'] > Mar 26 14:05:12 xen011 python: > /opt/xensource/libexec/setup-vif-rules[4113] - ['/sbin/ebtables', '-L', > 'FORWARD_vif718.1'] > Mar 26 14:05:13 xen011 python: > /opt/xensource/libexec/setup-vif-rules[4113] - ['/sbin/ip', 'link', 'set', > 'vif718.1', 'up'] > Mar 26 14:05:13 xen011 script-vif: vif718.0: removing > backend/vif/718/0/hotplug-status > Mar 26 14:05:13 xen011 script-vif: vif718.0: removing > /xapi/718/hotplug/vif/0/hotplug > Mar 26 14:05:13 xen011 scripts-vif: vif718.0 has been removed > Mar 26 14:05:13 xen011 python: > /opt/xensource/libexec/setup-vif-rules[4156] - ['/sbin/ip', 'link', 'set', > 'vif718.0', 'down'] > Mar 26 14:05:13 xen011 python: > /opt/xensource/libexec/setup-vif-rules[4156] - ['/sbin/ebtables', '-L', > 'FORWARD_vif718.0'] > Mar 26 14:05:13 xen011 python: > /opt/xensource/libexec/setup-vif-rules[4156] - ['/sbin/ip', 'link', 'set', > 'vif718.0', 'up'] > Mar 26 14:05:24 xen011 fe: 4917 (/sbin/ip addr show dev vif718.0) exitted > with code 255 > Mar 26 14:05:25 xen011 fe: 5062 (/sbin/ip addr show dev vif718.1) exitted > with code 255 > > > List of vif's, 718 is missing now however: > > >> vif477.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF >> >> UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 >> >> RX packets:150128316 errors:0 dropped:0 overruns:0 frame:0 >> >> TX packets:163423985 errors:0 dropped:0 overruns:0 carrier:0 >> >> collisions:0 txqueuelen:32 >> >> RX bytes:598157233 (570.4 MiB) TX bytes:501933888 (478.6 MiB) >> >> >>> vif671.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF >> >> UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 >> >> RX packets:38112 errors:0 dropped:0 overruns:0 frame:0 >> >> TX packets:71566 errors:0 dropped:0 overruns:0 carrier:0 >> >> collisions:0 txqueuelen:32 >> >> RX bytes:2005682 (1.9 MiB) TX bytes:92870677 (88.5 MiB) >> >> >>> vif696.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF >> >> UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 >> >> RX packets:20049 errors:0 dropped:0 overruns:0 frame:0 >> >> TX packets:49817 errors:0 dropped:0 overruns:0 carrier:0 >> >> collisions:0 txqueuelen:32 >> >> RX bytes:1215219 (1.1 MiB) TX bytes:62130987 (59.2 MiB) >> >> >>> vif703.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF >> >> UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 >> >> RX packets:1459 errors:0 dropped:0 overruns:0 frame:0 >> >> TX packets:1803 errors:0 dropped:0 overruns:0 carrier:0 >> >> collisions:0 txqueuelen:32 >> >> RX bytes:48244 (47.1 KiB) TX bytes:213662 (208.6 KiB) >> >> >>> vif719.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF >> >> UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 >> >> RX packets:1571 errors:0 dropped:0 overruns:0 frame:0 >> >> TX packets:75983 errors:0 dropped:2 overruns:0 carrier:0 >> >> collisions:0 txqueuelen:32 >> >> RX bytes:74416 (72.6 KiB) TX bytes:3710662 (3.5 MiB) >> >> >>> vif719.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF >> >> UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 >> >> RX packets:7982 errors:0 dropped:0 overruns:0 frame:0 >> >> TX packets:8513 errors:0 dropped:1 overruns:0 carrier:0 >> >> collisions:0 txqueuelen:32 >> >> RX bytes:1349032 (1.2 MiB) TX bytes:787782 (769.3 KiB) >> >> >>> vif720.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF >> >> UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 >> >> RX packets:75 errors:0 dropped:0 overruns:0 frame:0 >> >> TX packets:77 errors:0 dropped:0 overruns:0 carrier:0 >> >> collisions:0 txqueuelen:32 >> >> RX bytes:3404 (3.3 KiB) TX bytes:5502 (5.3 KiB) >> >> > > > > On Fri, Mar 27, 2015 at 8:57 AM, cs user <acldstk...@gmail.com> wrote: > >> Hi Jayapal, >> >> Those two parameters are both set to 1. >> >> We have a router which has survived the upgrade, and is still able to >> receive and return dns requests from instances. We have checked on the >> xenserver host and can see the following iptable config: >> >> Chain FORWARD (policy ACCEPT) >>> target prot opt source destination >>> BRIDGE-FIREWALL all -- anywhere anywhere >>> PHYSDEV match --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth0+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond3+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond0+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth1+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth3+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth6+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond1+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth2+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth5+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth7+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth4+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond2+ --physdev-is-bridged >>> DROP all -- anywhere anywhere >> >> >> >> However, on a xenserver which is running a router which is not working, >> we can see the following: >> >> Chain FORWARD (policy ACCEPT) >>> target prot opt source destination >>> BRIDGE-FIREWALL all -- anywhere anywhere >>> PHYSDEV match --physdev-is-bridged >>> >> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth1+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth4+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth3+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth7+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond3+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond0+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth6+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond1+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth5+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond2+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth0+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth2+ --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth1 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth4 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth3 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth7 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond3 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth6 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond1 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth5 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond2 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth0 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out eth2 --physdev-is-bridged >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-out bond0 --physdev-is-bridged >>> DROP all -- anywhere anywhere >> >> >> It seems the config is duplicated but without the pluses. I think these >> are similar to wildcard entries? >> >> Cheers! >> >> >> >> >> >> >> >> On Fri, Mar 27, 2015 at 8:46 AM, Jayapal Reddy Uradi < >> jayapalreddy.ur...@citrix.com> wrote: >> >>> Silly question but Is your xenserver configured bridge mode related >>> settings correctly ? >>> >>> #xe-switch-network-backend bridge >>> #echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables >>> #echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables >>> >>> Thanks, >>> Jayapal >>> On 27-Mar-2015, at 1:50 PM, cs user <acldstk...@gmail.com<mailto: >>> acldstk...@gmail.com>> wrote: >>> >>> Hi Somesh, >>> >>> arping looks good, the correct mac address is displayed and we get a >>> unicast reply from the ip address. >>> >>> Erik, tried restarting dnsmasq, all looks fine. VR is able to perform >>> outgoing dns requests. There is nothing in syslog/dnsmasq logs that I can >>> see. No egress rules are in place. The system vm's are able to perform >>> dig's against google's dns, but not the virtual router. It seems it is >>> being blocked at the xen level. >>> >>> We're seeing the below in the logs when restarting a network (either >>> ticking clear config or not). This appears to be similar to : >>> >>> https://issues.apache.org/jira/browse/CLOUDSTACK-7605 >>> >>> We are using basic zones, some have multiple pods, others don't. We see >>> the >>> same error in both. The routers come up though and go green, and dnsmasq >>> is >>> populated with the relevant info. DNS lookups work locally on the router, >>> just not remotely. DHCP is working for new machines which get spun up. >>> >>> Is there a way to debug this? I've checked the logs on the router >>> (cloud.log) can't see any errors in there. >>> >>> 2015-03-27 08:12:45,081 DEBUG [o.a.c.e.o.NetworkOrchestrator] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Implementing >>> the >>> network Ntwk[9f5655bf-3101-45d9-83eb-d9061eadc2bb|Guest|47] elements and >>> resources as a part of network restart >>> >>> 2015-03-27 08:12:45,096 DEBUG [o.a.c.e.o.NetworkOrchestrator] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Asking >>> SecurityGroupProvider to implemenet >>> Ntwk[9f5655bf-3101-45d9-83eb-d9061eadc2bb|Guest|47] >>> >>> 2015-03-27 08:12:45,103 DEBUG [o.a.c.e.o.NetworkOrchestrator] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Asking >>> VirtualRouter to implemenet >>> Ntwk[9f5655bf-3101-45d9-83eb-d9061eadc2bb|Guest|47] >>> >>> 2015-03-27 08:12:45,112 DEBUG >>> [c.c.n.r.VirtualNetworkApplianceManagerImpl] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Lock is >>> acquired >>> for network id 204 as a part of router startup in >>> >>> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] >>> : Dest[Zone(8)-Pod(null)-Cluster(null)-Host(null)-Storage()] >>> >>> 2015-03-27 08:12:45,119 DEBUG >>> [c.c.n.r.VirtualNetworkApplianceManagerImpl] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Skipping VR >>> deployment: Found a running or starting VR in Pod null id=8 >>> >>> 2015-03-27 08:12:45,120 DEBUG >>> [c.c.n.r.VirtualNetworkApplianceManagerImpl] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Lock is >>> released >>> for network id 204 as a part of router startup in >>> >>> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] >>> : Dest[Zone(8)-Pod(null)-Cluster(null)-Host(null)-Storage()] >>> >>> 2015-03-27 08:12:45,123 WARN [o.a.c.e.o.NetworkOrchestrator] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Failed to >>> implement network Ntwk[9f5655bf-3101-45d9-83eb-d9061eadc2bb|Guest|47] >>> elements and resources as a part of network restart due to >>> >>> java.lang.NullPointerException >>> >>> at >>> >>> com.cloud.network.element.VirtualRouterElement.getRouters(VirtualRouterElement.java:952) >>> >>> at >>> >>> com.cloud.network.element.VirtualRouterElement.prepareAggregatedExecution(VirtualRouterElement.java:1099) >>> >>> at >>> >>> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator.java:1090) >>> >>> at >>> >>> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.restartNetwork(NetworkOrchestrator.java:2430) >>> >>> at >>> >>> com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1892) >>> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> at >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:601) >>> >>> at >>> >>> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) >>> >>> at >>> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) >>> >>> at >>> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) >>> >>> at >>> >>> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) >>> >>> at >>> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) >>> >>> at >>> >>> com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) >>> >>> at >>> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) >>> >>> at >>> >>> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) >>> >>> at >>> >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) >>> >>> at >>> >>> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) >>> >>> at $Proxy156.restartNetwork(Unknown Source) >>> >>> at >>> >>> org.apache.cloudstack.api.command.user.network.RestartNetworkCmd.execute(RestartNetworkCmd.java:95) >>> >>> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) >>> >>> at >>> >>> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) >>> >>> at >>> >>> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) >>> >>> at >>> >>> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) >>> >>> at >>> >>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) >>> >>> at >>> >>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) >>> >>> at >>> >>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) >>> >>> at >>> >>> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) >>> >>> at >>> >>> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) >>> >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>> >>> at >>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >>> >>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>> >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>> >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>> >>> at java.lang.Thread.run(Thread.java:722) >>> >>> 2015-03-27 08:12:45,125 WARN [c.c.n.NetworkServiceImpl] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235 ctx-77114e2e) Network id=204 >>> failed to restart. >>> >>> 2015-03-27 08:12:45,140 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235) Complete async job-189235, >>> jobStatus: FAILED, resultCode: 530, >>> >>> result:org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed >>> to restart network"} >>> >>> 2015-03-27 08:12:45,152 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235) Done executing >>> org.apache.cloudstack.api.command.user.network.RestartNetworkCmd for >>> job-189235 >>> >>> 2015-03-27 08:12:45,158 INFO [o.a.c.f.j.i.AsyncJobMonitor] >>> (API-Job-Executor-16:ctx-0b0aa78a job-189235) Remove job-189235 from job >>> monitoring >>> >>> >>> >>> >>> >>> On Thu, Mar 26, 2015 at 7:38 PM, Somesh Naidu <somesh.na...@citrix.com> >>> wrote: >>> >>> You might want to do a arpping on the router's IP from one of the guests >>> and see how many records are returned. >>> >>> Somesh >>> CloudPlatform Escalations >>> Citrix Systems, Inc. >>> >>> -----Original Message----- >>> From: Erik Weber [mailto:terbol...@gmail.com] >>> Sent: Thursday, March 26, 2015 12:54 PM >>> To: users@cloudstack.apache.org >>> Subject: Re: Virtual Routers not responding to dns requests >>> >>> I briefly remember having similar problems at some point, but do not >>> recall >>> details as version nor the solution. >>> >>> 1) Does it work if you restart dnsmasq on the VR? >>> 2) is the VR able to do outgoing dns requests? >>> 3) anything in syslog/dnsmasq logs? >>> 4) any egress rules in place? >>> >>> >>> Erik >>> >>> Den torsdag 26. mars 2015 skrev cs user <acldstk...@gmail.com> følgende: >>> >>> Hi All, >>> >>> We have upgraded from 4.3 to 4.4.2. >>> >>> After some issues with starting the systemvm's, the virtual routers no >>> longer responding to dns requests from the vm's which we start (or >>> existing >>> ones). >>> >>> We have disabled the firewall on the virtual routers and ran tcpdump on >>> them but we can't see any inbound traffic on port 53 (udp or tcp). If we >>> log onto the virtual routers and dig locally against eth0 and the alias >>> on >>> eth0 both of these return fine with the correct IP. >>> >>> This is using Xenserver 6.1 as the host. >>> >>> Has anyone come across this before? dhcp lookups appear to be working >>> fine. >>> Is there a firewall rule in place on the router vm's (other than >>> iptables), >>> similar to the security groups which are applied by Xen, which is >>> preventing these requests from hitting the routers? >>> >>> Many thanks for any help. >>> >>> >>> >>> >> >
