ProSoundWeb Community

Sound Reinforcement - Forums for Live Sound Professionals - Your Displayed Name Must Be Your Real Full Name To Post In The Live Sound Forums => LAB: The Classic Live Audio Board => Topic started by: Scott Helmke on January 20, 2013, 09:35:57 pm

Title: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Helmke on January 20, 2013, 09:35:57 pm
OK, so here's a basic primer on TCP/IP networking.  Applicable to basic computer networking, including audio devices with a TCP/IP (aka "Cat5") port and standard networking.  I'm not going to bother to explain the acronyms.  Make up a cute and memorable name for each if you like.

So the overview is that each device on the network needs a unique address.  Back in the bad old days when we ran coax around to each computer these addresses were manually assigned.  That's still what happens a lot in digital audio applications and device control, just to keep things consistent.

DHCP:  This is where you have something on the network (usually a router, even a cheap WiFi router these days usually has a DHCP server inside) which hands out addresses automatically.  This is the easiest way to go, generally.  Each device needs to be configured for DHCP instead of manual address (though you can still have some devices with manually set addresses), and the DHCP server will hand out compatible unique addresses to everybody.  Beyond that some devices can also assign themselves a generally unique address, assuming other things on the network are doing the same thing and if there's no DHCP server to be found.

Not every device can request a DHCP address, though.  Yamaha consoles, for instance.  So you'll still need to understand a little about manual addressing.

The usual type of address you see looks something like this:  192.168.1.12, with a subnet mask of 255.255.255.0.  Each of those numbers is between 0 and 255, and unless we're talking IPv6 you'll always see four of them with those periods in between.  The deal here which you should remember above all else is that each device needs a unique address, but not too far away from the other devices you want to talk to.  So with that 192.168.1.12 you might have addresses like 192.168.1.100, 192.168.1.209, etc.  The first three numbers are the same for all of those, the last is different.  Those are compatible addresses in the same subnet.

Subnets - so what is a subnet?  It's a way to make addresses more local.  When you talk about your neighbors you don't have to give the whole address, everybody knows they're on the same block so you can just give the house number and maybe the street.  Subnets work the same way, making the space smaller so that it is easier to deal with.  There are different types of subnets - class A is huge, class B is medium sized, class C is small.  That 192.168.1.x example is a class C address, where the first three numbers are always the same and the last changes.  Since the numbers are always between 0 and 255 the size of your "neighborhood" is smaller than say 254 (some addresses tend to be reserved) devices.  Almost always that'll be enough for our purposes. 

Now if you need a bigger neighborhood you can use a class B subnet, where the first two numbers are always the same and the last two need to be unique.  Now we're into the tens of thousands of possible devices.  Class A goes even further; only the first number needs to be the same between all the devices.  Class A subnets are only used by companies like Google and IBM.

Dante defaults to a class B subnet, and the default addresses.  Remember above when I said that if all else fails a device might just assign itself a random address?  This is the usual way that Dante devices find each other, assigning themselves a class B subnet with the addresses always starting with 169.254.  Dante devices can also be configured to request addresses from a DHCP server or use a manually assigned address.

Subnet mask:  I'm not even going to try to describe why this is the way it is.  Suffice it to say that for a class A subnet it'll be 255.0.0.0, for class B it'll be 255.255.0.0, and for class C it'll be 255.255.255.0. 

MAC address:  This is basically a serial number for your network device.  It's made up of a manufacturer code (assigned by the folks who admin the Internet) plus a unique number assigned by the manufacturer.  As long as everybody plays by the rules each network card, networkable device, etc. has a worldwide unique number.  It'll look something like this: "01-23-45-67-89-AB", where each digit can be 0-9 or A-F (hexadecimal, or 16 values per digit).  You don't need to worry about these - at the most, when setting up remote control of a Yamaha console, you might have to enter the MAC address from the console setup screen into the remote control application.

By the way, that 192.168.1.x example isn't random numbers.  That's the official default for "I'm just hooking some computers together" addresses.  Just about every little Wifi router found in just about every home has the address 192.168.1.1, and will hand out addresses compatible with that.  Sometimes you'll see 192.168.0.x instead, which is fine too.

If you're trying to troubleshoot networking problems with Dante network you can manually assign your computer an address in that range of 169.254.x.x.  Just pick random numbers for the last two; out of a pool of tens of thousands you're probably not going to pick one that is already being used.  Don't forget to set the subnet mask to 255.255.0.0.

Number one network troubleshooting tool is "ping", which you can run from the Terminal application on a Mac or from the Command Prompt application on Windows.  "ping 192.168.1.32" will send a "tell me if you're there, dude" request to a device at that address.  If it's there and working it should send back a "hey man, I'm here" message.  Try this if you're not getting the control software to talk to something, and if it works (gets a response) then your problem is not with the network.
Title: Re: TCP/IP networking primer
Post by: Mac Kerr on January 20, 2013, 09:58:35 pm
I am going to make this a sticky. Please add to it. When there are enough posts we will edit it into a single document and distribute it to the contributors for editing and suggestions. At that point it will be reposted as a FAQ.

If we can put together a good FAQ that is not already spread around the Internet we will look into the possibility of getting it published as a magazine article.

Mac
Title: Re: TCP/IP networking primer
Post by: Scott Helmke on January 21, 2013, 01:37:37 pm
Ideally it'll get shorter, not longer.  Something that can be printed on a cocktail napkin would be the most useful.
Title: Re: TCP/IP networking primer
Post by: Tim McCulloch on January 21, 2013, 02:03:27 pm
Ideally it'll get shorter, not longer.  Something that can be printed on a cocktail napkin would be the most useful.

