cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces
Date Wed, 07 Dec 2016 18:36:59 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729511#comment-15729511
] 

ASF subversion and git services commented on CLOUDSTACK-9339:
-------------------------------------------------------------

Commit 2e5373b7f8903494ab91308771dc89e463a5a6d4 in cloudstack's branch refs/heads/master from
[~rohit.yadav@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2e5373b ]

Merge pull request #1659 from murali-reddy/multiple_public_ip_ranges_non_vpc

CLOUDSTACK-9339 Virtual Routers don't handle Multiple Public Interfaces correctlyAs pointed
out in CLOUDSTACK-9339, in case of multiple public IP's from different public IP ranges are
associated with VR, VR functionality is broken from 4.6. Below are the brief list of problems
specific to non-VPC networks addressed in the PR. This PR handles both VPC and non-VPC scenarios.
- reverse traffic for the connections accepted on the eth3 and above public interfaces are
getting blocked. Need a rule for e.g "-A FORWARD -i  eth3 -o eth0 -m state --state RELATED,ESTABLISHED
-j ACCEPT" in the FORWARD chain of filter table to permit reverse path traffic for established
connections.
- outbound public traffic from eth0 to eth3 (or for interfaces above like eth4 eth5 etc) needs
rule to run through FW_OUTBOUND chain in the filter table
- network stats on public interfaces eth3 are getting gathered
- default gateway is missing in the device specific routing table, resulting in traffic to
be looked up in main routing table
- creating a device specific route table is generating "from all lookup Table_eth3" in the
  ip rules, resulting in rest of the traffic getting blocked.

Picked few commits from #1519 from dsclose (https://github.com/apache/cloudstack/pull/1519)
submitted for 4.7

Marvin tests are added to test below
- Static NAT works on the public interfaces above eth2, in case non-vpc networks
- Portforwarding works on the public interfaces above eth2, in case non-vpc networks
- Route tables are configured as expected for the device specific table for the public interfaces
above eth2, in case non-vpc networks
- IP tables rules are as expected for the traffic from and to the public interfaces above
eth2, in case non-vpc networks

* pr/1659:
  CLOUDSTACK-9339 Virtual Routers don't handle Multiple Public Interfaces correctly

Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>


> Virtual Routers don't handle Multiple Public Interfaces
> -------------------------------------------------------
>
>                 Key: CLOUDSTACK-9339
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.8.0
>            Reporter: dsclose
>            Assignee: Murali Reddy
>              Labels: firewall, nat, router
>             Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple public interfaces.
These are more pronounced on redundant virtual router setups. I have not attempted to examine
these issues in a VPC context. Outside of a VPC context, however, the following is expected
behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue commands
to the router.
> * eth2 is the routers public interface. By default, a single public IP will be setup
on eth2 along with the necessary iptables and ip rules to source-NAT guest traffic to that
public IP.
> * When a public IP address is assigned to the router that is on a separate subnet to
the source-NAT IP, a new interface is configured, such as eth3, and the IP is assigned to
that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how many public
subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The master.py
script is responsible for setting public interfaces to UP during a keepalived transition.
Currently the check_is_up method of the CsIP class brings all interfaces UP on both RvR. A
proposed fix for this has been discussed on the mailing list. That fix will leave public interfaces
DOWN on RvR allowing the keepalived transition to control the state of public interfaces.
Issue #1413 includes a commit that contradicts the proposed fix so it is unclear what the
current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. Assuming
public interfaces should be default be DOWN on an RvR we need to accommodate the fact that,
as interfaces are created, no keepalived transition occurs. This means that assigning an IP
from a new public subnet will have no effect (as the interface will be down) until the network
is restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two iptables rules
in the FORWARD chain of the filter table created for eth2 that allow forwarding between eth2
and eth0. Equivalent rules are not created for other public interfaces so forwarded traffic
is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, outbound
traffic is source-NAT'd to the networks default source-NAT IP. New connections from guests
that are destined for public networks are processed like so:
> 1. Traffic is matched against the following rule in the mangle table that marks the connection
with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 0x0/0xffffffff
> 2. There are no "ip rule" statements that match a connection marked 0x0, so the kernel
routes the connection via the default gateway. That gateway is on source-NAT subnet, so the
connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP address is
the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message