[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to setup a multi vlan connection to an (Ubuntu) XEN-server !!??



louis.forums@xxxxxxxxx <lsrbreda@xxxxxxxxx> wrote:

> Lets start with the fact that I have to deal with two aspects:
> 1) Interfacing the host with the network
> 2) interfacing the host with the xen-hypervisor
> The first problem to solve was how to interface the host with the network. 
> 
> The host is connected to the network via vlan's (or untagged interface). 
> Those vlans are there for security reasons. And traffic should NEVER  be 
> allowed to pass from vlan to another one in an endpoint like a server. Unless 
> of course the server is used as firewall or managed switch. That is the 
> reason that I absolutely require that traffic which enters via vlan-x is also 
> answered via vlan-x.

OK, the detail that wasn’t previously stated. In that case, yes you’ll be 
needing policy routing.
One thing worth considering is whether the host needs addresses in multiple 
VLANs, or whether you could reduce host access to just one address on one 
network. Just trying to think of ways you could simplify things - though I 
realise that there are probably reasons for having it as it is.
It’s certainly a valid (in terms of what the OS needs) config for the host to 
have no addresses on some or all of the networks used by guests.


> Related to MAC-addresses:
> - of course I know the mac-addresses of the interfaces, however I do not see 
> any reason to use them here on IP-level, ......... apart from one reason. My 
> original intention was to change the interface names via "set-name", but 
> apart that the syntax is bizarre (first that name and then the definition 
> (strange), it did not work when using  match name <interface name> ...... and 
> it is clear that match on mac does work (ihmo it is a bug)

I agree that “set-name” does seem redundant - but the docs do suggest that it’s 
needed. It’s not a huge task anyway, you’re only building this config once.
Matching by MAC address is, IMO, by far the most reliable way to do things. 
Unless you change the hardware (i.e. replace a NIC) then it’s not going to 
change - and if you do replace a NIC then you know that there’s only one - 
precisely ONE - place you need to change the MAC address to keep your network 
config the same.


> Related to naming:
> - I completely agree that it is better to give interfaces, but also e.g. 
> vlans sensible names. Not sure that is possible for .e.g. vlans

It is - just use a meaningful name for the VLAN definition instead of (e.g.) 
“enp3s0f1.100”.

Based on what I recall of reading the docs, something like this should work :
# Define the trunk (2e 10G)
    trunk1:
      match:
        macaddress: “aa:bb:cc:dd:ee:ff"
      set-name: trunk1 # requires match (on mac !!??)


# Define vlan100 (vm-managment)
  vlans:
    vlan100:
      id: 100
      link: trunk1
      addresses:
      - 192.168.100.10/24
      ...


> Related to Bridges
> - I do not know yet I need them. That is because I do not yet know yet how to 
> connect one or more vm's, or dom0, to the host its network as defined in the 
> actual stage
> - perhaps I can simply connect one or more vm's or dom0 to an interface or 
> vlan, however perhaps I need to use a bridge for that. My feeling is that a 
> bridge is the equivalent of an unmanged switch ... only required if you want 
> to connect multiple (logical) devices (vm's !?) to an interface / vlan.

Well you are connecting multiple devices - the host and at least one guest - to 
an interface.
I’ve always left the physical interface un-numbered and put an IP address on 
the bridge. I do know there was a reason for that, but I don’t recall what it 
was - possibly networking between host and guest doesn’t work properly if the 
host spits the packet out of the physical interface rather than into the bridge.

You are correct to liken the bridge to an un-managed switch - that is exactly 
what it is. In the world of separate boxes, you’d have a switch per VLAN, 
physically plug in network cables, then power up the device. In the virtualised 
world, when you start a guest, Xen plugs in virtual network cable(s) between 
the guest and switch(es), then starts the guest. With no guest running, it’s 
valid to have a bridge with only the physical port connected - analogous to 
having a real switch with only the uplink connected, waiting for you to plug 
devices into it.

TBH, I don’t know if you can do what you want without bridges - hopefully 
someone else can help with that. What I do know is that using bridges is 
trivially easy - create bridge, connect physical interface (or VLAN interface), 
connect guest(s) as required.

So putting the above together, I’d probably have a config along the lines of :

# Define the trunk (2e 10G)
    trunk1:
      match:
        macaddress: “aa:bb:cc:dd:ee:ff"
      set-name: trunk1 # requires match (on mac !!??)

# Define vlan100 (vm-managment)
  vlans:
    pvlan100:
      id: 100
      link: trunk1

# Bridge for VLAN 100
  bridges:
    vlan100:
      interfaces:
        - pvlan100
      addresses:
      - 192.168.100.10/24
      ...

That, barring typos and me not understanding the docs properly, should create 
you a bridge called “vlan100” attached to VLAN 100 on the interface with MAC 
“aa:bb:cc:dd:ee:ff”, and with address 192.168.100.10/24 (plus the routing stuff 
etc).


I think that’s me out of ideas now. As I may have mentioned, I’ve not done this 
sort of advanced networking for a few years now (changed jobs) and no longer 
have access to any of the configs to look at.


Simon




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.