ProSoundWeb Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: 1 [2] 3 4   Go Down

Author Topic: TCP/IP networking primer - Please Read and Add Questions and Comments  (Read 23072 times)

Justice C. Bigler

  • SR Forums
  • Hero Member
  • *
  • Offline Offline
  • Posts: 1548
  • Tulsa, Oklahoma
    • My homepage
Re: TCP/IP networking primer
« Reply #10 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

Logged
Justice C. Bigler
www.justicebigler.com

Andrew Moyer

  • SR Forums
  • Newbie
  • *
  • Offline Offline
  • Posts: 31
Re: TCP/IP networking primer
« Reply #11 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
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
Logged
Andrew Moyer

Jonathan Johnson

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2449
  • Southwest Washington (state, not DC)
Re: TCP/IP networking primer - Please Read and Add Questions and Comments
« Reply #12 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.
Logged
Stop confusing the issue with facts and logic!

Mac Kerr

  • Old enough to know better
  • Administrator
  • Hero Member
  • *****
  • Offline Offline
  • Posts: 5418
  • Audio Plumber
Re: TCP/IP networking primer - Please Read and Add Questions and Comments
« Reply #13 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
Logged

Kieran Walsh

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 88
    • Audinate
Re: TCP/IP networking primer - Please Read and Add Questions and Comments
« Reply #14 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
Logged
Senior Technical Solutions Manager, Audinate EMEA.

Tommy Peel

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1446
  • Longview, Texas
    • Facebook Profile
Re: TCP/IP networking primer - Please Read and Add Questions and Comments
« Reply #15 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).
Logged
"An idea is like a virus, resilient, highly contagious. The smallest seed of an idea can grow. It can grow to define or destroy you."
-Inception

Gear List:
Behringer XR18, Samsung Galaxy Tab A 10.1, Dell Latitude E7470, '09 13 inch MacBook Pro

Theo White

  • Newbie
  • *
  • Offline Offline
  • Posts: 9
Re: TCP/IP networking primer
« Reply #16 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. 
Logged

Bob Charest

  • Lab Lounge
  • Hero Member
  • *
  • Offline Offline
  • Posts: 640
  • Westbrook ME, USA
    • Bob Charest Band
Re: TCP/IP networking primer
« Reply #17 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
Logged

Stefan Maerz

  • Full Member
  • ***
  • Offline Offline
  • Posts: 199
  • Northern New Mexico
Re: TCP/IP networking primer - Please Read and Add Questions and Comments
« Reply #18 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.
« Last Edit: June 21, 2014, 03:31:55 pm by Stefan Maerz »
Logged

Scott Holtzman

  • Hero Member
  • *****
  • Online Online
  • Posts: 3383
    • River Delta Audio
Re: TCP/IP networking primer - Please Read and Add Questions and Comments
« Reply #19 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.

Logged
Scott AKA "Skyking" Holtzman
River Delta Audio is now:

Ghost Audio Visual Solutions, LLC
Cleveland OH
www.ghostav.rocks
Pages: 1 [2] 3 4   Go Up
 


Page created in 0.113 seconds with 20 queries.