Networks so small you can drown them in a bath tub.... ;)
Title: Re: TCP/IP networking primer
Post by: Chris Johnson [UK] on January 22, 2013, 05:44:03 pm
Can I propose a couple of clarifications:

1) Ethernet refers to a group of networking technologies . Cat5/Cat5e/Cat6/Cat7 are cable types. RJ45 is the connector type that is typically used with the aforementioned cables for ethernet use. TCP/IP is a specific communications protocol. These things are not mutually exclusive. You can have ethernet without TCP/IP, you can have cat5 without ethernet, and you can have RJ45 connectors on other types of cable...

2) IP addresses are owned, like internet domains. However, back in the day, the powers that be decided they would reserve some IP addresses for private use. There are 4 such IP address blocks:
- 10.x.x.x
- 169.254.x.x
- 172.16.x.x
- 192.168.x.x
All other addresses are either reserved for special purposes, or owned by companies and used on the internet.

3) As an expansion on the use of 'ping':
If you find yourself in a situation where you need to connect to a device that has an address that is, say, 192.168.1.x, but you cant remember what exact address, you can set your IP address to an address in the same range (say 192.168.1.100) and ping 192.168.1.255. Then any device with an IP address that is 192.168.x.x will respond, allowing you to see the addresses of other devices on the network.

Equally, if you have no idea what the address is, you can connect your computer to the same LAN, and give it any IP address and then ping the address 224.0.0.1 and any device on the LAN with any address will respond.

Feel free to ignore if you like :)

But remember, todays engineer has to be part IT engineer!
Title: Re: TCP/IP networking primer
Post by: Jerome Malsack on January 24, 2013, 12:16:28 pm
2) IP addresses are owned, like internet domains. However, back in the day, the powers that be decided they would reserve some IP addresses for private use. There are 4 such IP address blocks:
- 10.x.x.x
- 169.254.x.x
- 172.16.x.x
- 192.168.x.x
All other addresses are either reserved for special purposes, or owned by companies and used on the internet.

These addresses are not routed onto the internet and they should be translated by the router to an address that can be.  With IPV6 there will be no equivalent and all addresses will be addressable on the internet. 
Title: Re: TCP/IP networking primer
Post by: Scott Wagner on January 31, 2013, 12:34:01 pm
In the audio world, it's best to keep networks as simple as possible.  While the subnet classes have been deprecated thanks to variable length subnet masking, they are still useful in that they are much easier for a novice to understand.  24 bit (or class C 255.255.255.0) subnet masks are probably the best choice for audio networks, since it is extremely rare to need more than 254 unique addresses (in each subnet) in an audio environment.  Keep in mind that the first address in a subnet (192.168.1.0 in a class C subnet for example) is the network itself, and the last address in a subnet (192.168.1.255 in a class C subnet) is the broadcast address (ie: all devices on that subnet will accept the packet).  That would leave a range of addresses available (192.168.1.[1-254]) for addressing each device.

Given the constraint that class C subnet masking will be used, the best choice for addressing would be to use the 192.168.[0-255].[1-254] private address space.  The first two octets (since they are 8 bits in length) are defined by RFC1918 as a private 16 bit (class B) address space that is easily configurable into 256 class C subnets.  The third octet (192.168.x) would define the network, and the fourth octet (192.168.[0-255].x) defines each device.  Traditionally, routers are assigned addresses at the beginning or end of the address space (192.168.1.1 or 192.168.1.254 for example), but there are no requirements to do so other than tradition.

To summarize the TCP/IP Networking for Audio Dummies:
1.  Use the 192.168.[0-255].[1-254] address space
2.  Use 255.255.255.0 for all subnet masks
3.  Pick a number for the third octet to define your network (192.168.1 is a standard choice).
4.  Pick a number for the fourth octete to define each device (192.168.1.[1-254]).
5.  The "default gateway address" is whatever address you've assigned to your router (or 0.0.0.0 if you don't have a router).
6.  Remember that most audio networks are switched (instead of routed), since it's best to isolate production networks from the rest of the world.
7.  When deploying wireless, always enable the security to keep the punters out of your production network.

