[ale] VLANs and logging

[Alex Carver]

Yeah, I know, I just hoped there was a VLAN method I didn't know about
that didn't require additional IPs. :)


On 2019-04-17 11:59, Derek Atkins wrote:
> A VLAN is effectively the same as a virtual NIC.  So for each VLAN,
> imagine the system has yet another Ethernet interface.  Plan your IP
> network accordingly.
> 
> -derek
> 
> 
> On Wed, April 17, 2019 2:50 pm, Alex Carver via Ale wrote:
>> I was hoping to avoid having multiple IPs on them but looks like I can't
>> since each VLAN virtual interface will have to have its own IP.
>>
>> On 2019-04-17 08:47, Phil Turmel via Ale wrote:
>>> A trunk port w/ tagged VLANs for your router and DHCP server is all you
>>> need.  These devices are then virtually multihomed (in addition to your
>>> router's uplink).
>>>
>>> You router will bounce traffic among your local VLANs to the extent you
>>> wish to allow it.
>>>
>>> On 4/17/19 10:56 AM, Alex Carver via Ale wrote:
>>>> The plan was always to use managed switches to isolate the VLANs (I
>>>> already have them) but I  was mainly trying to sort out the missing
>>>> links.  I only have one DHCP server but it's not at the router, it's a
>>>> separate machine that also handles DNS.  Similarly the logging server
>>>> with the big drive is also independent of the router.  Currently the
>>>> router is a small computer with a pair of USB NICs though I could be
>>>> convinced to replace it with something like a Ubiquiti EdgeRouter if
>>>> that was part of the solution.
>>>>
>>>> The things that complicated the layout were the fact that sometimes
>>>> some
>>>> devices need to talk to others.  For example, the phones and other VoIP
>>>> devices have web management interfaces so I have to be able to reach
>>>> them from one of my desktop machines.  The desktop machines live on one
>>>> VLAN and the phones another.  The same thing happens to the cameras
>>>> where I need to access their video feeds or their web interfaces
>>>>   from a desktop computer.  At the same time I wouldn't want the
>>>> cameras
>>>> being able to initiate a connection to a device outside of the VLAN.
>>>>
>>>> One thing I wasn't sure about is whether some of these devices were
>>>> going to need to be multihomed with multiple IPs hanging off trunk
>>>> ports
>>>> on the switches or if I could do something smarter than that.
>>>> Multihoming some of the devices would be hard to do.  One example are
>>>> the cell phones which I do use to view the cameras, visit internal
>>>> server pages, and also a VoIP softphone when I'm on WiFi to link with
>>>> the rest of the VoIP system.  When I'm out and about the VPN server has
>>>> to handle that and making that multihomed is probably an exercise in
>>>> drinking.
>>>>
>>>> The guest network and IoT network were actually the only
>>>> straightforward
>>>> parst of this mess.  Each was going to be isolated from the other and
>>>> neither was going to be able to communicate with the other VLANs (the
>>>> IoT network is specifically for devices like the TV that would need a
>>>> connection out to video services but I don't need to talk to the TV
>>>> myself).  It's all my other stuff that's harder simply because I have
>>>> these cross-over cases.
>>>>
>>>>
>>>> On 2019-04-17 06:19, Derek Atkins wrote:
>>>>> I don't see why you can't do both?  Assign each VLAN its own /24.
>>>>>
>>>>> You will need to *route* between the different VLANs.
>>>>>
>>>>> Some hosts may be able to be on multiple VLANs simultaneously by
>>>>> putting
>>>>> it on a physical trunk link (don't assign a VLAN at the switch) and
>>>>> then
>>>>> assigning the VLANs in software on the port in question (e.g. ifconfig
>>>>> eth0.69).  This would allow your syslog, DHCP, etc servers to talk to
>>>>> all hosts on all VLANs.
>>>>>
>>>>> I'll note that if you use multiple /24s but share a physical LAN you
>>>>> STILL have some potential for cross-talk.  For example, a host can put
>>>>> itself onto any VLAN it sees, whereas if you do port-based VLAN then
>>>>> the
>>>>> switch will prevent cross-talk!  This might be important for certain
>>>>> applications, like IoT, phone, etc.
>>>>>
>>>>> Of course, things get more complicated if you have a VM solution where
>>>>> different VM guests need to be on different VLANs.  ;)
>>>>>
>>>>> For the record, I was planning to use VLANs in my new home build-out.
>>>>> Specifically I was planning to have an IP Camera VLAN, a Guest VLAN,
>>>>> an
>>>>> IoT VLAN, and an in-house VLAN.  I was debating also a Server VLAN (I
>>>>> do
>>>>> run an oVirt cluster and have a routable Class-C Network), and maybe a
>>>>> Phone VLAN (although I only have 2 phones, so not a big deal).
>>>>>
>>>>> I'm still a good 6 months out from this deployment, so I have some
>>>>> time
>>>>> to plan it all out.
>>>>>
>>>>> -derek
>>>>>
>>>>> Jim Kinney via Ale <ale at ale.org> writes:
>>>>>
>>>>>> So you have a manageable switch that does vlans. Ports are assigned
>>>>>> to
>>>>>> specific vlans ids. To bridge vlans requires either vlan combination
>>>>>> at a port
>>>>>> or an external device like a multi homed server.
>>>>>>
>>>>>> For small locations like homes with under 20k devices, it's easier
>>>>>> to use
>>>>>> literal private networks. Guest network is one class C, phones get
>>>>>> another,
>>>>>> iot another, etc. Use the dhcp server as the bridge/firewall/router
>>>>>> between
>>>>>> all. Assign fixed IPs by mac in the dhcp for servers, printers, and
>>>>>> such, and
>>>>>> dynamic for everything else based on which nic port the request
>>>>>> arrives on at
>>>>>> the dhcp server.
>>>>>>
>>>>>> On April 16, 2019 11:47:28 PM EDT, Alex Carver via Ale <ale at ale.org>
>>>>>> wrote:
>>>>>>
>>>>>>      I'm playing around with the idea of splitting a few things at
>>>>>> home into
>>>>>>      VLANs.  This would include one VLAN for phones, another for the
>>>>>> general
>>>>>>      computers, a third for IoT devices, a guest network, and one
>>>>>> for the
>>>>>>      video cameras.
>>>>>>           The problem I'm trying to figure out is how to set things
>>>>>> up so that the
>>>>>>      devices with configurable syslogs (in this case phones,
>>>>>> computers,
>>>>>>      cameras) send their logs to my central logging server, allow
>>>>>> the devices
>>>>>>      to pick up their DHCP leases from the central DHCP server, and
>>>>>> still
>>>>>>      have the ability to reach the admin consoles for things like
>>>>>> the phones
>>>>>>      and cameras.
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> https://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
> 
>