cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From remibergsma <...@git.apache.org>
Subject [GitHub] cloudstack pull request: [BLOCKER] Combined PRs that fix VR issues
Date Thu, 24 Sep 2015 22:26:51 GMT
GitHub user remibergsma opened a pull request:

    https://github.com/apache/cloudstack/pull/887

    [BLOCKER] Combined PRs that fix VR issues

    Tonight I worked with @wilderrodrigues to figure out what is wrong with the virtual router.
As we couldn't test single PRs any more (because of other issues with them causing tests to
fail) we added all VR related PRs in a separate branch and started testing from there.
    
    We combined the following PRs into this PR:
    #836 #851 #867 #870 #881 #882 #842
    
    After that, one issue remains: the VPC does not get a default gateway. Which is strange,
because we already solved it in PR #738. When I look back, it was fixed again in PR #784.
It could very well be that either one fixed one specific case, but also breaking the other.
We need to investigate this, and make sure there will be a fix that works both for VPCs and
VRs.
    
    When we manually add the default gateway on the VPC, most tests pass and also spinning
up two VPCs with one tier each, having a VM and them using s2s to VPN them together works
fine. See for more details the report Wilder sent earlier.
    
    Tomorrow we'll try to figure out how to fix the default gateway and merge this. Then we
should have a base to work from again. Any PR that fixes another blocker, should at least
then be rebased against the fixed master so we can run the tests against the PR branch. I'm
not saying everything is fixed, I'm just saying that we can spin up a cloud that has working
VMs.
    
    When, in the mean time, someone has the time to checkout this branch and make the default
route work for both VPC and VR that would be awesome. After that we should double check and
verify the test results. 
    
    Pinging @karuturi to let her know the current status.
    
    Regards,
    Wilder / Remi

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/schubergphilis/cloudstack vr_fixes_combined

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/cloudstack/pull/887.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #887
    
----
commit a15df0569fa0e56b14a9a119858c53e8ae6085c3
Author: Jayapal <jayapal@apache.org>
Date:   2015-09-16T09:52:33Z

    CLOUDSTACK-8843: Fixed issue in default iptables rules on shared network VR

commit 56d4429500d0d3da7334b3f1c559d1eca8ee85a4
Author: SudharmaJain <sudharma.jain@citrix.com>
Date:   2015-09-16T09:10:31Z

    CLOUDSTACK-8863: VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE

commit 96c38bf491d81e41975dddbfc3c87716293c7bdf
Author: SudharmaJain <sudharma.jain@citrix.com>
Date:   2015-09-19T18:10:21Z

    CLOUDSTACK-8864: Not able to add TCP port forwarding rule in VPN for specific ports

commit dbedfe2557839332c394c44deb6c376f386681d9
Author: Jayapal <jayapal@apache.org>
Date:   2015-09-17T06:04:27Z

    Configured dnsmasq to listen on all interfaces so that vpn  client gets dns

commit 746a5dc48e01cc07cbd4b319755d45e414c49504
Author: Jayapal <jayapal@apache.org>
Date:   2015-09-24T07:14:15Z

    CLOUDSTACK-8891: Fixed default iptables rules on VR  for guest traffic

commit 2bf7fb4b63932d80f641462073c751f07ab0c3ea
Author: Jayapal <jayapal@apache.org>
Date:   2015-09-24T11:36:11Z

    CLOUDSTACK-8905: Fixed hooking egress rules

commit 40138d2e994458250b8db706be993d4b040f95ca
Author: Jayapal <jayapal@apache.org>
Date:   2015-09-24T11:52:29Z

    CLOUDSTACK-8881: Fixed Static and PF configuration issue

commit 8367911ef7f502eb760ca57d0a018d96620fdbed
Author: Remi Bergsma <github@remi.nl>
Date:   2015-09-24T13:35:00Z

    Merge pull request #836 from SudharmaJain/cs-8863
    
    CLOUDSTACK-8863: VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE
    
    The ongoing ICMP request reply session is broken when the VR is down, the expectation
is that it would resume once the VR is up. Investigations revealed that the ongoing ICMP packets
are sent out of eth2 without being NATed post VR stop/start or restart or recreate.
    
    TCPDUMP output from VR post restart/stop-start/recreate on eth2:
    
    root@r-4-VM:~# tcpdump -i eth2 icmp -n -vvv
    tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
    06:22:52.749770 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length
84)
        192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 81, length 64
    06:22:53.749782 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length
84)
        192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 82, length 64
    06:22:54.749771 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length
84)
        192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 83, length 64
    06:22:55.749775 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length
84)
        192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 84, length 64
    06:22:56.749765 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length
84)
        192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 85, length 64
    06:22:57.749776 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length
84)
        192.168.200.67 > 173.194.33.163: ICMP echo request, id 30996, seq 86, length 64
    ^C
    6 packets captured
    6 packets received by filter
    0 packets dropped by kernel
    root@r-4-VM:~#
    root@r-4-VM:~# grep icmp /proc/net/ip_conntrack
    icmp     1 29 src=192.168.200.67 dst=173.194.33.163 type=8 code=0 id=30996 [UNREPLIED]
