Quantum Networking (Part 5)

Welcome back.

Let’s remind ourselves of what happens in the OSI model.

Layer 1 makes our physical connections, and Layer 2 makes use of MAC addresses to transmit Ethernet ‘frames’.

And then layer 3 allows us to transmit packets, make use of IP addresses, routing and multicast protocols.

There’s one other aspect of layer 3 that comes into play with time-sensitive audio and video protocols:

giving packets a marking that indicates their priority on the network.

This is something we discuss a great deal in Q-SYS networking and troubleshooting.

The DSCP marking, which stands for Differentiated Services Code Point,

is a marking in each packet that can help the infrastructure prioritize delivery of certain packets over others.

Let’s say someone just sent a giant email with a cat video…

well, we wouldn’t want that email to stop or disrupt the audio to or from our videoconference.

The infrastructure can use the markings of PTPv2 and Q-LAN audio traffic from Q-SYS

as a way to know to prioritize those packets over others.

We ask that the packets be prioritized on the network using a ‘strict priority’ queuing model.

Note that DSCP values have a ‘name’ and a decimal value.

Different switches use different methods to configure prioritization.

A table like this can be very useful in making sure you know which name maps to the decimal value.

PTPv2 and Q-LAN are protocols that require both low latency and

jitter to be successfully implemented on a given network.

For example, Q-LAN packets must arrive in less than 280ms to be considered ontime.

We do recommend that PTPv2 and Q-LAN audio packets are the highest priorities on the network.

The feature set required on the switch to allow this prioritization is called Quality of Service, or QoS.

We’ve now covered the pertinent features of the media layers of the OSI model.

You can see that this is the real workhorse of the Ethernet model.

While the media layers determine how it gets there,

layers 4-7 determine how devices communicate on a higher level.

Layer 4, the transport layer, for example

determines if and how connections between devices are supervised

and how a device handles multiple services at once.

There are two major categories of traffic in the transport layer:

The user datagram protocol (or UDP) and the transmission control protocol (or TCP).

UDP is considered connectionless in the sense that there is no assurance

that the intended device received a given packet.

Sender, receiver and infrastructure are all on the honor system to deliver the communication.

On the other hand, when TCP is used, a supervised connection is negotiated before any data is even sent at all.

The transmitter tells the receiver how many packets they should receive

and how big each packet should be.

The receiver then confirms that each packet was received properly.

Although not supervised, UDP packets are good for rapid transmission (like Q-LAN, for example).

A Q-LAN stream consists of 3000 packets per second.

It would introduce a lot more processing overhead to have the sender tell the receiver

before sending every packet and the receiver confirming that every packet got there.

TCP is great for things like file transfers where you want to make sure every bit got there,

but you’re not terribly worried about how fast the transfer occurs.

Another important concept included in the transport layer is the idea of network ports.

Almost every networked device handles a number of different services and applications at once.

Think of a network port as a receiving dock in a large warehouse.

There might be twenty different ports

and each truck must be told where to drop off its merchandise so it gets to the right place.

This is the same for network traffic.

Every packet has a source port…the dock from which it left and a destination port,

the dock at which it should be dropped off. Ports are just numbers in this case.

Let’s look at an example.

Let’s say a computer wants to send a Q-SYS core a message.

Different services running on the Q-SYS core are ‘listening’ on different ports.

In this case the core is listening on port 8554.

If the computer sends a message to destination port 8551, that door is closed.

It’s as if the message wasn’t received as all, because it can’t be unloaded into the warehouse.

If the computer sends the message to a port that’s listening for the right service type,

we have a successful transmission.

The information in the packet goes into the right place and can be processed accordingly.

Many services, such as FTP, http, and other protocols have standard port numbers associated with them.

Here’s a list of many of the UDP and TCP ports used by various services supported by Q-SYS.

Feel free to pause here if you want to study these.

Next, let's take a look at a PCAP capture of an Ethernet packet that clearly illustrates

how all these layers fit together to form a cohesive package.

At layer one, we see how many bits and bytes are in the transmission. The ones and zeroes, if you will.

At layer two we see the source and destination MAC addresses.

At layer three, we see the source and destination IP addresses.

At layer four, we see the transport type, and the source/destination ports.

Finally, at layer five we have the data to be processed. This is called the ‘session’ layer.

When troubleshooting networking issues,

thinking in terms of along the OSI model is a good place to start.

We start at Layer 1 – is it plugged in? Right? Do we have normal LED activity on the switch?

Are we sure that the cabling is good and we have the expected connection speeds?

At layer 2, we might log into the switch and make sure that the switch is aware of the problem device.

A quick PCAP capture might show if there are any broadcast level packets from the device in question.

If you can ‘see’ the device in question or you can access it through other means,

well then check the layer 3 configuration of the device.

Does it have the right IP, subnet mask, gateway assignments?

Is this a case where IGMP is going to be required?

If so, is it enabled, is it working?

If we’re dealing with external control protocols, for instance,

we should confirm that the right type of socket is being opened.

Are the port numbers correct?

If TCP is being used, you should be able to tell if the connection is opened…if not,

well then you've got a problem.

If the connection is open,

well then maybe the formatting of the data that you’re sending is the issue rather than the network at all.

Alright, so... that is it.

That is a crash course in the basics of networking and network troubleshooting.

Thanks for watching!