Quantum Networking (Part 3)

Welcome back.

Up till now we discussed a lot of ideas about IP addresses and subnetting,

but, now let’s look at some specific ways to understand and troubleshoot a problem in the real world.

Two very useful tools for troubleshooting IP addressing and problems with subnets

are actually built into the windows environment.

The PING command can help assess basic network connectivity.

This can be called executed from the windows command prompt.

You can PING a specific IP address and confirm there’s a reply from that address.

Remember those OUIs we discussed before?

You can look at the address resolution protocol (or ARP) table on your machine

as well to confirm the correct piece of hardware actually replied.

If you know the full MAC address or at least the OUI of the manufacturer you expect,

you can make sure the correct MAC address is associated with the IP address in question.

This is especially useful in finding duplicate IP addresses on a network.

If you know a device has a certain IP but the MAC address doesn’t look right,

then another device most likely has been assigned that IP address as well.

Let’s take a look at another example.

Say I’m on a typical Q-SYS project site, where I have a wired connection to the Q-SYS network

and a wireless connection to the end user’s guest network for email, chat etc.

Let’s say the Q-SYS core is set up with the IP address 192.168.2.2 with a subnet mask of 255.255.255.240.

I set my computer’s wired connection manually to 192.168.2.17 with the same netmask as the core.

As a preliminary network connectivity test,

I PING the core from the windows command prompt and I get a ‘destination host unreachable’ message.

Why don’t I get a response?

If I look carefully at the subnet mask (or just use a subnet calculator),

I can see that the subnet of the Q-SYS Core has a valid range of 192.168.2.1-14,

so 17 is out of the allowable range.

And if I look closely at what the computer is doing,

I’ll notice that the PING request isn’t even being sent to the Q-SYS network.

It’s actually being sent to a wireless pathway to the internet,

as that’s how the operating system handles traffic to other subnets.

It attempts to route them.

That's because IP routing is a technology that operates at OSI layer 3.

It makes use of routers to connect LANs on different subnets,

or LANs to Wide Area Networks (WANs) or the internet itself.

This layer 3 routing technology is what allows us to reuse these private address schemes

all over the world (in our cities if you will) while still allowing access to the internet.

A router has an internal address, known as the ‘gateway’ address, and an external address.

This may be a router directly connected to the internet where all addresses are distinct,

or may be connected to a LAN of routers that are connected to other routers.

Many packets routed to the internet are routed many times before actually reaching their destinations.

Routers communicate to the outside world on behalf of all the devices on its LAN side.

They inspect and route the replies from the outside world back to the appropriate device on the LAN.

For the devices on the private side of a router to connect to the public side,

we need to specify a third parameter in the IP configuration – the gateway address,

which represents the private address of the router itself.

There are a couple of things we need to be careful of when specifying a gateway address:

A) it needs to be a valid private router address,

and B) That address must be on the same subnet as the device itself.

Let’s look at an example: Let’s say a device has IP address 192.168.1.101 and it's on a class C subnet.

We specify a gateway of 10.36.121.7.

That’s problematic, as we thenn would need a router to talk to the specified gateway,

which IS our router address.

We need to make sure the gateway address is directly accessible by the device we’re configuring.

Very often, the gateway is either the first or the last available address on the subnet in question.

One other note – specifying a gateway is NOT mandatory.

If a device is on an isolated network and doesn’t need to communicate with devices on another subnet,

there is NO NEED to define this at all.

You can actually run into some subtle problems if you pick an address that isn’t a valid router.

And now that we’ve discussed the basic parts of configuration,

let’s look a little more closely at exactly what a router does.

Let’s say I have my lonely little computer who would like to browse the internet.

The computer uses another technology (that we’ll discuss later)

to find the website it wants to access is hosted at address 98.139.80.80 on the internet.

The computer passes the packet bound for that address to the gateway address of the router.

In the simplest systems, the router takes the packet and replaces the private source IP with its public IP address

to pass through the network of routers and relays that comprise the cloud.

The reply from the destination address will be sent to the router’s public IP.

The router will then pass the reply back to the original requestor on the private side.

This is often referred to as Network address Translation or NAT.

It comes in a number of forms, but this is how it works in the general sense.

Note that there are many schemes for IP routing, but the basic concepts are the same – you’re sending packets from one subnet to another with the router as a go-between.

Now, we’ve talked about the need for IP addresses on the network,

but we haven’t yet discussed how those are configured on the devices themselves.

There are a few different possibilities here.

In general, there are two models:

Automatic IP addressing, which means the user doesn’t need to do anything to assign one.

The most common protocol for this is the Dynamic Host Control Protocol, or DHCP.

Using this model, a device requests an IP from a machine on the network that serves as a DHCP server.

The server manages the addresses of each device and makes sure they each get the right configuration,

including subnet mask, gateway address, etc.

The BOOTP protocol is an older dynamic addressing protocol that works in a similar fashion.

It’s most commonly used by older embedded networking devices.

Most modern DHCP servers will respond to BOOTP requests.

If a device is configured for an Automatic IP addressing and there’s no DHCP server on the network,

it will often use the APIPA scheme to assign one itself.

If you see an IP address starting with 169.254 this is most likely the case.

These are defined as Class B networks.

If a device receives no reply from a DHCP server and it supports APIPA,

it will send out a broadcast that says

‘Hey, I’m thinking about taking on this address in the APIPA scope, does anyone object?’.

And if another device doesn’t reply saying it already has that address, it assumes it’s safe to use.

If it does get an objection, it will repeat with a different address.

And then finally, Static addressing means the user must know what the IP of a device should be

and enter it manually along with the subnet, etc. in the device's configuration.

Let’s have a look at how these configuration options apply directly to a Q-SYS core.

If we look at a core configuration in core manager, we see the mode,

whether static or automatic for each Q-SYS network interface.

Core manager shows us the MAC address of each Q-SYS interface as well.

The Link Layer Discovery Protocol,

or LLDP shows us the MAC of the switch port to which the interface is connected.

For interfaces in ‘Auto’ mode with no DHCP server, we see the APIPA support here.

Note Q-SYS devices are configured as ‘Auto’ out of the box,

so it’s very common to see this until other configuration options are used.

The gateway address will be used to communicate with other subnets.

Note that only ONE gateway should be configured for the combination of all interfaces.

We’ll explain why later.

We have one additional configuration option that should be discussed.

The Domain Name (DNS) Server or DNS configuration.

A DNS server is a computer who translates domain names (such as QSC.com)

to IP addresses so that devices know how to address a packet.

If set to “Auto”, the DHCP server will provide the DNS server information to the interface in that case.

If it isn’t assigned automatically or if the interface is in ‘Static’ mode,

it must be manually enabled and have servers manually configured.

If manual DNS configuration is needed, consult the network administrator for the correct address. As a troubleshooting measure, you could try a Google DNS address.

Google’s DNS servers, 8.8.8.8 and 4.4.4.4 are always good bets when manually configuring devices.

So, when do you need a DNS server?

Well, hosted SIP providers will typically provide a domain name rather than an IP for registration,

so that’s one example.

Others are NTP time servers who sit on the internet to keep devices synchronized.

Alright let’s take a break here, before we start talking about different types of network traffic.