Networking notes - Layer 2 mostly

From Helpful
Jump to navigation Jump to search

For other network related things, see:


Also:

📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense.


✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Switches, routers, hubs, bridges, etc.

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

LAN, Broadcast domain, LAN segment, collision domain

Reducing broadcast domain size

DHCP notes

See also:

  • RFC 1541, Dynamic Host Configuration Protocol (deprecated by 2131)
  • RFC 2131, Dynamic Host Configuration Protocol updated by:

Bridging notes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Bridging mostly means repeating packets between two LAN segments, at layer 2.


Bridging can be contrasted with routing

Routing means two separate segments, a node that has an interface on both
and and some explicit routing-rule reason to send each packets between them (or not to).
Bridging copies basically all traffic
making them look like the same network in most any way that matters
it's hard to determine that there is a bridge in a network at all.
(though yes, various bridges can be told to filter traffic, but only using layer 2 criteria)


Bridges can be distinct devices, but is probably more usually done with different ports on a switch, or two NICs in a host.


What bridging code does with each frame depends on its ARP table. Basically, if the bridge knows a packet is already on the right side, it won't copy it to the other:

  • if the MAC is on the same side of the bridge, it ignores the frame
  • if the MAC is on another side of the bridge, it sends it there
  • if the MAC is unknown, it's sent to all parts of the bride
...and we would usually get some ARP packets that lets us do better soon
  • if the MAC is us, it's passed to our own network stack (usually IP)

(You can inspect details: brctl showmacs br0)


Bridges speak STP to other bridges, so that you don't get weird loops and such.


The bridge itself does not need to participate in the network, but it can if you see some reason.

For example, in linux I usually configure the bridge device for DHCP, which I do so that I can log in remotely via SSH without needing a third NIC just to participate on the network.


The effects of using linux as a bridge (rather than choosing a hardware bridge):

  • you can use firewalling
  • you can monitor the traversing traffic
  • you can use traffic shaping ((verify))
  • the bridge can participate in the network (however...)
  • the bridge can eat CPU on busy networks, because it handles pretty much all traffic it sees (NICs have to be in promiscuous mode)


Manual setup: 

brctl addbr br0           # create bridge interface, arbitrary name (this is just a convention)
brctl addif br0 eth0      # add interfaces you want to bridge
brctl addif br0 eth1

# in case your node was not set up for routing before, you may want some of:
echo 1 > /proc/sys/net/ipv4/ip_forward
for devfile in br0 eth0 eth1;
do
  echo 1 > /proc/sys/net/ipv4/conf/${devfile}/proxy_arp;
  echo 1 > /proc/sys/net/ipv4/conf/${devfile}/forwarding;
done;

# if running multiple or redundant bridges on the same network, you likely want STP:
brctl stp br0 on
# you can inspect STP details with:
brctl showstp br0

# As for IP configuration, you likely want none on the bridged interfaces
ifconfig eth0 down
ifconfig eth1 down
ifconfig eth0 0.0.0.0 up
ifconfig eth1 0.0.0.0 up

# If you want to be able to connect to the bridge via SSH (or anything else),
#  then configure an IP on the bridge interface itself.
# In practice it may be preferable to configure DHCP. For manual config:
ifconfig br0 192.168.1.222 broadcast 192.168.1.255 netmask 255.255.255.0 up
# and possibly:
route add default gw 192.168.1.222


Automatic, debian/ubuntu /etc/network/interfaces 

auto lo br0
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

# Bridge setup
iface br0 inet dhcp
    bridge_ports eth0 eth1