If you stick to these simple constraints, anyone can easily configure networks without ever having to understand binary (base2) mathmatics.
Title: Re: TCP/IP networking primer
Post by: Tim Padrick on February 19, 2013, 10:23:58 pm
Quote from: Chris Johnson [UK
ss, you can set your IP address to an address in the same range (say 192.168.1.100) and ping 192.168.1.255. Then any device with an IP address that is 192.168.x.x will respond, allowing you to see the addresses of other devices on the network.

Equally, if you have no idea what the address is, you can connect your computer to the same LAN, and give it any IP address and then ping the address 224.0.0.1 and any device on the LAN with any address will respond.

192.168.1.255 works on my network.  224.0.0.1 does not.
Title: Re: TCP/IP networking primer
Post by: Scott Wagner on February 20, 2013, 09:28:45 am
In another discussion someone mentioned using MAC Filtering for alternative or additional security.  A MAC address is an unique identifier assigned by the manufacturer to each network device.  Enabling MAC Filtering would block anything with the exception of that specific device.  This is a good step to keep unwanted devices off of your network; however, if you replace that device (even with the exact same model) you will have to change your filtering rules since the new device will have a different MAC address.

Imagine a simple network consisting of a digital mixer, router (or WAP), and a single computer.  If MAC Filtering were enabled and only these three devices were added to the MAC filtering allow list, you could be in for some trouble.  If you computer dies and you have to replace it, now you can't get into the router (or WAP) to change the MAC Filtering rules.  At that point it's time for a hard reset of the router (or WAP) and starting over with the configuration from scratch.  I recommend having an additional computer allowed on your MAC list to avoid this situation.  We all know that computers never die, right?
Title: Re: TCP/IP networking primer
Post by: David Sturzenbecher on February 20, 2013, 11:03:51 am
This may be a new thread but...

Are there any best practices for adding wireless to systems with digital snakes. 

I would really like to know the best way to add a wireless router to my I-tech System without taking the Cobranet down...
Title: Re: TCP/IP networking primer
Post by: Justice C. Bigler on February 22, 2013, 11:55:59 am
This was just posted on another forum, and has a decent primer on networking basics, which includes topology and cabling and connector types.

http://labgruppen.com/media/download...PLM_rev106.pdf (http://labgruppen.com/media/download...PLM_rev106.pdf)

Title: Re: TCP/IP networking primer
Post by: Andrew Moyer on February 22, 2013, 10:46:22 pm
This was just posted on another forum, and has a decent primer on networking basics, which includes topology and cabling and connector types.

http://labgruppen.com/media/download...PLM_rev106.pdf (http://labgruppen.com/media/download...PLM_rev106.pdf)
Not sure what happened to the URL but here is all of it...
http://labgruppen.com/media/downloads/product/PLM_Series_Network_Configuration_Guide_NCG-PLM_rev106.pdf
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Jonathan Johnson on September 25, 2013, 05:06:16 pm
Dante defaults to a class B subnet, and the default addresses.  Remember above when I said that if all else fails a device might just assign itself a random address?  This is the usual way that Dante devices find each other, assigning themselves a class B subnet with the addresses always starting with 169.254.  Dante devices can also be configured to request addresses from a DHCP server or use a manually assigned address.

...

If you're trying to troubleshoot networking problems with Dante network you can manually assign your computer an address in that range of 169.254.x.x.  Just pick random numbers for the last two; out of a pool of tens of thousands you're probably not going to pick one that is already being used.  Don't forget to set the subnet mask to 255.255.0.0.


IP addresses beginning with 169.254.x.x are reserved to a special class of addresses known as APIPA ("Automatic Private IP Addressing"). APIPA addresses are not assigned, but rather chosen somewhat randomly ("pulled out of the air") by networking devices when they are not assigned an IP address manually (AKA statically assigned) or by a DHCP server (AKA dynamically assigned). (For example, Windows computers will choose an APIPA address if nothing else is available.) Since the APIPA standard specifies a subnet mask of 255.255.0.0, any two devices with a 169.254.x.x address on the same network segment will be able to communicate. APIPA addresses should never be statically assigned to a device except where there is no router on the network and no DHCP server, and such static assignments ideally would be temporary.
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Mac Kerr on September 25, 2013, 05:20:38 pm
IP addresses beginning with 169.254.x.x are reserved to a special class of addresses known as APIPA ("Automatic Private IP Addressing"). APIPA addresses are not assigned, but rather chosen somewhat randomly ("pulled out of the air") by networking devices when they are not assigned an IP address manually (AKA statically assigned) or by a DHCP server (AKA dynamically assigned). (For example, Windows computers will choose an APIPA address if nothing else is available.) Since the APIPA standard specifies a subnet mask of 255.255.0.0, any two devices with a 169.254.x.x address on the same network segment will be able to communicate. APIPA addresses should never be statically assigned to a device except where there is no router on the network and no DHCP server, and such static assignments ideally would be temporary.

The primary network for Dante uses 169.254.x.x addresses, the secondary network uses 172.31.x.x. All Dante devices on a network will have an address for each network it is connected to.

Mac
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Kieran Walsh on January 10, 2014, 09:13:02 am
IP addresses.... hmmmm

Very difficult to give a "definitive, and concise" pointer on this...

I'll start by being a bit controversial:

"IP addresses are perhaps the LEAST interesting thing about networking in my opinion... OK maybe a very close second to MAC addresses"

A large number of people waste pointless hours getting into messes with IP addresses because they can't just leave them alone.

There is a large amount of largely correct information here... for the definitive rundown on IP addresses (if you are really that interested) asking a good source of training such as www.commsupport.co.uk (who are providing free webinar training) will give you all the information you never wanted to know.

Why the lack of enthusiasm?

IPV4 addresses... the www.xxx.yyy.zzz type addresses we are used to seeing have been seriously messed around with since they were first thought up. Nobody predicted that everyone on the planet would need several IP addresses, so the address range wasn't built to a large enough scale. That was the first problem....

Well the global communications system hasn't ground to a halt - this is largely because a lot of IPV4 got revised and re-functioned... the truth is that 2^32 is actually a reasonably respectable number... its about 4.3 billion- ok there are more people on earth than that... well using an IP address to describe the address of a group of machines solved that... and the sockets layer was already there for application handling... so no problem.

The problem was that IPv4 was "shared out" in an inefficient way (20/20 hindsight... its not like these were unintelligent people doing it) Actually as soon as the problem was realised two proposals happened... IPv4 got re-functioned a bit (which immediately addressed the issue) and IPv6 was born.

IPv6 was nice because of historical context... IPV4 was born when fixed line phones were around - IPv6 by contrast had huge contributions from (inter alia) Nokia and Cisco. Mobile phones work differently to fixed line phones... so it is more a technology of its era. Someone alluded to what is known as IPv6 global addressing... this is where a device has a global public address... not a bad idea... but that changed a bit last year. There was concern about device security... so now IPv6 devices can have a global address and a private address (anyone getting deja vu?) OK so its not a big problem - IPv6 has such a big address pool - 128 bits instead of 32 bits... that we will never run out of addresses... so cutting that pool in half immediately isn't a big deal... and "640K should be enough for anyone". I of course say this partly in jest ;)

I'll explain with an example - IPv4 of course (IPv6 is great... but not human readable)

I have a bunch of devices in the network I am working in... counting up now... there are about 30 devices... there are multiple interfaces on most of them... so there are about 150 ports in this subnet. I'll be honest- I only know (or care) about the IP addresses on four devices (and even then I should only really care about two of them).

I know the IP addresses of my routers (Cisco enterprise boxes) and the IP addresses of two switches (the ones that the serial port is physically difficult to get at... IE I have to get out of my chair).

I need to know the IP addresses of my routers... because one is connected to the Local rack room directly, and the other is connected to another building across town for redundancy of Internet connection- both via Ethernet.

Naturally the backup route is in a different network to the main route, so those two routers have to be able to send traffic to and from each other, and load balance.

I am DHCP serving addresses to everything in the subnet that has the devices connected...

Every Dante device will obtain a DHCP address if there is a DHCP server present by Default - correctly identifying 169.254.xxx.yyy as APIPA (we prefer the term link-local) is- just like Windows, OSX and most Linux distributions- as in if there is no DHCP server present we fall back to this addressing method. Please Please Please do not statically assign APIPA range addresses... It "shouldn't" matter as most popular APIPA/Link Local mechanisms can deal with this (ours included)... but it is "non-standard practise" to do so.

So I care about the IP address of my router- so that I can configure the DHCP server I am running on it, and configure the routes to the other networks. Naturally My enterprise network has public IP addresses, and I may choose to function these as entire other networks or single devices...

To put it another way... I don't know the IP address of the server that handled my last google search - it is probably not of any immediate concern to google either (I hope)... they could probably find out if they really really wanted to.

What I did was I typed www.google.com into my browser, and then searched... DNS resolved the IP address for me, and I assume the google data-centre handled the assignment of which machine the request went to through their load-balancing algorithms.

Dante Devices (and an increasing number of other devices too) use MDNS - which means that you can talk to a device by typing its name .local into your browser... or ping using the name rather than the IP address... Even my newer Cisco switches do this, and I have worked on installations where the IT department use MDNS names to communicate with switches... much easier to remeber westgate.local than a bunch of numbers.

This mode of working is going to become the norm... as IPv6 addresses (at 128 bits long) are impossible to remember!

There was a time... once upon a time, where software implementations cared about IP addresses... this was largely solved with "updates" to certain operating systems...

Now if I write a software application that uses a network port- some nice open-source code and the operating system device driver take care of it for me...

The IP addresses you need to know are:
The public IP address of your network (if you are manually configuring an enterprise network)

And then the IP address range you are telling your DHCP server to dish out - suggest choosing a private IP address range (the router will keep those devices "invisible" to the outside world).

OK so there are some software applications that "force" you to use static IP addresses. This is nothing to do with the network being any different.

The "gentle" path is probably to describe how I set up my own web domain.

I purchased a domain name from a domain registration service... but I want to use a different hosting service (located at a different place) to actually hold the information for say my email and web services.

Lets think about what happens when I type the web address www.mydomain.com into a browser...

The first thing that happens is that the browser application asks something called the DNS what IP address www.mydomain.com is at (I am unaware as to whether this is IPV6 or IPv4 from an end user perspective... if my browser, and infrastructure support IPv6, then it might be IPv6... the application will deal with all of this for me. Because I "purchased" the domain from a registration company - they hold the DNS record for my domain... its a big database. If I edit the DNS record here - for example I can "point" ftp.mydomain.com direct to a hard drive on my desk in my office if I know how to set up a public IP address for that hard drive. I can point www at a server of my choosing elsewhere.

If I change the DNS record, then this change will take a few hours to copy itself across the web of DNS servers globally (it doesn't work so well if all the computers in the world make requests to the same machine...)

Once my application knows the IP address of the "other end" it can communicate with the other device.

MDNS (sometimes known as Bonjour) does this in microcosm. That is after all how you can find printers so easily when connected to a network... there is a nice record of that network printer sitting in the MDNS domain waiting for your Bonjour client (inside your operating system) to browse for it.

Using MDNS- we can "discover" what is out there... and some other information about it. Once we "know" that something is there... and that this "something" is of interest to our application (from its description), then we can display it seemingly automatically to the user.

Of course we don't have to use MDNS to do this... we could make up our own parallel method- MDNS is one open-source technique to do this.

The important aspect to note here is that I am using names... not IP addresses. Just like on the big bad internet- If I get angry with my hosting company (which I have done before... mainly due to charges) I can move elsewhere very quickly... I go back to DNS, and I simply change the IP address or master domain of my new host in the DNS record... a few hours later, and its as if the old host never existed... but users will not notice... they will still type www.mydomain.com and get the same content (as long as I copied it correctly). In the same way...

Dante uses a naming scheme for channels that looks like kickdrum@stageleft.local

If I name a new piece of equipment stageleft and call a channel on that piece of equipment kickdrum, the Dante network will not be able to tell any difference. The IP address (which we don't care about) may be different, and the MAC address will also be different (we care even less about this), but if I put this identically named device into the network, after removing the "original" the system will pick up the information from the new device as if it were the "original".

I could go further and of course use other metrics to stop this happening... if that was a needed feature... but I would still not use the IP address to achieve this.

This is why some devices have the "identify" LED on them... Out of the factory a device will be called <sometext>nnnnnn which will uniquely identify it. Not a very snappy name- granted. but there are ways to change this name and if the name is changed according to a template, then pre-configuration is achievable in software without having to blindly target IP addresses.

In fact it is possible to push complex information to a device in a very easy way... think...

OK so I have a new device with uncool name
- i'll change the name,
- my application knows it has information for that device name
- ah yes there it is
- send message to device named my_new_toy
- IP address is known- all automatically handled

In terms of actual sending of data there is no big difference in sending the data- instead of targeting an IP address, you target a name (that resolves to an IP address)

Some have argued "what if the name resolution breaks?"
The IP address is resolved to the MAC address don't forget... What if ARP breaks?

The advantage with the name approach is that there is a concept of automatic discovery. IP address based software tends to either rely upon a entering numbers in each endpoint locally, or doing a ping of every address in a subnet to find out what is there, and then populating a table much like a quasi DNS record in any case.

This is a complex subject, and I have not done it justice here... please post questions/comments for discussion
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Tommy Peel on January 10, 2014, 03:06:52 pm
IP addresses.... hmmmm

<snip>

This is a complex subject, and I have not done it justice here... please post questions/comments for discussion

Very interesting and informative read as a sound guy and an IT guy(day job).
Title: Re: TCP/IP networking primer
Post by: Theo White on June 10, 2014, 02:42:00 am
In another discussion someone mentioned using MAC Filtering for alternative or additional security.  A MAC address is an unique identifier assigned by the manufacturer to each network device.  Enabling MAC Filtering would block anything with the exception of that specific device

This is actually not true.  It's very easy to spoof a mac address.  If you're only using mac address filtering to secure your wireless network then your wireless network is *not* secure. 
Title: Re: TCP/IP networking primer
Post by: Bob Charest on June 10, 2014, 08:23:32 am

This is actually not true.  It's very easy to spoof a mac address.  If you're only using mac address filtering to secure your wireless network then your wireless network is *not* secure.

Theo, the post you quoted stated "alternative or additional" security. Although mac addresses can be spoofed, if one only allows several mac addresses access, it's going to take someone a long time to determine which mac addresses they want to spoof.

Nothing is impervious to tampering, but making it harder to do, and not worth the effort, is a good idea... I'm sure you agree.

Best regards,
Bob Charest
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Stefan Maerz on June 21, 2014, 03:26:48 pm
A common problem I have noticed that new networking people have is with IP addressing conflicts. Typically between DHCP and statically assigned addresses. I suppose there are other ways to accomplish this, but I don't recall seeing other ways occur in the wild.

Basically an addressing conflict occurs when two devices have the same IP address.

The most common source (I've found) is when people haphazardly mix DHCP (automatic IP assignment) with Static IP assignment (Manual IP assignment). The problem arises when you have assigned a static IP within what is known as the DHCP Pool (Also known as the DHCP range, DHCP Addresses, or a whole host of other names I'm sure). The DHCP pool are addresses that the DHCP server can hand out when a network device connects to the network.

For example, the DHCP pool might be configured to assign addresses from 192.168.1.50 to 192.168.1.100. If you, for instance, statically assign 192.168.1.55 and the DHCP server tries to hand that address out, you now have the possibility of two devices with one IP address.

The solution is simple -- move your static IPs out of the DHCP pool, or move the DHCP pool away from the static IPs. It is also possible (but typically not a good practice) in some situations to assign static IP addresses through DHCP. That is the client connects to the DHCP server and asks for a DHCP lease, then receives the same address every time, thus reserving its spot in the DHCP pool. I've also seen situations where you can make "exceptions" to the DHCP pool (i.e. don't hand out 192.168.1.55 via DHCP). But your best bet is to keep the DHCP pool and static assignments separate.

It is also worth noting that ip addressing conflicts can come and go. DHCP assigns addresses based on a "lease," which has a predetermined length. In other words, the IP address is given to the client computer for a predetermined period of time. A common length for a DHCP lease is 24 hours. So once that lease has expired (in our example 24 hours), the IP addressing conflict might go away after 24 hours (if the DHCP gives a different address). However if you have network misconfigured, the problem can reappear at any time.


In summary: Make sure your DHCP pool (aka DHCP range, DHCP addresses, DHCP start address/DHCP end address, ect.) and static addresses do not overlap.
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Holtzman on July 09, 2014, 12:02:45 am
My real job is a network engineer.  I have watched brilliant sound engineers trip on simple network concepts.  They have had to watch (and hear) my basic mistakes when I was starting and the mistakes I still make today so fair trade.

Anyway #1

There is no  reason to use anything other than a 255.255.255.0 subnet mask, almost every device defaults to it.

So rule #1 is the first three octets (digits between the periods) must be the same between all devices in the network

#2

Lots of devices, especially tablets that we use to manage the sound gear expect to find the Internet on the other side of a networks gateway.  Since only the largest fixed installations may need a gateway you should always leave your gateway blank or 0.0.0.0 - This goes for when setting up the DHCP on the network, most routers will put the interface IP (the IP assigned to the LAN port on the device) in the gateway field.  You should delete or use 0.0.0.0

The other good thing about rule #2 is you can turn on your Cellular connection on your tablet and get to the Internet and your console.  Fear no security because your device can't forward a packet between interfaces (just trust me on this one)

If you know a sound guy who is a network geek during the day ask them for help.  They will fall over backwards (at least I will) to help a seasoned pro and possibly learn something from them.

Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Stefan Maerz on July 09, 2014, 11:58:22 am

#2

Lots of devices, especially tablets that we use to manage the sound gear expect to find the Internet on the other side of a networks gateway.  Since only the largest fixed installations may need a gateway you should always leave your gateway blank or 0.0.0.0 - This goes for when setting up the DHCP on the network, most routers will put the interface IP (the IP assigned to the LAN port on the device) in the gateway field.  You should delete or use 0.0.0.0

The other good thing about rule #2 is you can turn on your Cellular connection on your tablet and get to the Internet and your console.  Fear no security because your device can't forward a packet between interfaces (just trust me on this one)

If you know a sound guy who is a network geek during the day ask them for help.  They will fall over backwards (at least I will) to help a seasoned pro and possibly learn something from them.
Aside from isolating your audio gear from the internet, what is the advantage of this? (Perhaps I am missing it) legitimate question -- I have network printers who ask for a gateway, I've never understood why -- so I end up plugging it in even though it works without it.

I also agree with the subnet point. If you have more than 254 networked devices you should probably have someone who knows what they are doing for reasons beyond address space. Following these instructions will make your life easier.

Along those lines sometimes the subnet mask of 255.255.255.0 is referee to as /24 in what is known as CIDR notation, though I can't say I've seen CIDR pop up in home/small audio networking.
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Holtzman on July 09, 2014, 05:03:00 pm
Aside from isolating your audio gear from the internet, what is the advantage of this? (Perhaps I am missing it) legitimate question -- I have network printers who ask for a gateway, I've never understood why -- so I end up plugging it in even though it works without it.

I also agree with the subnet point. If you have more than 254 networked devices you should probably have someone who knows what they are doing for reasons beyond address space. Following these instructions will make your life easier.

Along those lines sometimes the subnet mask of 255.255.255.0 is referee to as /24 in what is known as CIDR notation, though I can't say I've seen CIDR pop up in home/small audio networking.

1 -  You can't have two gateways so if you populate the gateway in a closed system you can't have Internet on another interface
2 - I would not even bring up CIDR notation, then you have to explain why 255^8+255^8+255^8=24

Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Kieran Walsh on July 09, 2014, 08:23:45 pm
1 -  You can't have two gateways so if you populate the gateway in a closed system you can't have Internet on another interface
2 - I would not even bring up CIDR notation, then you have to explain why 255^8+255^8+255^8=24

First let me state that functionally a lot of what has been said so far is sound advice in terms of the world "today"

I do feel its important to put the pedants hat on... As often times people reference something as the gospel out of context and confusion occurs. You can have more than one gateway - this is very important when constructing a scalable internetwork. You likely do not NEED to have multiple gateways in most deployed audio networks today... but that is a long way from the existence or not thereof.

I totally Agree - if you know what CIDR notation is... good for you... I hope you understand it and VLSM... if you don't know what these terms are and what there significance is then you probably have more interesting things to do with your time ;) A full discussion on subnetting is best done elsewhere.

a machine does not expect to see "the Internet" the other side of a router. The machine hopes that packets that are not delivered within the LAN will reach their destination IP address by going through the (or a) gateway to their destination... whether they do this or not is purely down to whether an internet exists (note the deliberate difference in the capital and lowercase i)
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Holtzman on July 09, 2014, 09:00:52 pm
First let me state that functionally a lot of what has been said so far is sound advice in terms of the world "today"

I do feel its important to put the pedants hat on... As often times people reference something as the gospel out of context and confusion occurs. You can have more than one gateway - this is very important when constructing a scalable internetwork. You likely do not NEED to have multiple gateways in most deployed audio networks today... but that is a long way from the existence or not thereof.

I totally Agree - if you know what CIDR notation is... good for you... I hope you understand it and VLSM... if you don't know what these terms are and what there significance is then you probably have more interesting things to do with your time ;) A full discussion on subnetting is best done elsewhere.

a machine does not expect to see "the Internet" the other side of a router. The machine hopes that packets that are not delivered within the LAN will reach their destination IP address by going through the (or a) gateway to their destination... whether they do this or not is purely down to whether an internet exists (note the deliberate difference in the capital and lowercase i)

Kieren - It's important to be specific, it's not a gateway it's a default gateway of last resort for the 0.0.0.0/0 network.  If you have two interfaces, such as a 4G and a wifi on a tablet and you put a default gateway on both interfaces at the least Internet connectivity will "flap" between the two equally costed routes.  At the worst the OS will think one connection is unstable and go in search of another.  Then you lose you network in the middle of show.  If running a headless mixer like a Behringer x32 core or rack or a Mackie DL-1608 all of a sudden you have no control over your system.  If feedback starts it could turn ugly really fast.

Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Kieran Walsh on July 10, 2014, 02:03:07 am
Kieren - It's important to be specific, it's not a gateway it's a default gateway of last resort for the 0.0.0.0/0 network.  If you have two interfaces, such as a 4G and a wifi on a tablet and you put a default gateway on both interfaces at the least Internet connectivity will "flap" between the two equally costed routes.  At the worst the OS will think one connection is unstable and go in search of another.  Then you lose you network in the middle of show.  If running a headless mixer like a Behringer x32 core or rack or a Mackie DL-1608 all of a sudden you have no control over your system.  If feedback starts it could turn ugly really fast.

Scott - the phrase used originally was gateway. The statement was therefore factually incorrect. The application you describe where there is a simple network and we are considering a gateway of last resort is indeed probably the most common (and probably only) scenario that most Pro-Audio users will encounter.

I do however spend a lot of time dealing with misconceptions held by IT managers that have been started by well intentioned AV people using terms that they have seen which have had terminology adapted for the application.

I apologise I have made it seem necessary to elaborate on further examples. As I said before a lot of things said here - including your previous comments form great practical advice for a specific situation/use case. I am merely stating that using terms as they are described "in general" ie outside of the specific use case is very risky without realising that the scope has been narrowed deliberately to provide a solution. To this end your example of a node "flapping" between gateways is just one possible (albeit common) operating mode. To be fair you did use the term "headless" but I picked up on it... the distinction may be subtle to others.

I mention this because should someone go tell an IT manager in an enterprise scenario that "you cant have two gateways because the nodes will flap between them" the urge to restrict and even remove that user from essential resources grows in the mind of the IT guys... this is a shame, and happens all too often. There are many examples of over complex methodologies being used due to certain published use cases that arguably have done more harm than good in the long-run, as they describe a specific workaround rather than a "perfect world" operating scenario.

Its a really good conversation to have, and am on the side of putting all of these things "out in the wild" so to speak, as a large discussion ultimately gives the greatest number of possible workarounds and solutions (which are things that we all need practically). The "perfect world" where everybody knows everything about everything is obviously not practical - so my best final thought for this post would be... yep thats right... you really don't want me to mix your band! but maybe I might fix your network well ;)
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Tom Burgess on July 10, 2014, 12:28:39 pm
My brain hurts.
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Holtzman on July 10, 2014, 01:55:32 pm
My brain hurts.

That's what I was trying to avoid, the take away here is if you don't populate the gateway field in your device or in the DHCP scope then you will never have an issue of two default gateways.  It's that simple.

Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Tom Burgess on July 10, 2014, 03:04:14 pm
That's what I was trying to avoid, the take away here is if you don't populate the gateway field in your device or in the DHCP scope then you will never have an issue of two default gateways.  It's that simple.
OK, I was actually just being a smartass about the brain thing... or maybe I was channeling an old Monty Python skit, hmmmm.   :o

It's been several years since I've had much to do with IT on a regular basis but I was actually able to follow enough of the commentary here to glean some excellent information.  Thanks to all for the great info!  :) 
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Helmke on July 11, 2014, 07:02:37 pm
The question of "gateway" is a very weird one in the context of networked audio device control. Recent Yamaha mixers (M7CL and later) have a setting for gateway IP address, and you do have to put in something in the same subnet. But what the heck is it for? It's not like an LS9 is going onto the Internet to download its own firmware updates.

And beyond that, you really can't use the Yamaha control software (Studio Manager, CL Editor, etc) across subnets anyways because they use a protocol that also needs MAC address. I've got a kickass little L-Com wireless access point / router at work that we can't use for remote mixing because there are no "local" hardware ports. I've been able to tweak things enough to mostly control a Meyer Galileo... but that's beyond anything we could expect a show tech or rental customer to set up in the field.
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Josh Millward on July 11, 2014, 07:16:39 pm
The question of "gateway" is a very weird one in the context of networked audio device control.
I guess I don't think it is that weird. There are plenty of devices out there that can use the default gateway to reach out to something elsewhere on the network. Working from my personal knowledge of the MediaMatrix NIONs I deal with daily, if you have them connected to a larger network that is accessed through a router, you can keep the NION's multicast traffic between themselves down within the context of your larger network. IT guys seemingly hate multicast traffic because it is too easily abused, so they like to filter and block it when they can. However, I can still use a tablet to bring up a user control screen through the web interface since there is a WiFi access point on the network and using the router on the network I can still access the NIONs and manipulate the system remotely. Likewise, the NIONs can also send control information to other devices on other parts of the network that are on the other side of the router if you give them the default gateway.

Recent Yamaha mixers (M7CL and later) have a setting for gateway IP address, and you do have to put in something in the same subnet. But what the heck is it for? It's not like an LS9 is going onto the Internet to download its own firmware updates.
It is just a part of the standard network stack. I'm glad to see that Yamaha has thought far enough ahead to include it. It should be in there because it is part of the IP communications protocol. Your device needs to know where to send requests when it doesn't already know where to send them. Whether your device needs that ability is another question altogether. With the NION platform you can just leave the field blank if you do not have a router on the network for it to communicate with.
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Holtzman on July 13, 2014, 03:47:09 am
I guess I don't think it is that weird. There are plenty of devices out there that can use the default gateway to reach out to something elsewhere on the network. Working from my personal knowledge of the MediaMatrix NIONs I deal with daily, if you have them connected to a larger network that is accessed through a router, you can keep the NION's multicast traffic between themselves down within the context of your larger network. IT guys seemingly hate multicast traffic because it is too easily abused, so they like to filter and block it when they can. However, I can still use a tablet to bring up a user control screen through the web interface since there is a WiFi access point on the network and using the router on the network I can still access the NIONs and manipulate the system remotely. Likewise, the NIONs can also send control information to other devices on other parts of the network that are on the other side of the router if you give them the default gateway.
It is just a part of the standard network stack. I'm glad to see that Yamaha has thought far enough ahead to include it. It should be in there because it is part of the IP communications protocol. Your device needs to know where to send requests when it doesn't already know where to send them. Whether your device needs that ability is another question altogether. With the NION platform you can just leave the field blank if you do not have a router on the network for it to communicate with.

Josh, everything you say is correct.  My comments were made for touring systems.  Installed systems may have requirements to reach other networks, switching gear etc.  If I was going out on the road I would also put a small file server running FreeNAS to keep common documents.  The other day we had a band that had their set list and other things they needed out in the cloud on a Google Docs and we had no Internet service or cellular data coverage.  We actually had to drive into town, download the docs so the show could start.  When IP became common place in live production and everyone knew that I was an IT guy I was extremely popular.  Now I have folks trained they won't call me until they have tried to ping a few devices.  The oddest thing I ever had was the in house guy checked the IP's on the iPOD's the band was using for their monitor mixes and he told me the IP's were too close the sound could "bleed over" I was so flummoxed I didn't know what to say.  Reminded of the story of a guy showing up with a rig for show, the rider said no Behringer.  There was an inactive (not even plugged in and certainly not in the signal chain) Behringer crossover or GeQ in the rack.  The manager insisted it would degrade the performance and made them take it out of the rack and put it in the truck.

Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Stefan Maerz on July 15, 2014, 11:57:59 am
For the record, when I brought up CIDR, I was in no way recommending people learn vlsms or subnettibg at any capacity.

CIDR is simply a different way to express a subnet mask. 255.255.255.0 = /24.

That is pretty much all the home networking/audio networking person needs to know to keep things simple IMO. I've needed to use CIDR in home networking before. That is why I brought it up.

Nothting about complex addressing schemes. :)
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Josh Millward on July 17, 2014, 02:32:23 pm
If I was going out on the road I would also put a small file server running FreeNAS to keep common documents.  The other day we had a band that had their set list and other things they needed out in the cloud on a Google Docs and we had no Internet service or cellular data coverage.  We actually had to drive into town, download the docs so the show could start.

Yep, here again, if it is something that critical to your show, you NEED to be bringing it with you.

The oddest thing I ever had was the in house guy checked the IP's on the iPOD's the band was using for their monitor mixes and he told me the IP's were too close the sound could "bleed over" I was so flummoxed I didn't know what to say.

Now that is funny!

Reminded of the story of a guy showing up with a rig for show, the rider said no Behringer.  There was an inactive (not even plugged in and certainly not in the signal chain) Behringer crossover or GeQ in the rack.  The manager insisted it would degrade the performance and made them take it out of the rack and put it in the truck.

Oh my!!! Out, out evil devil!!! You must get out of the rack or you are going to destroy our performance! LoL!!!

Thanks for those! Hahaha
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Brad Harris on October 31, 2014, 02:33:58 pm
Program question on monitoring IP/MAC addresses with either iPad or PC/MAC computers

Usually, I'm out with 20-60 units of networked inventory (Tx, Rx, Amps, Consoles) across a network on a show. Our inventory of equipment is probably close to the 1000 unit mark.

I've been using Fing on my iPad for monitoring onsite show use (quick way to see what gear is on the network).

I've found programming with it (ie, entering its a UHFR or G3, 9000, etc) to be a little annoying, as it seems to randomly remembers units from day to day, and usually not. (I know it doesn't support seeing different units on different networks ... I keep my AP and DHCP server the same across all of them until I eventually replace them every few years).


