Sometimes you have more than one router in your network, and want different [[VEcontainer]]s to use different routers. For that, Other times you may have a single HN with IP addresses on different networks and want to assign containers addresses from those networks. Lets say you have a HN with an IP address in network 192.168.100.0/24 (192.168.100.10) and an IP address in 192.168.200.0 (192.168.200.10). Maybe those addresses are on different VLANs. Maybe one is an internal network and the other faces the wider internet. Maybe you have 10 different networks assigned to the HN. It does not matter as long as there is a gateway on each of those networks. In our example we will assume the gateways are 192.168.100.1 and 192.168.200.1. You want any container assigned an address in the 192.168.100.0/24 network to use 192.168.100.1 and any container assigned an address in the 192.168.200.0/24 network to use 192.168.200.1. By default the network traffic coming from a container will use the default gateway on the HN to reach the rest of the world. If we want our containers to use the gateways on their respective networks we need to set up configure source-based routing on . This involves creating an additional routing table to redirect the host systemtraffic.  For example: <pre># /sbin/ip rule add from 192.168.100.0/24 table 10000# /sbin/ip route add throw 192.168.100.0/24 table 10000# /sbin/ip route add default via 192.168.100.1 table 10000</pre> The first line adds a routing rule. This rule tells the system to use an alternate routing table when trying to route packets from a certain source. In this case we are telling the system that if a packet originates from a 192.168.100.0/24 address we should use routing table 10000. The table number is unique and simply must be an unused table number from your system. I tend to start at 10000, but you can start your number wherever is convenient. To see a list of tables in use you can use:

# /sbin/ip rule add from $IP table $TBL# /sbin/ip route add default dev eth0 via $GW table $TBLlist

where * <code>$IP</code> Next we add two routing rules to table 10000. The first one is an IP a throw rule. A throw rule merely tells the system to stop processing the current table if the destination address which should matches the criteria provided. This will allow the host system and the VPSs to continue to reach other systems on our 192.168.100.0/24 network without trying to use non-the default gatewaywe provide. You can also use netmask here, e.g And the second rule provides that default gateway.  Now all we need to do is repeat this for our second network: <codepre>10# /sbin/ip rule add from 192.9168.8200.0/24<table 10001# /sbin/code> will mean that all containers with addresses like 10ip route add throw 192.9168.8.x will be routed through the given gateway200.0/24 table 10001* <code>$GW<# /sbin/code> is a gateway for this IP addressip route add default via 192.168.200.1 table 10001* <code>$TBL</codepre> is any free  Here we have changed the networks in the rule and routes and used a different table number. Everything else stays the same. You can, of course, I use numbers from 6 upwardsas as many complex routes to a particular table as you like. If you want to allow a container in the 192.168.100.0/24 network to reach the 192.168.200. Note that tables 250-255 are usually reserved (see 0/24 network without using the gateway, you can add another throw rule and allow the HN's default routing table to take effect: <codepre># /etcsbin/iproute2ip route add throw 192.168.200.0/rt_tables24 table 10000</codepre>).

Note that A previous version of this page suggested adding an additional route in order to allow the HN to contact the container. Indeed this would be required if we did not provide the throw rule, but maintaining such a configuration requires adding new rules for every new noncontainer. Using <code>vzctl set <ctid> --standard gateway will require another ipadd <ip></code> adds these rules to the main routing table by default, but not our custom routing table number. The configuration here only requires rules to be modified when changes are made to the networks, not each container.