src=173.194.33.163 dst=192.168.200.67 type=0 code=0 id=30996 mark=0 use=2
    
    This get fixed after flushing the conntrack table.
    
    Screenshots:
    
    Before fix (ping session doesn't resume, stop and starting the ping works, 120 packets
lost):
    ![image](https://cloud.githubusercontent.com/assets/12229259/9897800/4de7488e-5c6a-11e5-98eb-3bd79cc3a8b1.png)
    
    After fix(ping session resumes, 27 packets lost):
    ![image](https://cloud.githubusercontent.com/assets/12229259/9897822/9112e866-5c6a-11e5-95b3-1b20600d2e44.png)
    
    * pr/836:
      CLOUDSTACK-8863: VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE
    
    Signed-off-by: Remi Bergsma <github@remi.nl>

commit 7d5555429b90fcb9e1456ea858d5163b41ee41ab
Author: Remi Bergsma <github@remi.nl>
Date:   2015-09-24T13:35:16Z

    Merge pull request #851 from SudharmaJain/cs-8864
    
    CLOUDSTACK-8864: Not able to add TCP port forwarding rule in VPN for specific ports
    
    Setting port forwarding rules for port 500,1701 and 4500 after enabling VPN, gives the
error message "The range specified, xxxx, conflicts with rule xxxx which has xxxx." This happens
because the rules added for vpn doesn't have a matching condition to allow port forwarding
rules.
    
    Added a unit test to verify the detectRulesConflict function of FirewallManagerImpl.
    
    * pr/851:
      CLOUDSTACK-8864: Not able to add TCP port forwarding rule in VPN for specific ports
    
    Signed-off-by: Remi Bergsma <github@remi.nl>

commit a5a5f612ea4fbdb37b6dc5c708fd042b00902f84
Author: Remi Bergsma <github@remi.nl>
Date:   2015-09-24T13:35:33Z

    Merge pull request #867 from jayapalu/CLOUDSTACK-8891
    
    CLOUDSTACK-8891: Fixed default iptables rules on VR  for guest trafficVR default iptables
rules in INPUT chain are configured partially.
    In CsAddress.py rules are configured while configuring public interface, guest interface
post configuration is missed. Fixed to configure guest post configuration so that iptables
rules are configured.
    
    Testing:
    1. Deployed vm in the network.
    2.iptables rules on the VR configured correctly.
    3.VM got the dhcp ip address from the VR.
    
    * pr/867:
      CLOUDSTACK-8891: Fixed default iptables rules on VR  for guest traffic
    
    Signed-off-by: Remi Bergsma <github@remi.nl>

commit 4018d47ef8ea3be780f27d6558275f19b70e5ef0
Author: Remi Bergsma <github@remi.nl>
Date:   2015-09-24T13:35:48Z

    Merge pull request #870 from jayapalu/CLOUDSTACK-8874
    
    Configured dnsmasq to listen on all interfaces so that vpn  client gets dns1. Dnsmasq
is not listening on the ppp+ interfaces due to this remote access vpn clients dns requests
are  dropped.
    
    2. Configured the dnsmasq to listen on all the interfaces except public. There is firewall
to allow only specific cidr to allow the dns requests.
    
    Tested from windows client nslookup.
    
    * pr/870:
      Configured dnsmasq to listen on all interfaces so that vpn  client gets dns
    
    Signed-off-by: Remi Bergsma <github@remi.nl>

commit 649a4bdc7633298ceba39d30857d147f17952a84
Author: Remi Bergsma <github@remi.nl>
Date:   2015-09-24T13:36:03Z

    Merge pull request #881 from jayapalu/CLOUDSTACK-8905
    
    CLOUDSTACK-8905: Fixed hooking egress rulesAdded hooking the FIREWALL_EGRESS_RULES chain
into FW_OUTBOUND chain.
    With this egress rules will effective.
    
    * pr/881:
      CLOUDSTACK-8905: Fixed hooking egress rules
    
    Signed-off-by: Remi Bergsma <github@remi.nl>

commit 4420f48e3e0378c440806fad0a2dcebaaa17b511
Author: Remi Bergsma <github@remi.nl>
Date:   2015-09-24T13:36:18Z

    Merge pull request #882 from jayapalu/CLOUDSTACK-8881
    
    CLOUDSTACK-8881: Fixed Static and PF configuration issue1. For static nat filter rules
are not configured in VR.
    2. Corrected vm ip in PF rule.
    
    * pr/882:
      CLOUDSTACK-8881: Fixed Static and PF configuration issue
    
    Signed-off-by: Remi Bergsma <github@remi.nl>

commit 4c8f4ac3417f60962abfc2cb0f1439bb78a44d4d
Author: Remi Bergsma <github@remi.nl>
Date:   2015-09-24T14:42:41Z

    Merge pull request #842 from jayapalu/shareNwVR
    
    CLOUDSTACK-8843: Fixed issue in default iptables rules on shared network VROn basic zone
share network VR default iptables rules are not applied correctly. Due to this ssh to VR got
failed.
    In shared network the VR type is 'dhcpsrvr' not router. So corrected it in the ''del_standard'
method to select the correct type.
    
    Testing:
    1. VR is deployed correctly.
    2. Tested restart, stop, start VR.
    3. New VM deployment is success.
    4. ssh to VR from the host is successful.
    5. iptables rules on the VR came up correctly.
    below is the output from the VR:
    iptables -L INPUT -nv
    Chain INPUT (policy DROP 16 packets, 1056 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            224.0.0.18
        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            225.0.0.50
      104  9800 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0        
   state RELATED,ESTABLISHED
      281 36500 ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0        
   state RELATED,ESTABLISHED
        0     0 ACCEPT     all  --  eth2   *       0.0.0.0/0            0.0.0.0/0        
   state RELATED,ESTABLISHED
        6   504 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
        2   656 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0        
   udp dpt:67
       13   780 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0        
   tcp dpt:3922 state NEW,ESTABLISHED
        0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0        
   tcp dpt:80 state NEW
        0     0 ACCEPT     tcp  --  eth0   *       10.147.40.0/23       0.0.0.0/0        
   state NEW tcp dpt:8080
    
    * pr/842:
      CLOUDSTACK-8843: Fixed issue in default iptables rules on shared network VR
    
    Signed-off-by: Remi Bergsma <github@remi.nl>

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message