Is there a good (cheapish) app to keep this information? (preferably based on MAC addresses) without going into a 'terminal' application and sorting through the information (Like Fing on MAC - I like the iPad app)


BRad




edit: - Autocorrect
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Riley Casey on January 04, 2015, 10:23:18 pm
I've been using http://10base-t.com/iphone-ipod-software/ipscanner-mobile/ on my Mac and iPad. 


...
Is there a good (cheapish) app to keep this information? (preferably based on MAC addresses) without going into a 'terminal' application and sorting through the information (Like Fing on MAC - I like the iPad app)


BRad




edit: - Autocorrect
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Scott Holtzman on January 05, 2015, 01:16:40 am
I've been using http://10base-t.com/iphone-ipod-software/ipscanner-mobile/ on my Mac and iPad.

http://www.solarwinds.com/products/freetools/ip-address-tracker/
Title: Re: TCP/IP networking primer
Post by: Jeff Hague on May 22, 2017, 05:15:33 pm
192.168.1.255 works on my network.  224.0.0.1 does not.

224.0.0.0 is a multicast address and many switches (especially pro/consumer level gear) block multicast by default so that may work on larger networks it will rarely work on smaller ones.
Title: Re: TCP/IP networking primer - Please Read and Add Questions and Comments
Post by: Theo White on July 01, 2017, 07:50:41 pm
For the record, when I brought up CIDR, I was in no way recommending people learn vlsms or subnettibg at any capacity.

CIDR is simply a different way to express a subnet mask. 255.255.255.0 = /24.

That is pretty much all the home networking/audio networking person needs to know to keep things simple IMO. I've needed to use CIDR in home networking before. That is why I brought it up.

Nothting about complex addressing schemes. :)

Classless IP adresses are typically used with WAN connections.  Classful IP addressing, especially using Class C addresses, is more than sufficient for small private networks.