Wednesday, January 16, 2019
Monday, January 14, 2019
SSL Inspection
HTTPS Inspection does not work on Following situations
- Certificate pinning
- Client certificate authentication
- Different ciphers used for TLS than are supported in HTTPS Inspection
- Where TLS 1.3 is required
For HTTPS Inspection in R80.20, there a couple things:
- Improved cipher support
- Support of outbound HTTPS Inspection with a Gemalto SafeNet HSM Appliance
- Support for use of both HTTPS Inspection and Categorize HTTPS Websites concurrently (at the moment, they do not work together).
Saturday, January 5, 2019
R80.10 CoreXL_Dynamic Dispatch
Introduction
CoreXL is a performance-enhancing technology for Security Gateways on platforms with multiple CPU cores. CoreXL enhances Security Gateway performance by enabling the processing CPU cores to concurrently perform multiple tasks.
On a Security Gateway with CoreXL enabled, the Firewall kernel is replicated multiple times. Each replicated copy, or Firewall instance, runs on one processing CPU core. These Firewall instances handle traffic concurrently, and each Firewall instance is a complete and independent Firewall inspection kernel. When CoreXL is enabled, all the Firewall kernel instances in the Security Gateway process traffic through the same interfaces and apply the same security policy.
The CoreXL software architecture includes the Secure Network Distributor (SND). The SND is responsible for:
- Processing incoming traffic from the network interfaces
- Securely accelerating authorized packets (if SecureXL is running)
- Distributing non-accelerated packets or Medium Path packets among CoreXL FW kernel instances - this functionality is also referred to as dispatcher
Traffic received on network interface cards (NICs) is directed to a processing core running the SND.
The dispatcher is executed when a packet should be forwarded to a CoreXL FW instance (in Slow path and Medium path - see sk98737 for details) and is in charge of selecting the CoreXL FW instance that will inspects the packet.
In R77.20 and lower versions, traffic distribution between CoreXL FW instances is statically based on Source IP addresses, Destination IP addresses, and the IP 'Protocol' type. Therefore, there are possible scenarios where one or more CoreXL FW instances would handle more connections, or perform more processing on the packets forwarded to them, than the other CoreXL FW instances.
This may lead to a situation, where the load is not balanced across the CPU cores, on which the CoreXL FW instances are running.
To help mitigate the above issue, CoreXL Dynamic Dispatcher feature was introduced in R77.30 Security Gateway.
CoreXL Dynamic Dispatcher
Rather than statically assigning new connections to a CoreXL FW instance based on packet's IP addresses and IP protocol (static hash function), the new dynamic assignment mechanism is based on the utilization of CPU cores, on which the CoreXL FW instances are running.
The dynamic decision is made for first packets of connections, by assigning each of the CoreXL FW instances a rank, and selecting the CoreXL FW instance with the lowestrank.
The rank for each CoreXL FW instance is calculated according to its CPU utilization.
The higher the CPU utilization, the higher the CoreXL FW instance's rank is, hence this CoreXL FW instance is less likely to be selected by the CoreXL SND.
The CoreXL Dynamic Dispatcher allows for better load distribution and helps mitigate connectivity issues during traffic "peaks", as connections opened at a high rate that would have been assigned to the same CoreXL FW instance by a static decision, will now be distributed to several CoreXL FW instances.
When CoreXL Dynamic Dispatcher is enabled, the dynamic decision is always made (even when there is no significant load).
Configuration on Security Gateway R80.10 and above
CoreXL Dynamic Dispatcher is enabled by default. Meaning, CoreXL dynamically assigns new connections to a CoreXL FW instance based on the utilization of CPU cores.
Instructions:
- To check the current mode on Security Gateway:
[Expert@HostName]# fw ctl multik dynamic_dispatching get_mode
Example output:
[Expert@R80.10:0]# fw ctl multik dynamic_dispatching get_mode Current mode is On [Expert@R80.10:0]#
- To Enable the CoreXL Dynamic Dispatcher on Security Gateway:
Note: In cluster environment, this procedure must be performed on all members of the cluster. Since a reboot is required, it is recommended to follow the Installation and Upgrade Guide - Chapter 'Upgrading ClusterXL Deployments' - either "Minimal Effort Upgrade" procedure, or "Zero Downtime Upgrade" procedure. - Run in Expert mode:
[Expert@HostName]# fw ctl multik dynamic_dispatching on
Example output:
[Expert@R80.10:0]# fw ctl multik dynamic_dispatching on New mode is: On Please reboot the system [Expert@R80.10:0]# - Reboot (in cluster, this might cause fail-over).
- Run in Expert mode:
- To Disable the CoreXL Dynamic Dispatcher on Security Gateway:
- Run in Expert mode:
[Expert@HostName]# fw ctl multik dynamic_dispatching off
Example output:
[Expert@R80.10:0]# fw ctl multik dynamic_dispatching off New mode is: Off Please reboot the system [Expert@R80.10:0]# - Reboot (in cluster, this might cause fail-over).
- Run in Expert mode:
Monitoring CoreXL load distribution
This section describes how administrator can monitor either the current CoreXL load distribution to decide whether to enable CoreXL Dynamic Dispatcher, or the CoreXL Dynamic Dispatcher in action (after it was enabled):
Note: To monitor the CoreXL Dynamic Dispatcher in action, it must already be enabled with fw ctl multik set_mode 9 command and Security Gateway must already be rebooted.
The examples provided below were taken from the machine without VPN blade or VoIP traffic and with disabled CoreXL Dynamic Dispatcher. These examples show an excellent reason to enable CoreXL Dynamic Dispatcher to mitigate the load imbalance between CoreXL FW instances:
- Check on which CPU cores the CoreXL FW instances are running with the fw ctl affinity -l -r command.
Example (CoreXL FW instances are running on CPU 1, CPU 2, and CPU 3):
[Expert@HostName]# fw ctl affinity -l -r CPU 0: eth0 eth1 eth2 CPU 1: fw_2 CPU 2: fw_1 CPU 3: fw_0 All: cpca status_proxy in.geod fwm cpstat_monitor fwd mpdaemon cpsead cpd cprid [Expert@HostName]# - Check the current CPU utilization by each CoreXL FW instance with the top command.
Note: If the output does not show all CPU cores (if 3rd line shows "Cpu(s):"), then press "1" and then "Shift+W".
Example (Load on CPU 3 is 24% by SoftIRQ; CoreXL FW instance 0 is consuming 18%; other CoreXL FW instances (fw_worker threads) are idle):
Tasks: 118 total, 3 running, 115 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 94.0%id, 0.0%wa, 1.2%hi, 4.8%si, 0.0%st Cpu1 : 0.0%us, 1.2%sy, 0.0%ni, 98.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 40.2%us, 9.2%sy, 0.0%ni, 49.4%id, 0.0%wa, 0.0%hi, 1.1%si, 0.0%st Cpu3 : 1.3%us, 1.3%sy, 0.0%ni, 73.3%id, 0.0%wa, 0.0%hi, 24.0%si, 0.0%st Mem: 4078484k total, 4021144k used, 57340k free, 241380k buffers Swap: 3140696k total, 64k used, 3140632k free, 414744k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15964 admin 18 0 1644 436 368 R 41 0.0 0:00.42 cp_logrotate 4129 admin 15 0 0 0 0 R 18 0.0 8:23.67 fw_worker_0 15954 admin 15 0 2176 1112 840 R 2 0.0 0:00.09 top 14 admin 10 -5 0 0 0 S 0 0.0 47:01.09 events/0 4995 admin 15 0 207m 66m 24m S 1 1.7 79:04.08 cpd 1 admin 15 0 2044 724 624 S 0 0.0 0:00.43 init 2 admin RT -5 0 0 0 S 0 0.0 3:08.83 migration/0 3 admin 15 0 0 0 0 S 0 0.0 0:02.15 ksoftirqd/0 4 admin RT -5 0 0 0 S 0 0.0 0:00.05 watchdog/0 5 admin RT -5 0 0 0 S 0 0.0 2:46.42 migration/1 6 admin 15 0 0 0 0 S 0 0.0 0:00.01 ksoftirqd/1 7 admin RT -5 0 0 0 S 0 0.0 0:00.36 watchdog/1 8 admin RT -5 0 0 0 S 0 0.0 2:36.56 migration/2 9 admin 17 0 0 0 0 S 0 0.0 0:00.24 ksoftirqd/2 - Check the distribution of connections across all CoreXL FW instances with the fw ctl multik stat command.
Example (refer to the "Peak" column - CoreXL FW instance 0 processed almost all connections, while other CoreXL FW instances were idle):
[Expert@HostName]# fw ctl multik stat ID | Active | CPU | Connections | Peak ---------------------------------------------- 0 | Yes | 3 | 1 | 21623 1 | Yes | 2 | 0 | 6 2 | Yes | 1 | 1 | 13 [Expert@HostName]#
Limitations
The CoreXL Dynamic Dispatcher is not supported in the following scenarios:
- Security Gateway is configured in VSX mode (not supported on any of the VSs, including VS0)
- SAM acceleration card is installed on the appliance
- Carrier Grade NAT (CGN) is configured
- Security Gateway is configured in Monitor Mode (per sk101670)
- 6in4 tunnel (SIT interface) is configured
- Some lines in the $FWDIR/boot/modules/fwkern.conf file are commented out (refer to sk106309).
The following types of traffic are not load-balanced by the CoreXL Dynamic Dispatcher (this traffic will always be handled by the same CoreXL FW instance):
- VoIP
- VPN encrypted packets
Additional known limitations:
- sk108894 - Difficulties in connecting to untrusted sites when both HTTPS Inspection and CoreXL Dynamic Dispatcher are enabled
- sk108856 - R77.30 cluster member might go Down after disabling CoreXL Dynamic Dispatcher only on one member
FAQ
- When should I enable CoreXL Dynamic Dispatcher?
Note: The thresholds given in this answer are approximate and should be suitable for majority of environments.
Administrator should enable CoreXL Dynamic Dispatcher if:
- A CoreXL FW instance consumes its CPU core at 85% (and above) even for 1 second.
- Other CoreXL FW instances consume their CPU cores at 75% (and below) - i.e., the difference in CPU consumption between overloaded and normally loaded CoreXL FW instances is 10% and more.
- When will Security Gateway benefit from enabling CoreXL Dynamic Dispatcher?
- When CPU load is not properly balanced, Dynamic Dispatcher will distribute the load equally between the CPU cores.
- Dynamic Dispatcher will mostly benefit on machines with large number of CPU cores (multi core machines). On machine with small number of CPU cores, the static hash distribution of traffic is good enough, and the benefit of enabling Dynamic Dispatcher is low.
Additional common scenarios, in which enabling CoreXL Dynamic Dispatcher will improve Security Gateway performance, are cases when traffic is dropped/delayed due CPU load on Security Gateway.
For example, during traffic peaks, during policy installation.
Refer to "Monitoring CoreXL load distribution" section. - Can CoreXL assign some connections statically and some connections dynamically?
By default, CoreXL assigns all connections statically.
If you fully enable the CoreXL Dynamic Dispatcher, then CoreXL assigns all connections dynamically.
In addition, refer to "Limitations" section. - Does affinity of interfaces change when enabling CoreXL Dynamic Dispatcher?
CoreXL Dynamic Dispatcher does not affect affinity of interfaces.
For information about affinity of interfaces when CoreXL is enabled, refer to sk98737 - ATRG: CoreXL - section "(4) Architecture".
Friday, December 28, 2018
fw monitor debugging traffic
If SecureXL is on, please turn off the secureXL
#fwaccel off // to turn it off
#fwaccel stat // to check status
#fw monitor -e "accpet host(srcIP) and host(dstIP);" -o filename.pcap
eg:
#fw monitor -e "accept host(17.16.202.89) and host(100.25.219.39) or host(100.25.219.39);" -o captures.pcap
#fwaccel on // to turn on SecreXL
Run below traffic captures at internal and external interface:
tcpdump -t -enni <interface_name> host Src.IP and host dst.IP
tcpdump -t -enni eth2-04 host + and host 208.94.8.8 -w filename1.pcap
fwaccel off
fw monitor -e "accpet host(17.16.202.80);" -o filename.pcap
fw ctl zdebug drop | grep 17.16.202.80
fw monitor -e "accept host(17.16.202.80);"
fw monitor -e "accept host(17.16.202.80);" -T -T is for time stamp
[fw_0] 20Dec2018 10:35:28.713159 eth2-04:I[200]: 17.16.202.80 -> 10.13.4.17 (UDP) len=200 id=2656 UDP: 24628 -> 9980 [vs_0]
[fw_0] 20Dec2018 10:35:28.713168 eth2-01:o[200]: 17.16.202.80 -> 10.13.4.17 (UDP) len=200 id=2656 UDP: 24628 -> 9980 [vs_0]
[fw_0] 20Dec2018 10:35:28.713175 eth2-01:O[200]: 17.16.202.80 -> 10.13.4.17 (UDP) len=200 id=2656 UDP: 24628 -> 9980 [vs_0]
[fw_0] 20Dec2018 10:35:28.720730 eth2-01:i[200]: 10.25.220.68 -> 17.16.202.80 (UDP) len=200 id=37057 UDP: 21416 -> 21898 [vs_0]
[fw_0] 20Dec2018 10:35:28.720749 eth2-01:I[200]: 10.25.220.68 -> 17.16.202.80 (UDP) len=200 id=37057 UDP: 21416 -> 21898 [vs_0]
I and i are for In
O and o are for Out
Upper Case I is for after Inspection
lower case i is for before inspection
Thursday, November 8, 2018
Troubleshooting Tools
Troubleshooting Tools
Take into consideration the following:
1. If you have a cluster, this command will show traffic flowing through the active firewall.
a. To check active status issue: cphaprob state
2. If you have SecureXL enabled, some commands may not show everything.
a. To disable SecureXL: fwaccel off
b. To enable SecureXL: fwaccel on
“fw monitor” command
fw monitor -e “accept host(x.x.x.x);”
Example
CP-Firewall> fw monitor -e "accept host(192.168.1.86);"
Compiled OK.
1-way network flow:
fw monitor -e “accept (src=x.x.x.x and dst=x.x.x.x); ”
Example (from 173.16.25.44 to 192.168.2.134)
CP-Firewall> fw monitor -e "accept (src=173.16.25.44 and dst=192.168.2.134); "
2-way network flow:
fw monitor -e "accept (src=x.x.x.x and dst=x.x.x.x) or (src=x.x.x.x and dst=x.x.x.x);"
Example (from/to 172.16.125.81 to 192.168.1.84)
CP-Firewall> fw monitor -e "accept (src=172.16.125.81 and dst=192.168.1.84) or (src=192.168.1.84 and dst=172.16.125.81);"
monitorfilter:
In this example, you can see the ingress interface (eth3) and the egress interface (eth1). Also, you can see the 4 capture points (iIoO):
pre-inbound i (lowercase i)
post-inbound I (uppercase i)
pre-outbound o (lowercase o)
post-outbound O (uppercase o)
You can also use set the capture points:
CP-Firewall> fw monitor -e "accept host(192.168.1.86);" -m iO
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_6] eth3:i[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
[vs_0][fw_6] eth1:O[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
- fw monitor
- fw ctl zdebug + drop
Take into consideration the following:
1. If you have a cluster, this command will show traffic flowing through the active firewall.
a. To check active status issue: cphaprob state
2. If you have SecureXL enabled, some commands may not show everything.
a. To disable SecureXL: fwaccel off
b. To enable SecureXL: fwaccel on
“fw monitor” command
fw monitor -e “accept host(x.x.x.x);”
Example
CP-Firewall> fw monitor -e "accept host(192.168.1.86);"
Compiled OK.
1-way network flow:
fw monitor -e “accept (src=x.x.x.x and dst=x.x.x.x); ”
Example (from 173.16.25.44 to 192.168.2.134)
CP-Firewall> fw monitor -e "accept (src=173.16.25.44 and dst=192.168.2.134); "
2-way network flow:
fw monitor -e "accept (src=x.x.x.x and dst=x.x.x.x) or (src=x.x.x.x and dst=x.x.x.x);"
Example (from/to 172.16.125.81 to 192.168.1.84)
CP-Firewall> fw monitor -e "accept (src=172.16.125.81 and dst=192.168.1.84) or (src=192.168.1.84 and dst=172.16.125.81);"
monitorfilter:
In this example, you can see the ingress interface (eth3) and the egress interface (eth1). Also, you can see the 4 capture points (iIoO):
pre-inbound i (lowercase i)
post-inbound I (uppercase i)
pre-outbound o (lowercase o)
post-outbound O (uppercase o)
You can also use set the capture points:
CP-Firewall> fw monitor -e "accept host(192.168.1.86);" -m iO
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_6] eth3:i[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
[vs_0][fw_6] eth1:O[64]: 173.16.25.44 -> 192.168.1.86 (TCP) len=64 id=0
TCP: 3932 -> 443 .S.... seq=ccbcc90f ack=00000000
Wednesday, November 7, 2018
IP Subnetting
The main purpose of subnetting is to help relieve network congestion.
1. Improve network performance and speed
2. Reduce network congestion
3. Boost network security
4. Control network growth
5. Ease administration
Bits Subnet-Mask
11111111 /32 .255
1111111 /31 .254
111111 /30 .252 64 Nets 2 hosts
11111 /29 .248 32 Nets 6 hosts
1111 /28 .240 16 Nets 14 hosts
111 /27 .224 8 Nets 30 hosts
11 /26 .192 4 Nets 62 hosts
1 /25 .128 2 Nets 126 hosts
Class C first octet 192-223
/24 .0
/23 .254
/22 .252
/21 .248
/20 .240
/19 .224
/18 .192
/17 .128
Class B first octet 128-191
/16 .0.0
/15 .254
/14 .252
/13 .248
/12 .240
/11 .224
/10 .192
/9 .128
Class A first octet 1-126
/8 .0.0.0
/7 .254
/6 .252
/5 .248
/4 .240
/3 .224
/2 .192
/1 .128
/0
Example Giving 172.16.200.0/29
1. How many Networks are created?
2. How many Hosts are created?
3. What is the Network Number?
4. What is the Subnet mask?
5. What is the Broadcast?
Calculation
For a /24 network 00000000 to be used as a /29 11111000, it means, you will have to borrow 5 host bits 11111 to be used as network, and that leaves us with 3 bits 000 for hosts.
11111000 /29 .248 32 Nets 6 hosts
1. How many Networks are created?
Formula n^2 (number of network bits raised to the 2nd power)
n^2 = 5^2 = 32 Networks created
2. How many Hosts are created?
Formula 2^n -2 (2 raised to the number of host bit power, minus 2 for network mask and subnet mask.
2^n -2 = 2^3 -2 = 8-2 = 6 hosts per subnet
3. What is the Network Number?
Examples of the 32 subnets
172.16.200.0/29 Network .0 Hosts .1 .2 .3 .4 .5 .6 Broadcast .7
172.16.200.8/29
172.16.200.16/29
172.16.200.24/29
172.16.200.32/29
172.16.200.40/29
172.16.200.48/29
172.16.200.56/29
172.16.200.64/29
4. What is the Subnet mask?
1 1 1 1 1 0 0 0
00000000 = 2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0
11111000 = 128 + 64 + 32 + 16 + 8 + 0 + 0 + 0
= 248
So subnet mask = 255.255.255.248
5. What is the Broadcast?
172.16.200.0/29 = Network 172.16.200.0 subnet mask 255.255.255.248 net mask /29
Broadcast 172.16.200.7
IP Addressing IP addressing refers to assigning a 32-bit logical numeric address to a network device. Every IP address on the network must be unique. An IP address is represented in a dotted decimal format, for example: 159.101.6.8
As you can see the address is divided in 4 parts, these parts are called octets. IP is defined at Layer 3 (Network layer) of the OSI model and is routable. In order to be routable a network address must have two parts: a network and a host portion. Subnet masks are used to determine which part represents the network portion and which part represents the host portion. By default the subnet mask is based on the class to which the IP address belongs. The following table lists the classes and corresponding values of the first octet (in the IP address) and the default subnet mask.
| Major classes | First octet | Default mask |
| Class A | 1 - 126 | 255.0.0.0 |
| Class B | 128 - 191 | 255.255.0.0 |
| Class C | 192 - 223 | 255.255.255.0 |
Subnetting
Before we go to actually calculating subnets (i.e. subnetting) I want to stress the meaning of the word “subnet mask”. As the name implies, it is a mask that determines what portion of an IP address is the (sub-)network portion. Combined with knowing the class of the IP address it also determines the number of subnets. Although that automatically gives us the host portion as well, it important to realize the class does not influence the number of hosts in a subnet. For example, a class A network with a subnet mask of 255.255.255.0 allows for 254 hosts, which is the same for a class B or class C network with the same subnet mask of 255.255.255.0.
So to determine the maximum number of hosts in a (sub-)network, all you need to know is the subnet mask, or even better: the “prefix”. The class and even the IP address itself are irrelevant when it comes to calculating the maximum number of hosts.
For example, a typical subnetting exam questions might present you with an IP address and a subnet mask or prefix and ask for the total number of hosts and/or subnets. Let’s say the network address is 192.168.1.0 255.255.255.224. To determine the number of hosts we need to translate the mask to a prefix, because that gives us the maximum number of bits we have left for hosts. In this case the prefix is /27 (we’ll get to translation process in detail later) which leaves 5 bits from the 32 bits in an IPv4 address in total. So that’s 5 bits for hosts, which is 5^2 = 32. However, the first address is the network address for the subnet, and the last is the broadcast address, so we need to subtract 2 for those, leaving us with 30 addresses for hosts.
Now, what if the IP address would have been 10.12.3.88, or 179.192.32.254? Or if no IP address was mentioned at all and all we got to go on was the mask? Exactly, it would have made no difference to the number of maximum hosts. So to conclude, the subnet mask doesn’t merely determine what portion of a given IP address is the network portion and what portion is for host, but by itself, without any additional info, a subnet mask can tell you directly how much space it allows for host addresses “per subnet”.
More often we (also) need to know the number of subnets, for which we need one more piece of info than just the subnet mask or prefix, and that’s the class of the IP address. The IP address itself is again irrelevant, except for the first octet, which as shown in the intro above determines the class.
So far we stressed the importance of knowing the prefix and knowing the default subnet mask for the major IP address classes. There is one more thing you need to add to your subnetting toolkit, or actually should be in there already, and that is basic binary math. In particular there are two essential “formulas” you cannot do without:
1. Calculate the maximum number of different decimal values a given amount of bits can represent:
This is really basic binary math. 1 bit allows for 2 different values, 2 bits allows for 4 different values, 3 bits allow for 8 different values. So for every bit you add, the number of possible different values doubles. This can also be written as b^2 where b is the number of bits. Memorizing the first 10 or so is as easy as learning basic multiplication tables back in high school:
1 bit – 2 values
2 bits – 4 values
3 bits – 8 values
4 bits – 16 values
5 bits – 32 values
6 bits – 64 values
7 bits – 128 values
8 bits – 256 values
9 bits – 512 values
10 bits – 1024 values
Again, extending the list is easy because all you need to do is double the previous amount of values for every bit you add. Just remember to start with 2 for the first bit (value 0 and value 1).
The b^2 formula is used to determine the maximum number of subnets and the maximum number of hosts per subnet. For example if you have a class B network with a prefix of /18 you have 2 bits for subnets, which according to the formula and table above means space for 4 different subnets.
When determining the maximum number of hosts in a subnet you need to subtract 2 of the results, one for the network address of the subnet and one for the broadcast address. So basically the formula for hosts is (b^2) - 2.
2. Translate octets from their binary value to their decimal equivalent and back.
The second “bit” of binary math you need to master is translating 8 bits (a byte) to its decimal equivalent (an octet). So instead of looking for the maximum number of different values, we’re going to determine the actual decimal value a given number of bits represent.
Each octet represents 8 bits, for example the IP address 159.101.6.8 mentioned earlier can also be displayed in dotted binary format: 10011111.01100101.00000110.00001000
Converting the decimal address to a binary format (and vice versa) is a fairly easy process. The lowest decimal number you can represent with 8 bits is 0 (when all bits are zero, as in turned off), the highest is 255 (all bits turned on) as shown in the following translation table:
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| 128 + | 64 + | 32 + | 16 + | 8 + | 4 + | 2 + | 1 | = 255 |
| 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | |
| 0 + | 0 + | 0 + | 0 + | 8 + | 4 + | 0 + | 1 | = 13 |
| 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |
| 128 + | 0 + | 32 + | 0 + | 8 + | 0 + | 2 + | 0 | = 170 |
| Binary | Decimal |
| 00000000 | 0 |
| 00000011 | 3 |
| 10000000 | 128 |
| 10000001 | 129 |
| 10111111 | 191 |
| 11111010 | 250 |
Although this works for IP addresses and subnet masks, the latter are a little special. In subnet mask the bits are always consecutive. For example, the subnet mask 255.0.0.0 is written in binary as 11111111.00000000.00000000.00000000 and the subnet mask 255.255.240 is written as 11111111.11111111.11110000.00000000. The number of consecutive ‘1’ bits equals the prefix. So for the first example, the subnet mask 255.0.0.0, the prefix is 8 bits, and for the last example, the subnet mask 255.255.240, the prefix is 8+8+4=20 bits. To determine the decimal value for the third octet (11110000) we add up the first 4 values (1 for each bit turned on) in our translation table, starting from the left: 128+64+32+16 = 240.
After some practice this should become basic and easy math, but since the bits in a mask are always consecutive there is a limit to amount of possible values in a mask. Specifically the following 8:
8 bits = 11111111 = 128+64+32+16+8+4+2+1 = 255
7 bits = 11111110 = 128+64+32+16+8+4+2= 254
6 bits = 11111100 = 128+64+32+16+8+4 = 252
5 bits = 11111000 = 128+64+32+16+8 = 248
4 bits = 11110000 = 128+64+32+16 = 240
3 bits = 11100000 = 128+64+32 = 224
2 bits = 11000000 = 128+64 = 192
1 bits = 10000000 = 128 = 128
0 bits = 00000000 = 0 = 0
Simplified the table looks like this:
8 bits = 255
7 bits = 254
6 bits = 252
5 bits = 248
4 bits = 240
3 bits = 224
2 bits = 192
1 bits = 128
0 bits = 0
The decimal values on the right are the only valid values you will find in a subnet mask and I highly recommend memorizing this table (and if needed dump it on the sheet you get during the exam for quick reference). Besides translating individual octets, the table above is very helpful to determine the prefix based on the subnet mask. For example, the subnet mask 255.255.192.0 obviously equals a prefix of 8+8+2= /18. The other way around is almost as easy and becomes more obvious when written in binary format. For example, if you take the prefix /25 and write it in binary format you end up with:
11111111.11111111.11111111.10000000
This according to our table, if we translate the octets individually, is 255.255.255.128. Basically for every prefix above /8 you subtract 8 and write an octet of 255 until you have 8 bits or less left.
Determine the network and broadcast address
Besides calculating the number of subnets and hosts, another common task regarding subnetting is to determining the network and broadcast address for a given subnet. The network address is the first address in a subnet and the broadcast address is the last address. For example, in the class C network 192.168.1.0 using the default subnet mask 255.255.255.0 (a prefix of /24), the network address is 192.168.1.0 and the broadcast address is 192.168.1.255. When you divide this network into subnets, each subnet will get its own network address and broadcast address. For example, if we divide it into two subnets by using a subnet mask of 255.255.255.128, the network address of the first subnet is 192.168.1.0 and the broadcast address is 192.168.1.127. The network address for the second subnet would be 192.168.1.128 and the broadcast address 192.168.1.255.
In a class C network, or any other network with a prefix of 24 or more, it is easy to determine the network address and broadcast address by simply adding up the number of hosts per subnet, butin general writing out the addresses in binary format is the way to go. For example, to determine the network address of the subnet in which the IP address 10.4.220.36 with subnet mask 255.255.248.0 (prefix 21) resides:
| Subnet A | 00001010.00000100.11011100.00100100 |
| Subnet B | 11111111.11111111.11111000.00000000 |
| ------------------------ | ----------------------------------------------------- |
| Network Address: | 00001010.00000100.11011000.00000000 |
| Network Address: | 00001010.00000100.11011000.00000000 |
| Broadcast Address: | 00001010.00000100.11011111.11111111 |
The valid host range for a subnet consists of all addresses between the network address and the broadcast address.
VLSM
VLSM stands for Variable Length Subnet Masking and allows you to use the available address space more efficiently. For example, if you divide a class C network into two subnets, you can still divide one of the two subnets into additional subnets. An example network using VLSM is depicted below:
In this example network, a Class C network is divided into variable length subnets. Subnet A uses a prefix of /25, which basically divides the network into two subnets (a class C uses 24 bits for the network portion by default, so 1 additional bit is used for subnets, which allows for 2 different subnets).
Subnet A: 192.168.0.0/25 ranges from 192.168.0.0 – 192.168.0.127, allowing for 126 hosts in total (after subtracting the network address and broadcast address for the subnet). Without VLSM that would automatically leave us with 192.168.0.128 – 192.168.0.255 for the second subnet. However, by assigning a higher prefix/mask to the second subnet we can divide it further into smaller subnets.
Subnet B: 192.168.0.128/26 ranges from 192.168.0.128 – 192.168.0.191, allowing for 64 addresses, minus two for the network (192.168.0.128 ) and broadcast address (192.168.0.191) leaves 62 valid host addresses.
That still gives us 192.168.0.192 – 192.168.0.255, which could be used for another subnet with 62 hosts, but can also be divided into smaller subnets yet again:
Subnet C: 192.168.0.192/27 ranges from 192.168.0.192 – 192.168.0.223, allowing for 30 hosts. To summarize, we end up with the following subnets:
| Subnet | Network Address | Hosts |
| Subnet A | 192.168.0.0/25 | 126 |
| Subnet B | 192.168.0.128/26 | 62 |
| Subnet C | 192.168.0.192/27 | 30 |
| Unassigned | 192.168.0.224/27 | 30 |
Supernetting
Supernetting is more or less the opposite of subnetting but instead of dividing networks into subnets, networks can be combined in to a larger supernet. In practice this comes down simply to using a smaller prefix/mask than the default for a particular class. For example, a class C network with a prefix of /23 (mask: 255.255.254.0) would allow for twice as many hosts as a regular “classful” class C network using the default mask of 255.255.255.0. The supernet 192.168.0.0/23 for example ranges from 192.168.0.0 - 192.168.1.255 (the first being the network address, the last being the broadcast address and everything in between, 510 addresses, for hosts).
Subscribe to:
Posts (Atom)