Notes:

  • The bridge will drop all packets for (by default) the first 30 seconds. This is meant for complex topologies, to avoid creating loops before STP can resolve them. (note: forwarding delay is enabled even when STP isn't) (verify)
    • When you know this won't be a problem (e.g. when you make a single bridge on your home LAN), you can lower or disable that delay. For example, to disable (for the debian-style config, look at up (post-up):
brctl setfd br1 0
  • when there is any possibility of creating loops, enable STP:
brctl stp br0 on
  • sethello 10


  • bridging with WiFi devices is possible but apparently somewhat complex
  • The bridge will take the MAC of one of its members (presumably the first?(verify))


Inspection

MAC knowledge of the bridge: 

brctl showmacs br0


http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section2

http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO-3.html

-->

Fancier setups

https://wiki.debian.org/NetworkConfiguration#Bridging


Monitoring

Errors

Add bridge failed: Package not installed

You don't have kernel support for bridging.

Compile it in. It should be in 'Networking' → 'Networking options'.

can't add ppp0 to bridge br0: Invalid argument

Typically means that interface can't carry Ethernet.


See also (bridging)

Semi-sorted

Glossary

  • NIC - Network Interface Card. Used whenever it's not a given that a single computer has only one connection (and in documentation).
  • interface usually refers to how drivers provide (and how software uses) a NIC. Regularly used synonymously with NIC.
  • adapter - Regularly used synonymously with NIC.
  • node - usually means 'a single box of hardware', or something else coherent enough to be seen as a single actor. May have multiple NICs (that are or aren't related to each other). Examples include computers, routers, and more.
  • frame, packet, segment, PDU
    • Theoretically/formally, frame means layer 2, packet means layer 3, segment means layer 4, and the generalizing term is PDU)
    • In practice, the terms are fuzzy and there is no hard difference, except that 'frame' suggests lower layers (physical and link) and 'packet' suggests higher levels (layer 3 and above).

On MACs and EUIs

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

MAC address (Media Access Control address), is a 48-bit address.

It is now more specifically called MAC-48, or rather EUI-48 (because there's now also a 64-bit variant, see below).

Also commonly called something like hardware address, adapter address, physical address, Ethernet Hardware Address (EHA) and probably some others - because those were common uses.

Mostly known for its use in Ethernet cards, and actually somewhat broader: some other IEEE 802 networking requires use of MACs in the frames, including 802.11 (WiFi), IEEE 802.5 (token ring). Others use it, including Bluetooth, FDDI, Fibre Channel. ATM also uses it.



EUIs are a somewhat wider concept.

They are used by used by software and non-networking hardware.

From that perspective, EUIs are also MACs when they are used by networking hardware as node identifiers.

Since they are assigned from the same numbering space, not many people or situations really need to care for the distinction.


The newer 64-bit addressing is usually called EUI-64 (not MAC-64).

EUI-64 is used by FireWire, ZigBee/802.15.4, can be used in IPv6.


Most real-world MACs are enumerations within company-specific ranges, and companies assign each within their range at most to one physical device, which makes MACs globally unique.

There are also some MACs that are purely local - much like IP private net addresses are local (and independent from the same used in an unrelated network).


Further notes:

  • MAC-48 - the original scheme (IEEE considers MAC-48 an obsolete term)
  • EUI-48 can be seen as a later standardization(verify)
  • The 48-bit addresses is typically split either into:
    • 24 and 24: a 24-bit OUI (Organizationally Unique Identifier) with a 24-bit identifier from the organization
    • 36 and 12: a 36-bit IAB (Individual Address Block) or OUI-36, with a 12-bit identifier from the organization
    • ...there are a few exceptions to this in practice, though
  • EUI-64 is a larger address space
    • ...also a superset of EUI-48: there is a simple rule for converting existing EUI-48s to EUI-64 (in which you can actually distinguish between EUI-48 and MAC-48 -- middle octets are FFFE and FFFF, respectively -- though RFC5342 notes that IETF uses FFFE for both sources.


In the 48-bit addresses (what about EUI-64?) there are two special bits:

  • bit 0 (highest bit)
    • 0 means universal - assigned though OUI/IAB system
    • 1 means local - if MAC was assigned based on administration on the local network
  • bit 1 (second-highest bit)
    • 0 means unicast
    • 1 means multicast (special handling, used in ethernet, FDDI)


See also:

ARP

ICMPv6

NDP

Spanning trees

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The Spanning Tree Protocol (STP) is a layer 2 protocol that ensures a loop-free topology.

It is a thing that switches do, mostly automatically but often requiring a little thought and planning.


For context:

Routing is often based on 'if it meets this rule, then it goes there' type rules.

With which it is not impossible (or necessarily hard) to create a situation where packets will passing the same place twice, which will also be a problem.

In a lot of situations there are basic ways to avoid that with some in-the-moment manual cleverness.

But that often means that things will just break later, when network grows and topology changes happen in ways you didn't plan.

But also, consider like redundant cabling for fallover.

If you were to bridge those two links together, that would actually be a switching loop: data incoming on one would be sent out on the other, which effectively duplicates it and effectively floods the network.

Switches could choose to disable ports that seem to send back everything they get, to avoid a basic feedback problem, but that only solves the flooding part.

Without any reason for it to be enabled later, that does not describe failover.



So instead, STP and its variants collect information about all all the links in the mesh that is the network, calculates a spanning tree (connects everything without loops) (prefering links with higher bandwidth).

This means we can know exactly what links to disable -- everything not part of that spanning tree.


It also keeps collecting and updating this information, so that it can.

This lets you connect things whatever way you want, including bridge-style redundant links with automatic fallbacks onto the spare/redundant link, without causing the flooding problem.


The fact it works transparently means data centers can (re)organize their cabling without panicky downtime when you yank a cable. Yes, guaranteed-delivery protocols will see a momentary bump in latency, and fire-and-forget protocols may lose a few packets.



BPDU[1] refers to the packets that communicate STP information.




See also:


Wake On Lan

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
Hardware-wise
  • On-motherboard Ethernet that supports WOL should just work
  • PCI cards
    • may need a cable, which signals the motherboard to boot. Not all motherboards have such a connector.
    • PCI 2.2 can send it via power management events (support may vary?(verify))


Configuration:

  • PCs: Your BIOS should mention Wake on Lan (or some similar wording), usually in a power-related part of the BIOS.
  • Macs: ?


Triggers

Include...

  • Magic Packet (most common)
    • Contains the MAC address of the computer to wake, typically broadcast on the subnet that host is on
    • When WOL configuration doesn't mention ant of this list, it'll likely be Magic Packet.
  • Specified pattern within packet
    • like magic packet, but configurable
  • SecureOn(verify), which is like Magic Packet, but adds 4 or 6 extra bytes to match
    • that password (-of-sorts) is not secure against eavesdropping. It seems mostly intended to make accidental waking and brute force waking harder(verify)
  • Link Change (e.g. "computer tuns on when you plug its LAN cable into a switch"(verify))
  • There may be further options, e.g. reacting to specific types of traffic, but this is often impractical.


On Magic Packet, and the variant with a "password"

A magic packet is any layer-2 packet that contains:

  • a synchronisation stream, meaning six 0xFF bytes, directly followed by...
  • sixteen copies of the target NIC's MAC, in binary form (6 bytes each)
    • in part to avoid being a runt?
    • I've seen code with more than sixteen copies of the MAC, which works just as well (though may conflict with the password feature).
  • Optional: If both the NIC and the packet sender support passwords, this means that 4 or 6 pre-determined bytes should follow the above sequence.

The above sequence is allowed to appear anywhere in the packet - presumably so that WoL-capable NICs can completely ignore protocol encapsulation and just match this 102-byte sequence anywhere. (verify)


While NICs only look at all layer 2 packets they get, it is

  • usually Ethernet frames, because that's what most end networks use
  • usually IP, convenient for its routing
  • often UDP/IP, because it's a connectionless fire-and-forget protocol
(regularly UDP/IP broadcast -- related to routing behaviour, see below)
  • regularly on port 7 or 9 (or sometimes 0), primarily because they are unused ports you can use (forward) for this specific functionality (and even if they are used it's fine, because historically port 7 is echo, 9 is discard)


Networking / routing, in general and particularly for web based WOL

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Broadcasting is simple enough for same-subnet WOL, but things get more complex when you send WOL packets between subnets, which includes using web-based tools for WOL.


In general, your options for getting WOL packets where you want them to go, depending on your networking details, include:

  • broadcast the packet within the subnet
    • usually the easiest option within the same subnet
    • however
      • most network stacks will only create such a packet so if they are themselves (currently) configured to be on the subnet mentioned in the packet (for fairly good reason)
      • devices acting as routers (and, in some cases, bridges) tend to filter out broadcast packets; broadcast packets won't work between (sub)nets (again, for fairly good reason)
  • Get a host on the target subnet to generate a broadcast packet for you. A number of modems/APs can do this, or be easily made to. Other always-on hosts (e.g. LAN servers) can be helpful too, and sometimes more flexible.
  • using a routable unicast packet for a specific host (unicast)
    • requires the router to have a static ARP entry for the target (because without it, that router will consider the packet non-deliverable when the host is off)
    • for LANs with private IP addresses, this also means a forwarding rule (which itself means one port can serve at most one host)
  • use VPN as a way of belonging to the specific subnet - which can in some situations be an easy solution, but requires the VPN endpoint to always be active. If that's your modem/AP that's easy, but that may be harder to configure than VPN in general.


Slightly more concretely, assuming you want to use IP for routing between subnets, you have roughly these options:

  • route as unicast to the intended host
    • depends on a static ARP entry (one for each WOL-wakeable host) so that the host is considered routeable on that subnet when the host is off
    • you must know the IP at sending time (not all WOL clients let you do this)
    • if you are on a private-IP subnet (10.*, 192.168.*, 172.16-31.*) this won't work as-is; you'ld need to...
  • route as unicast, forward (DNAT) all use of a single port to a specific host
    • doesn't require you to know the IP, works for private-IP subnets
    • requires a forwarding route per host
    • requires that host having a non-changing IP (usually; depends on WOL-related features of forwarder)
    • needs a static ARP entry (per host) so that the host is considered routable on that subnet even when/though it is off
  • route as unicast until you get to the target network, then rewrite into a broadcast
    • Most devices and network stacks won't forward (DNAT) to a broadcast address, so you can rarely do this using just port forwarding (It's too easy to do bad/stupid things this way. A few devices are not clever enough to realize the risk, and allow it)(verify)
    • ...so usually needs a program to be the endpoint for WOL, and broadcast them locally - fairly easy to write, but it needs to be on an always-on host


WOL senders

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

It's easy generate magic packets - given socket-level networking. It takes at most a few dozen lines of python, perl, ruby, PHP, etc.

For example, in python: 

def broadcast_wol(mac, password_bytes='', ports=9):
    ''' Locally broadcasts a Wake-on-LAN packet (Magic Packet) with the given MAC.
        Arguments: 
         mac             should be a string. Will be stripped of everything not [0-9A-Za-f], 
                         so you can use most any form of MAC strings.
         password_bytes  if used, should be a bytestring
         ports           can be an integer, or iterable of integers, e.g. [7,9]
    '''
    import socket,struct,re

    #Remove all but hex so that we're robust to MACs with separator characters
    mac=re.sub(r'[^0-9A-Za-z]','',mac)
    if len(mac)!=12:
        raise ValueError('%r does not look like a valid MAC address'%mac)

    # Construct packet in hex form. It's easier and a little more readable
    hex_data = 'FF'*6
    hex_data += mac*16
    packet_data = hex_data.decode('hex_codec')  # ...then turn into the bytestring we want
    packet_data += password_bytes
    
    # Use low-level socket interface to broadcast the result via UDP
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)    # UDP socket
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) # Broadcast socket
    if type(ports) in (int,long):
        ports=[ports]
    for port in ports:
        sock.sendto(packet_data, ('<broadcast>', port)) # '<broadcast>' refers to INADDR_BROADCAST, 255.255.255.255


Apps include:

Web services include:

NIC, protocol address, and name resolution

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

There are different things that resolve.

Ethernet and IP; ARP

Say our LAN is Ethernet, as most are.

The unit of communication at ethernet level is the ethernet frame, which has a source MAC and destination MAC, where MAC is unique identifier for a physical network device (and one of its ports, if it has multiple).


When you want to send to another ethernet node, you must first learn that unique identifier.

There were a few different ways of doing this, all of which amount to lookups of something more convenient than MACs, but we generally landed on doing everything with IP - so IP's addresses became central to a lot of things.


ARP is the glue between ethernet addresses (layer 2) and IP addresses (layer 3). Conceptually, ARP consists mostly of two messages:

"hey guys, what's the MAC for this IP address?"
"that would be me - this IP and this MAC"

And yes, this is a specific case of two layers interacting (typically avoided where possible).


For hosts

The above are broadcast messages, meaning everyone gets it - at least within the same Ethernet segment (which typically corresponds to an IP subnet). This means

you don't get all the world's ARP messages, which is sane and good
that you need a way to send messages to other ethernet segments
which is mostly solved at IP level -- but relevant in some of the below, means you'll have an IP (and soon the according MAC) usually used for "all other traffic".


For networking hardware

An ethernet node isn't necessarily aware of IP.

In particular for networking hardware. Before switches were the norm, you had hubs.

Hubs were Ethernet-only and not IP-aware - and didn't need to be, remember how layers make life simpler. But because it doesn't know on which port the target host is connected, it just duplicated all incoming ethernet frames on all other ports.

Hubs aren't made anymore, because IP-aware ethernet switches are much more efficient, and very little extra effort.

These will listen to ARP responses, and can ignore the IP part, because they just want to learn which physical port answered "that would be me" with the relevant MAC.

Switches act like hubs only for packets where the destination MAC isn't yet known to be on a port. Which is fine, both because that's a small part of all traffic, and because they will typically learn it very soon.


Uses and abuses

Beyond making IP over ethernet work, there are ARP-related tricks and attacks, such as

  • having multiple IPs on a physical port
  • having multiple hosts have the same IP
though only under very specific conditions
  • claiming all unused IPs for sniffing purposes
  • sending many random ARP responses, implicitly flushing real entries out of the limited-size ARP tables
bsically reducing the switch to a hub, making it easier snoop on traffic from hosts that are not the packet's actual target (but only from another host on the same switch/segment).
  • learning the IP of the gateway, then sending around ARP asnwers with incorrect MACs
so that you're the only device left for which IP routing still works.


A lot of these are possible because ARP is connectionless and stateless, implying answers without questions are trusted. ARP spoofing is abusing that fact.

There are switches that alleviate many of these attacks, because some things (e.g. a port basically claiming to have thousands of hosts) are pretty easy to detect.



Server names; DNS

Name to IP address resolution that particularly enables you to use human-rememberable names in your browser address bar (but can potentially serve anything IP-based), is actually fairly unrelated to basic networking. IP numbers are used for actual communication, and this service simply tells you the IP(s) for a name.

In fact, there are tricks that allow one IP to have multiple names, one name to cycle though pointing to various nodes (a type of load balancing),

There are other ways to do the same resolution step, for example the hosts file on at least unices (/etc/hosts) and windows (I'm not sure the location is the same, search for it) which essentially hardcodes a name to an IP address. This can interfere when incorrectly used, though. Some protocols, such as SMB (windows sharing / CIFS / samba) also allow netbios, wins and lmhosts to provide adresses for names - IP or netbios.


Netbios names; WINS

In some way analogous to both of the above are netbios names. Netbios was used by the early windows versions to provide naming on local networks without DNS. NetBIOS names work something like ARP, but a level higher.

NetBIOS could also be used on top of IPX/SPX, but is used with IP the resolution system is WINS, which resolves NetBIOS names to IP addresses. There is an lmhosts file that allows you to hardcode these. This is used in file sharing based on UNC paths, in which you can use IP address as well as netbios names.

Packet size, MTU and MSS, fragmenting

On the wire, the packet/frame's size is everything together, though people often list a size at the layer they are dealing with, or most commonly deal with.


Classical Ethernet's frames are at most 1518-byte things, with 18 bytes for its own purposes, so each IP packet put inside it can be at most 1500 bytes.


MTU (Maximum Transferable Unit) and MSS (Maximum Segment Size) refer to upper limits to sizes.

MTU refers to the encapsulated whole,
MSS refers to how much payload is in it.


Strictly speaking, neither term is tied to a layer(verify), which means one layer's MSS is another's MTU, which can get very confusing if you don't mention what layer we're talking about.

In practice

  • you can often guess from context,
  • nine times out of ten we're thinking at at IP level.

Say, 1500 byte MTU size and 1460 byte MSS size very much suggests you are talking about IP over ethernet, and TCP/IP over Ethernet, respectively.



While we often think of IP having an MTU of 1500, this is more about typical backwards-compatible LANs, and the internet, than about the IP protocol.

Technically, IPv4 has a maximum packet size of 65535, though no one really wants to use that, in part because over almost any real network it will get fragmented, and partly because the effectiveness of IP's CRC checksum becomes low when you go over ~11K (see [2]).

On a gBit LAN, though, jumbo frames of something like 9000 bytes can more easily bulk-transfer close to 1gBit than without it (at best, it also depends on other efficiency issues, including the program/protocol's cleveness).

...but if not all switches and hosts support jumbo frames, they will probably get dropped.


Using 1gBit at full speed with 1.5k frames means ~80kpackets/sec, which means a lot of driver overhead, and in one-packet-per-interrupt setups is actually quite heavy (interrupts by their nature have to pause other work, so make for general sluggishness). Jumbo frames are one way to lessen that, but in the real world often only help a little -- and if not all hosts and routers along the path support and are configured for it they may fragment or just drop packets, meaning little help or no function at all.

Other offloading methods tend to work better (and most are standard now).


See also:


Fragmenting means data packets (usually network layer) are too big for a lower layer's frames (usually link and/or physical layer, since they are most likely to impose size limits) and need to be split up before they can be sent.


Usually there is a common maximum transmission unit (the MTU, for ethernet it's 1500) that cannot be exceeded at all, or can't be without all parties agreeing about it. That is, when packets are too large for a particular link, packets are automatically fragmented into smaller ones (or just rejected) and reassembled on the other end of that link. The data arrives, but more work has to be done, and transmission time is wasted.

Fast Ethernet can be set up to 1546, gBit ethernet up to 9000. The internet used to have 576 in the modem days, but is mostly at 1500 now(verify). And, frankly, all of those are rather low for anything faster than slow broadband. (But unless raising it is standardized across the board, it is pointless as it would just lead to fragmentation) Incidentally, the overhead involved in decoding and ACKing more small frames rather than fewer big frames has been shown to be considerable; one of the reasons for larger MTUs. See e.g. [3]


Fragmenting also happens when you tunnel protocols via higher level layers: what you do is wrap lower-layer packets into a higher layer packets, adding some extra size through the encapsulation. If the packet was exactly right for the MTU before, it will now fragment into one fully used frame and one almost empty frame.

In this sort of situation, it's best to set the MTU for the interface that is in reality tunneled lower (say, 1450), to avoid that inefficiency.


On congestion

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


QoS

In a broad sense, Quality of Service (QoS) is the concept of trying for certain types of guarantees, in telephony as well as in data networking.

Apparently the term QoS was first used in ITU X.902, but the term is used in various standards now, with varying and sometimes broad definitions.


The guarantees are often something like low latency, low latency jitter (e.g. for VoIP, videoconferencing), guaranteed bandwidth (e.g. for TV over IP), and such.


Approaches

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


TOS

A common trick when using IPv4 is to use the TOS byte in its header, which was never used much. It is now used to encode data to support:

  • Differentiated services (also 'DiffServ'); the QoS needs map onto this fairly decently
  • Explicit Congestion Notification (ECN)

Fancy(-ish) routers support this, as do modern unices and some recent windows implementations.


See also (QoS)


TODO: read:


VPN

See VPN notes


Link aggregation

VLANs

On encryption

Things like encryption can be done at every level above physical{[verify}}.


TLS/SSL security, in the IP sense, is snuck in between layer 4 and layer 5 by making it part of the layer 5 protocol, inside/under the real protocol (In the 7-layer view on IP, this can be said to be in multiple cooperating layers, mostly layer 6)

This usually means there is often a non-secure and a secure version of the same protocol defined at layer 5.


IPX, SPX, NWLink

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

IPX (Internetwork Packet Exchange) was a layer 3 protocol fairly commonly used up to the mid-nineties (which is approximately when the IP stack started replacing it, partly just because of convenience. (Note that while IP has a similar role to IPX, the two names and technologies are not particularly related).

SPX is a layer 4 protocol used on top of IPX.

Windows later added NWLink, which was an implementation of SPX/IPX, and NetBIOS on top of that.


IPX was commonly used for Netware, and by various DOS-era games.

NetBIOS was often transferred over IPX/SPX, and more recently also by TCP/IP (and more recently used primarily for SMB file sharing, which is currently done mostly over IP instead).


These days, IPX mostly matters to people wishing to play old games. IPX in DOS was a somewhat complex matter to set up. NWLink was supported from Win95 up to WinXP, but was dropped in Vista.

People report that in 32-bit vista, you can copy in XP's (32-bit) drivers (see things like [4]).

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Unsorted


Where to find nice images like: http://www.javvin.com/links.html ?


An IP-stack socket is effectively a 5-tuple: (protocol, local_address, local_port, remote_address, remote_port)




physically identify a card you have the name of

ethtool -p eth1

Steadily blinks LEDs on port


(in my case also used a different color -- ports tend to be two two-color LEDs)


Channel bonding

See also (general)


  • 802.3u is Fast Ethernet (100Mbit), 802.3ab is gigabit ethernet over copper, 802.3ah added gigabit over fiber
Retrieved from "https://helpful.knobs-dials.com/index.php?title=Networking_notes_-_Layer_2_mostly&oldid=92146"