Added global config to enable/disable rp_filter for domR.
previous commit: d966906374d4a0cb8fa57326a1f7625c871f64fd
Test Case-1 :
1) Set network.disable.rpfilter global config to true
2) Restart the domR
3) check the settings reflected in proc filesystem
- for public interface like eth2,eth3 : /proc/sys/net/ipv4/conf/eth2/rp_filter should have 0 , and rest other interfaces should have value of 1
Test Case-2 :
1) set network.disable.rpfilter global config to false
2) Restart the domR
3) check the settings reflected in proc filesystem
- for public interface like eth2,eth3 : /proc/sys/net/ipv4/conf/eth2/rp_filter should have 1 , and rest other interfaces should also have value of 1
It's very like caused by StartRouterCmd sent to the running router. I can
reproduce it by issue a StartRouterCmd to a running redundant router. And this
patch should the following exception:
Exception: com.cloud.exception.ResourceUnavailableException: Resource
[VirtualNetworkApplianceManagerImpl$$EnhancerByCGLIB$$565b4d45:0] is
unreachable: There are already two redundant routers with IP 10.91.32.126, they
are r-5-VM(5) and r-4-VM(4)
status 11214: resolved fixed
1) On enableStaticNat command we actually send the command to the backend (we used to just upgrade the DB in the past). The backend command carries sourceIp and destIp, and creates IP to IP mapping on the domR.
2) On disableStaticNat for the Ip address in addition to cleaning up port ranges, we also delete IP to IP mapping on the domR.
1) Added new apis: createFirewallRule, deleteFirewallRule, listFirewallRules
2) Modified existing apis - added boolean openFirewall parameter to createPortForwardingRule/createIpForwardingRule/createRemoteAccessVpn. If parameter is set to true, open firewall on the domR before creating an actual PF rule there
Modified backend calls appropriately.
3) Schema changes for firewall_rules table:
* startPort/endPort can be null now
* added icmp_type, icmp_code fields (can be not null only when protocol is icmp)
4) Added new manager - FirewallManagerImpl
status 10869: resolved fixed
Here is the flow (design is approved by Will Chan):
1) If user specifies custom ip address, and this ip is not the first ip in the range, the dhcp server gets the ip.
2) If user specifies custom ip address, and this ip is the first ip in the range, the dhcp server will get the random ip address from the range.
2) If user doesn't specify custom ip address, we always try to allocate first ip address from the range for the dhcp server; if this ip is already allocated, the dhcp server will get the random ip from the range.
This will work for:
* domR's Guest network
* dhcp's Direct network
alena
Naredula Janardhana Reddy
Sheng Yang
Abhinandan Prateek
Chiradeep Vittal
keshav