VR under VMware needs to ping all interfaces to kick vSwitch to function
We already ping the VR's private and public network interface.
We change the netwrok security setting to allow promiscuous mode and other two modes on the private cloud
interface for the vSwitch.
Bug 13429 - copy template FAIL - HTTP Server returned 403
lots of things:
1. generate a IP list of all SSVM across all zones, set this IP list to my .htaccess allowable from.
so other SSVMs get privilege to access me.
2. broadcast my IP to other SSVMs instructing them set me to theirs .htacess allowable from. so I get
privilege to access others
3. set outbound route for downloading through public IP. Because public ip/private ip in the same subnet in basic
zone, the http download traffic may come in through public ip but go outside through private ip which finally causes
the VM where the traffic is from to drop response packets. To resolve this, set individual route for each SSVM public
ip making sure the inter-communication between system vm happens through public IP
however, I met certificate expiraton on one SSVM, will report another bug
reviewed-by: Sheng.yang
status 13526: resolved fixed
status 13429: resolved fixed
Summary of changes :
- Added a new flag "-s" to ipassoc command to carry if the ip address is used for SNAT or not.
- SNAT is completly decoupled from the first flag. first flag is used to decide if the ip address is first ip address of the interface.
- -s and -f are independent, SNAT can be enabled on the non-first ip also.
Summary of changes:
- Mutiple routing table for each public interface is added (previously there is only one routing table ). when the packet is send out of public interface corresponding per-interface routing table will be used. per-interface routing table will modified when ever ip/interface added/deleted.
- New parameter is added to ipassoc command to include the default gateway for every interface/ip. prevously it is using only one public interface to send out, default gateway is obtained at the boot up time.
- In the DNAT case. In the revese path(from guest vm to outside, or when DNAT packet receives from the eth0) the public ip/source ip will not be available till POSTROUTING. to overcome this, DNAT connection are marked with routing table number at the time of connection creation, in the reverse path the routing table# from DNAT connection is used to detect per-interface routing table.