You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by je...@gmail.com on 2019/07/09 14:26:44 UTC
DHCP instance/vm issue
Have a DHCP issue where vm pulls from ACS proxy properly sometimes and
other when it pulls from our normal dhcp server for end-points.
Network layout is flat, and I ACS is using basic network with security
groups. IP range for acs is within range of our normal network so vms and
endpoints will flow without additional hardware. How do I ensure dhcp
requests are served by router vm and not our normal dhcp server?
TIA,
Jesse
Re: DHCP instance/vm issue
Posted by Yiping Zhang <yi...@adobe.com.INVALID>.
Jesse:
As Andrija said, this is a purely DHCP issue, has nothing to do with the CloudStack.
We have a similar set up here , where both ACS VM instances and non-ACS servers exist on the same subnet, and they are served by separated DHCP servers (stock ISC dhcp server on RHEL). Here is how we solved the conflict.
For non-ACS DHCP server, In dhcpd.conf, we define a class for Cloudstack instances based on their MAC address. Then in the pool stanza for each subnet served by this (non ACS) DHCP server , just ignore members of cloustack class.
Here are the relevant snippets in dhcpd.conf:
class "Cloudstack" {
match if substring(hardware,1,1) = 06;
}
...
# Prod_DMZ_subnet
subnet 10.0.8.0 netmask 255.255.252.0 {
pool {
deny members of "Cloudstack";
...
}
...
}
In earlier versions of ACS, all VM's MAC address start with "06:". I think in current version of ACS, they start with "1e:" now.
Hope this helps.
Yiping
On 7/9/19, 9:44 AM, "jesse.waters@gmail.com" <je...@gmail.com> wrote:
Interesting
proxy in to vm
pkill dhclient
dhclient -x
dhclient eth0
get ip I expected, odd
On Tue, Jul 9, 2019 at 11:16 AM <je...@gmail.com> wrote:
>
> My vm was assigned an ip from our endpoint DHCP server, not from VR. Do I
> need to add firewall rule(s) to force DHCP request to VR? I probably missed
> a part of setup w/KVM hosts and or within management when I defined the
> zone/pod/...
>
> This seems to be correct, VR is running on a different host then the vm.
>
> Chain i-2-11-VM-eg (1 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 RETURN all -- * * 0.0.0.0/0
> 0.0.0.0/0
>
> Chain i-2-11-def (2 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all -- * * 0.0.0.0/0
> 0.0.0.0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged udp spt:68 dpt:67
> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> --physdev-is-bridged udp spt:67 dpt:68
> 0 0 DROP all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged ! match-set i-2-11-VM src
> 0 0 RETURN udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged match-set i-2-11-VM src udp dpt:53
> 0 0 RETURN tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged match-set i-2-11-VM src tcp dpt:53
> 0 0 i-2-11-VM-eg all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged match-set i-2-11-VM src
> 15 1963 i-2-11-VM all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> --physdev-is-bridged
>
>
>
> Thanks for quick response Andrija!
>
> - Jesse
>
>
>
>
> On Tue, Jul 9, 2019 at 10:39 AM Andrija Panic <an...@gmail.com>
> wrote:
>
>> ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If you
>> have another DHCP server in your area, than it might be quicker to offer a
>> lease to a VM. You have to either remove your non-ACS DHCP server
>> completely, OR make sure it uses reservation for non-ACS servers/hosts
>> i.e.
>> NOT let it issue leases freely to anyone who asks for it. Pure DHCP
>> "problem" - i.e. nothing to do with ACS specifically.
>>
>> Best,
>> Andrija
>>
>> On Tue, Jul 9, 2019, 20:27 <je...@gmail.com> wrote:
>>
>> > Have a DHCP issue where vm pulls from ACS proxy properly sometimes and
>> > other when it pulls from our normal dhcp server for end-points.
>> >
>> > Network layout is flat, and I ACS is using basic network with security
>> > groups. IP range for acs is within range of our normal network so vms
>> and
>> > endpoints will flow without additional hardware. How do I ensure dhcp
>> > requests are served by router vm and not our normal dhcp server?
>> >
>> > TIA,
>> > Jesse
>> >
>>
>
Re: DHCP instance/vm issue
Posted by je...@gmail.com.
Interesting
proxy in to vm
pkill dhclient
dhclient -x
dhclient eth0
get ip I expected, odd
On Tue, Jul 9, 2019 at 11:16 AM <je...@gmail.com> wrote:
>
> My vm was assigned an ip from our endpoint DHCP server, not from VR. Do I
> need to add firewall rule(s) to force DHCP request to VR? I probably missed
> a part of setup w/KVM hosts and or within management when I defined the
> zone/pod/...
>
> This seems to be correct, VR is running on a different host then the vm.
>
> Chain i-2-11-VM-eg (1 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 RETURN all -- * * 0.0.0.0/0
> 0.0.0.0/0
>
> Chain i-2-11-def (2 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all -- * * 0.0.0.0/0
> 0.0.0.0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged udp spt:68 dpt:67
> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> --physdev-is-bridged udp spt:67 dpt:68
> 0 0 DROP all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged ! match-set i-2-11-VM src
> 0 0 RETURN udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged match-set i-2-11-VM src udp dpt:53
> 0 0 RETURN tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged match-set i-2-11-VM src tcp dpt:53
> 0 0 i-2-11-VM-eg all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> --physdev-is-bridged match-set i-2-11-VM src
> 15 1963 i-2-11-VM all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> --physdev-is-bridged
>
>
>
> Thanks for quick response Andrija!
>
> - Jesse
>
>
>
>
> On Tue, Jul 9, 2019 at 10:39 AM Andrija Panic <an...@gmail.com>
> wrote:
>
>> ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If you
>> have another DHCP server in your area, than it might be quicker to offer a
>> lease to a VM. You have to either remove your non-ACS DHCP server
>> completely, OR make sure it uses reservation for non-ACS servers/hosts
>> i.e.
>> NOT let it issue leases freely to anyone who asks for it. Pure DHCP
>> "problem" - i.e. nothing to do with ACS specifically.
>>
>> Best,
>> Andrija
>>
>> On Tue, Jul 9, 2019, 20:27 <je...@gmail.com> wrote:
>>
>> > Have a DHCP issue where vm pulls from ACS proxy properly sometimes and
>> > other when it pulls from our normal dhcp server for end-points.
>> >
>> > Network layout is flat, and I ACS is using basic network with security
>> > groups. IP range for acs is within range of our normal network so vms
>> and
>> > endpoints will flow without additional hardware. How do I ensure dhcp
>> > requests are served by router vm and not our normal dhcp server?
>> >
>> > TIA,
>> > Jesse
>> >
>>
>
Re: DHCP instance/vm issue
Posted by je...@gmail.com.
Yes race condition exists, I have been fortunate it hasn't been seen
outside of ACS environment so far.From a network topology, Ideally I should
isolate and route traffic to the Pod and use a firewall or other gateway to
control traffic.
I'll need to re-think my deployment and see if I need additional resources
On Tue, Jul 9, 2019 at 12:52 PM Andrija Panic <an...@gmail.com>
wrote:
> Don't kill dhcp client (don't force renew of IP), since again it will NOT
> work if you repeat that a few times - a VM will broadcast dhcp discover
> messages, all DHCP server will receive it and all DHCP servers will offer a
> lease/ip to your VMs - the one DHCP server to be "quicker" to send its dhcp
> offer, will "win" and VM will get its IP... you have "race condition" in
> any network with more than 1 DHCP server... It's a "wrong" setup
> effectively.
>
> Cheers
>
> On Tue, Jul 9, 2019, 22:47 Andrija Panic <an...@gmail.com> wrote:
>
> > Jesse,
> >
> > You can experiment with firewall rules/SG, but in general you should not
> > have more than 1 DHCP server in a single network. I assume your VMs would
> > be assigned one part of the net/subnet, while your external DHCP server
> > should be serving your non-ACS infra - i.e. if your acs network for VMs
> is
> > 192.168.1.1-128, while 192.168.1.129-254(non-ACS infra) should be served
> by
> > your external DHCP, then I would think of blocking dhcp ports (dhcp
> > discover) from whole 192.168.1.1-128 network on your external DHCP
> server -
> > i.e. this way your external DHCP SERVER would be "deaf" to all dhcp
> > discover messages sent from ACS VMs to itself and thus would not issue
> > leases to ACS VMs.
> >
> > Hope that makes sense.
> >
> > Best
> > Andrija
> >
> > On Tue, Jul 9, 2019, 21:16 <je...@gmail.com> wrote:
> >
> >> My vm was assigned an ip from our endpoint DHCP server, not from VR. Do
> I
> >> need to add firewall rule(s) to force DHCP request to VR? I probably
> >> missed
> >> a part of setup w/KVM hosts and or within management when I defined the
> >> zone/pod/...
> >>
> >> This seems to be correct, VR is running on a different host then the vm.
> >>
> >> Chain i-2-11-VM-eg (1 references)
> >> pkts bytes target prot opt in out source
> >> destination
> >> 0 0 RETURN all -- * * 0.0.0.0/0
> >> 0.0.0.0/0
> >>
> >> Chain i-2-11-def (2 references)
> >> pkts bytes target prot opt in out source
> >> destination
> >> 0 0 ACCEPT all -- * * 0.0.0.0/0
> >> 0.0.0.0/0 state RELATED,ESTABLISHED
> >> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> >> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> >> --physdev-is-bridged
> >> udp spt:68 dpt:67
> >> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> >> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> >> --physdev-is-bridged
> >> udp spt:67 dpt:68
> >> 0 0 DROP all -- * * 0.0.0.0/0
> >> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> >> --physdev-is-bridged
> >> ! match-set i-2-11-VM src
> >> 0 0 RETURN udp -- * * 0.0.0.0/0
> >> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> >> --physdev-is-bridged
> >> match-set i-2-11-VM src udp dpt:53
> >> 0 0 RETURN tcp -- * * 0.0.0.0/0
> >> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> >> --physdev-is-bridged
> >> match-set i-2-11-VM src tcp dpt:53
> >> 0 0 i-2-11-VM-eg all -- * * 0.0.0.0/0
> >> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
> >> --physdev-is-bridged
> >> match-set i-2-11-VM src
> >> 15 1963 i-2-11-VM all -- * * 0.0.0.0/0
> >> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> >> --physdev-is-bridged
> >>
> >>
> >>
> >> Thanks for quick response Andrija!
> >>
> >> - Jesse
> >>
> >>
> >>
> >>
> >> On Tue, Jul 9, 2019 at 10:39 AM Andrija Panic <an...@gmail.com>
> >> wrote:
> >>
> >> > ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If
> >> you
> >> > have another DHCP server in your area, than it might be quicker to
> >> offer a
> >> > lease to a VM. You have to either remove your non-ACS DHCP server
> >> > completely, OR make sure it uses reservation for non-ACS servers/hosts
> >> i.e.
> >> > NOT let it issue leases freely to anyone who asks for it. Pure DHCP
> >> > "problem" - i.e. nothing to do with ACS specifically.
> >> >
> >> > Best,
> >> > Andrija
> >> >
> >> > On Tue, Jul 9, 2019, 20:27 <je...@gmail.com> wrote:
> >> >
> >> > > Have a DHCP issue where vm pulls from ACS proxy properly sometimes
> and
> >> > > other when it pulls from our normal dhcp server for end-points.
> >> > >
> >> > > Network layout is flat, and I ACS is using basic network with
> security
> >> > > groups. IP range for acs is within range of our normal network so
> vms
> >> > and
> >> > > endpoints will flow without additional hardware. How do I ensure
> dhcp
> >> > > requests are served by router vm and not our normal dhcp server?
> >> > >
> >> > > TIA,
> >> > > Jesse
> >> > >
> >> >
> >>
> >
>
Re: DHCP instance/vm issue
Posted by Andrija Panic <an...@gmail.com>.
Don't kill dhcp client (don't force renew of IP), since again it will NOT
work if you repeat that a few times - a VM will broadcast dhcp discover
messages, all DHCP server will receive it and all DHCP servers will offer a
lease/ip to your VMs - the one DHCP server to be "quicker" to send its dhcp
offer, will "win" and VM will get its IP... you have "race condition" in
any network with more than 1 DHCP server... It's a "wrong" setup
effectively.
Cheers
On Tue, Jul 9, 2019, 22:47 Andrija Panic <an...@gmail.com> wrote:
> Jesse,
>
> You can experiment with firewall rules/SG, but in general you should not
> have more than 1 DHCP server in a single network. I assume your VMs would
> be assigned one part of the net/subnet, while your external DHCP server
> should be serving your non-ACS infra - i.e. if your acs network for VMs is
> 192.168.1.1-128, while 192.168.1.129-254(non-ACS infra) should be served by
> your external DHCP, then I would think of blocking dhcp ports (dhcp
> discover) from whole 192.168.1.1-128 network on your external DHCP server -
> i.e. this way your external DHCP SERVER would be "deaf" to all dhcp
> discover messages sent from ACS VMs to itself and thus would not issue
> leases to ACS VMs.
>
> Hope that makes sense.
>
> Best
> Andrija
>
> On Tue, Jul 9, 2019, 21:16 <je...@gmail.com> wrote:
>
>> My vm was assigned an ip from our endpoint DHCP server, not from VR. Do I
>> need to add firewall rule(s) to force DHCP request to VR? I probably
>> missed
>> a part of setup w/KVM hosts and or within management when I defined the
>> zone/pod/...
>>
>> This seems to be correct, VR is running on a different host then the vm.
>>
>> Chain i-2-11-VM-eg (1 references)
>> pkts bytes target prot opt in out source
>> destination
>> 0 0 RETURN all -- * * 0.0.0.0/0
>> 0.0.0.0/0
>>
>> Chain i-2-11-def (2 references)
>> pkts bytes target prot opt in out source
>> destination
>> 0 0 ACCEPT all -- * * 0.0.0.0/0
>> 0.0.0.0/0 state RELATED,ESTABLISHED
>> 0 0 ACCEPT udp -- * * 0.0.0.0/0
>> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
>> --physdev-is-bridged
>> udp spt:68 dpt:67
>> 0 0 ACCEPT udp -- * * 0.0.0.0/0
>> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
>> --physdev-is-bridged
>> udp spt:67 dpt:68
>> 0 0 DROP all -- * * 0.0.0.0/0
>> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
>> --physdev-is-bridged
>> ! match-set i-2-11-VM src
>> 0 0 RETURN udp -- * * 0.0.0.0/0
>> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
>> --physdev-is-bridged
>> match-set i-2-11-VM src udp dpt:53
>> 0 0 RETURN tcp -- * * 0.0.0.0/0
>> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
>> --physdev-is-bridged
>> match-set i-2-11-VM src tcp dpt:53
>> 0 0 i-2-11-VM-eg all -- * * 0.0.0.0/0
>> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
>> --physdev-is-bridged
>> match-set i-2-11-VM src
>> 15 1963 i-2-11-VM all -- * * 0.0.0.0/0
>> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
>> --physdev-is-bridged
>>
>>
>>
>> Thanks for quick response Andrija!
>>
>> - Jesse
>>
>>
>>
>>
>> On Tue, Jul 9, 2019 at 10:39 AM Andrija Panic <an...@gmail.com>
>> wrote:
>>
>> > ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If
>> you
>> > have another DHCP server in your area, than it might be quicker to
>> offer a
>> > lease to a VM. You have to either remove your non-ACS DHCP server
>> > completely, OR make sure it uses reservation for non-ACS servers/hosts
>> i.e.
>> > NOT let it issue leases freely to anyone who asks for it. Pure DHCP
>> > "problem" - i.e. nothing to do with ACS specifically.
>> >
>> > Best,
>> > Andrija
>> >
>> > On Tue, Jul 9, 2019, 20:27 <je...@gmail.com> wrote:
>> >
>> > > Have a DHCP issue where vm pulls from ACS proxy properly sometimes and
>> > > other when it pulls from our normal dhcp server for end-points.
>> > >
>> > > Network layout is flat, and I ACS is using basic network with security
>> > > groups. IP range for acs is within range of our normal network so vms
>> > and
>> > > endpoints will flow without additional hardware. How do I ensure dhcp
>> > > requests are served by router vm and not our normal dhcp server?
>> > >
>> > > TIA,
>> > > Jesse
>> > >
>> >
>>
>
Re: DHCP instance/vm issue
Posted by Andrija Panic <an...@gmail.com>.
Jesse,
You can experiment with firewall rules/SG, but in general you should not
have more than 1 DHCP server in a single network. I assume your VMs would
be assigned one part of the net/subnet, while your external DHCP server
should be serving your non-ACS infra - i.e. if your acs network for VMs is
192.168.1.1-128, while 192.168.1.129-254(non-ACS infra) should be served by
your external DHCP, then I would think of blocking dhcp ports (dhcp
discover) from whole 192.168.1.1-128 network on your external DHCP server -
i.e. this way your external DHCP SERVER would be "deaf" to all dhcp
discover messages sent from ACS VMs to itself and thus would not issue
leases to ACS VMs.
Hope that makes sense.
Best
Andrija
On Tue, Jul 9, 2019, 21:16 <je...@gmail.com> wrote:
> My vm was assigned an ip from our endpoint DHCP server, not from VR. Do I
> need to add firewall rule(s) to force DHCP request to VR? I probably missed
> a part of setup w/KVM hosts and or within management when I defined the
> zone/pod/...
>
> This seems to be correct, VR is running on a different host then the vm.
>
> Chain i-2-11-VM-eg (1 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 RETURN all -- * * 0.0.0.0/0
> 0.0.0.0/0
>
> Chain i-2-11-def (2 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all -- * * 0.0.0.0/0
> 0.0.0.0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
> udp spt:68 dpt:67
> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> --physdev-is-bridged
> udp spt:67 dpt:68
> 0 0 DROP all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
> ! match-set i-2-11-VM src
> 0 0 RETURN udp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
> match-set i-2-11-VM src udp dpt:53
> 0 0 RETURN tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
> match-set i-2-11-VM src tcp dpt:53
> 0 0 i-2-11-VM-eg all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
> match-set i-2-11-VM src
> 15 1963 i-2-11-VM all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-out vnet0
> --physdev-is-bridged
>
>
>
> Thanks for quick response Andrija!
>
> - Jesse
>
>
>
>
> On Tue, Jul 9, 2019 at 10:39 AM Andrija Panic <an...@gmail.com>
> wrote:
>
> > ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If you
> > have another DHCP server in your area, than it might be quicker to offer
> a
> > lease to a VM. You have to either remove your non-ACS DHCP server
> > completely, OR make sure it uses reservation for non-ACS servers/hosts
> i.e.
> > NOT let it issue leases freely to anyone who asks for it. Pure DHCP
> > "problem" - i.e. nothing to do with ACS specifically.
> >
> > Best,
> > Andrija
> >
> > On Tue, Jul 9, 2019, 20:27 <je...@gmail.com> wrote:
> >
> > > Have a DHCP issue where vm pulls from ACS proxy properly sometimes and
> > > other when it pulls from our normal dhcp server for end-points.
> > >
> > > Network layout is flat, and I ACS is using basic network with security
> > > groups. IP range for acs is within range of our normal network so vms
> > and
> > > endpoints will flow without additional hardware. How do I ensure dhcp
> > > requests are served by router vm and not our normal dhcp server?
> > >
> > > TIA,
> > > Jesse
> > >
> >
>
Re: DHCP instance/vm issue
Posted by je...@gmail.com.
My vm was assigned an ip from our endpoint DHCP server, not from VR. Do I
need to add firewall rule(s) to force DHCP request to VR? I probably missed
a part of setup w/KVM hosts and or within management when I defined the
zone/pod/...
This seems to be correct, VR is running on a different host then the vm.
Chain i-2-11-VM-eg (1 references)
pkts bytes target prot opt in out source
destination
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0
Chain i-2-11-def (2 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
udp spt:68 dpt:67
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-out vnet0 --physdev-is-bridged
udp spt:67 dpt:68
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
! match-set i-2-11-VM src
0 0 RETURN udp -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
match-set i-2-11-VM src udp dpt:53
0 0 RETURN tcp -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
match-set i-2-11-VM src tcp dpt:53
0 0 i-2-11-VM-eg all -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in vnet0 --physdev-is-bridged
match-set i-2-11-VM src
15 1963 i-2-11-VM all -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-out vnet0 --physdev-is-bridged
Thanks for quick response Andrija!
- Jesse
On Tue, Jul 9, 2019 at 10:39 AM Andrija Panic <an...@gmail.com>
wrote:
> ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If you
> have another DHCP server in your area, than it might be quicker to offer a
> lease to a VM. You have to either remove your non-ACS DHCP server
> completely, OR make sure it uses reservation for non-ACS servers/hosts i.e.
> NOT let it issue leases freely to anyone who asks for it. Pure DHCP
> "problem" - i.e. nothing to do with ACS specifically.
>
> Best,
> Andrija
>
> On Tue, Jul 9, 2019, 20:27 <je...@gmail.com> wrote:
>
> > Have a DHCP issue where vm pulls from ACS proxy properly sometimes and
> > other when it pulls from our normal dhcp server for end-points.
> >
> > Network layout is flat, and I ACS is using basic network with security
> > groups. IP range for acs is within range of our normal network so vms
> and
> > endpoints will flow without additional hardware. How do I ensure dhcp
> > requests are served by router vm and not our normal dhcp server?
> >
> > TIA,
> > Jesse
> >
>
Re: DHCP instance/vm issue
Posted by Andrija Panic <an...@gmail.com>.
ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If you
have another DHCP server in your area, than it might be quicker to offer a
lease to a VM. You have to either remove your non-ACS DHCP server
completely, OR make sure it uses reservation for non-ACS servers/hosts i.e.
NOT let it issue leases freely to anyone who asks for it. Pure DHCP
"problem" - i.e. nothing to do with ACS specifically.
Best,
Andrija
On Tue, Jul 9, 2019, 20:27 <je...@gmail.com> wrote:
> Have a DHCP issue where vm pulls from ACS proxy properly sometimes and
> other when it pulls from our normal dhcp server for end-points.
>
> Network layout is flat, and I ACS is using basic network with security
> groups. IP range for acs is within range of our normal network so vms and
> endpoints will flow without additional hardware. How do I ensure dhcp
> requests are served by router vm and not our normal dhcp server?
>
> TIA,
> Jesse
>