Showing posts with label Networking. Show all posts
Showing posts with label Networking. Show all posts
Sunday, February 12, 2012
Mac OS X Lion and Cisco IPSEC VPN Pitfalls
The Mac OS X Lion, Native VPN client, with Cisco IPSEC EasyVPN Server was NOT working properly for myself. The problem I faced was that traffic was NOT passed to the remote LAN when connected to VPN. Split-tunnel and normal EasyVPN setups did NOT work.
1) When presented with a split-tunnel ACL the Apple client will create a proxy pair for each line.
i.e. VPN IP address of A
split ACL of:
permit B
permit C
permit D
You would see an ipsec sa from A to B, A to C, and A to D.
2) When presented with a split-tunnel ACL the Cisco client will crete a single ipsec sa:
i.e. A to any
However the client will only route traffic to B, C, D over the tunnel.
This is fine and has no problems when using a crypto map style setup for ezvpn.
However when you configure the use of dVTI this becomes difficult. This is because the VTI can only support 1 ipsec sa built to it. As a results when the Apple client tries to propose the proxy pair for the A to C entry it is rejected.
This leaves you with two options here:
1) Switch to a tunnel-all configuration
2) Switch back to the crypto map configuration rather than the virtual-template configuration.
Reference: https://supportforums.cisco.com/thread/2095921
I chose to take the "old" crypto map style setup. Here's how I made it work on a Cisco 877 DSL router:
1) When presented with a split-tunnel ACL the Apple client will create a proxy pair for each line.
i.e. VPN IP address of A
split ACL of:
permit B
permit C
permit D
You would see an ipsec sa from A to B, A to C, and A to D.
2) When presented with a split-tunnel ACL the Cisco client will crete a single ipsec sa:
i.e. A to any
However the client will only route traffic to B, C, D over the tunnel.
This is fine and has no problems when using a crypto map style setup for ezvpn.
However when you configure the use of dVTI this becomes difficult. This is because the VTI can only support 1 ipsec sa built to it. As a results when the Apple client tries to propose the proxy pair for the A to C entry it is rejected.
This leaves you with two options here:
1) Switch to a tunnel-all configuration
2) Switch back to the crypto map configuration rather than the virtual-template configuration.
Reference: https://supportforums.cisco.com/thread/2095921
I chose to take the "old" crypto map style setup. Here's how I made it work on a Cisco 877 DSL router:
ip nat inside source route-map NAT interface Dialer0 overload
route-map NAT permit 10
match ip address 111
exit
access-list 101 remark ----------------------------------------------
access-list 101 remark *****VPN Access-list*****
access-list 101 permit ip 172.16.20.0 0.0.0.255 172.16.40.0 0.0.0.15
!
access-list 111 remark ----------------------------------------------
access-list 111 remark *****DENY Local LAN to VPN Traffic*****
access-list 111 deny ip 172.16.20.0 0.0.0.255 172.16.40.0 0.0.0.15
access-list 111 remark ----------------------------------------------
access-list 111 remark *****PERMIT Networks Internet Access*****
access-list 111 permit ip 172.16.20.0 0.0.0.255 any
access-list 111 permit ip any any
aaa new-model
aaa authentication login userauth local
aaa authorization network groupauth local
username myusername password 0 mypassword
crypto isakmp policy 3
encryption 3des
authentication pre-share
group 2
lifetime 86400
exit
crypto isakmp client configuration group my_vpn
key mysecretgroupkey
dns 172.16.20.1 8.8.8.8
domain my.domain
pool my_vpn_pool
acl 101
max-logins 10
max users 10
save-password
split-dns my.domain
include-local-lan
exit
crypto ipsec transform-set my_set esp-3des esp-md5-hmac
exit
crypto dynamic-map dynmap 10
set transform-set my_set
set security-association idle-time 900
reverse-route
exit
crypto map clientmap client authentication list userauth
crypto map clientmap isakmp authorization list groupauth
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
ip local pool my_vpn_pool 172.16.40.2 172.16.40.8
interface Dialer0
ip nat outside
crypto map clientmap
interface vlan1
no autostate
ip nat inside 
Wednesday, March 24, 2010
Interesting read... Traffic Conditioning scripts: Low Latency, Fast Up & Downloads
Maintain low latency for interactive traffic at all times:
This means that downloading or uploading files should not disturb SSH or even telnet. These are the most important things, even 200ms latency is sluggish to work over. Allow 'surfing' at reasonable speeds while up or downloading.
Even though http is 'bulk' traffic, other traffic should not drown it out too much. Make sure uploads don't harm downloads, and the other way around. This is a much observed phenomenon where outgress traffic simply destroys download speed.
It turns out that all this is possible, at the cost of a tiny bit of bandwidth. The reason that uploads, downloads and ssh hurt each other is the presence of large queues in many domestic access devices like cable or DSL modems.
The next section explains in depth what causes the delays, and how we can fix them. You can safely skip it and head straight for the script if you don't care how the magic is performed.
Why it doesn't work well by default:
ISPs know that they are benchmarked solely on how fast people can download. Besides available bandwidth, download speed is influenced heavily by packet loss, which seriously hampers TCP/IP performance. Large queues can help prevent packet loss, and speed up downloads. So ISPs configure large queues.
These large queues however damage interactivity. A keystroke must first travel the upstream queue, which may be seconds (!) long and go to your remote host. It is then displayed, which leads to a packet coming back, which must then traverse the downstream queue, located at your ISP, before it appears on your screen.
This HOWTO teaches you how to mangle and process the queue in many ways, but sadly, not all queues are accessible to us. The queue over at the ISP is completely off-limits, whereas the upstream queue probably lives inside your cable modem or DSL device. You may or may not be able to configure it. Most probably not.
So, what next? As we can't control either of those queues, they must be eliminated, and moved to your Linux router. Luckily this is possible.
Limit upload speed
By limiting our upload speed to slightly less than the truly available rate, no queues are built up in our modem. The queue is now moved to Linux.
Limit download speed
This is slightly trickier as we can't really influence how fast the internet ships us data. We can however drop packets that are coming in too fast, which causes TCP/IP to slow down to just the rate we want. Because we don't want to drop traffic unnecessarily, we configure a 'burst' size we allow at higher speed.
Now, once we have done this, we have eliminated the downstream queue totally (except for short bursts), and gain the ability to manage the upstream queue with all the power Linux offers.
What remains to be done is to make sure interactive traffic jumps to the front of the upstream queue. To make sure that uploads don't hurt downloads, we also move ACK packets to the front of the queue. This is what normally causes the huge slowdown observed when generating bulk traffic both ways. The Acknowledgements for downstream traffic must compete with upstream traffic, and get delayed in the process.
If we do all this we get the following measurements using an excellent ADSL connection from xs4all in the Netherlands:
Baseline latency:
round-trip min/avg/max = 14.4/17.1/21.7 ms
Without traffic conditioner, while downloading:
round-trip min/avg/max = 560.9/573.6/586.4 ms
Without traffic conditioner, while uploading:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms
With conditioner, during 220kbit/s upload:
round-trip min/avg/max = 15.7/51.8/79.9 ms
With conditioner, during 850kbit/s download:
round-trip min/avg/max = 20.4/46.9/74.0 ms
When uploading, downloads proceed at ~80% of the available speed. Uploads
at around 90%. Latency then jumps to 850 ms, still figuring out why.
What you can expect from this script depends a lot on your actual uplink speed. When uploading at full speed, there will always be a single packet ahead of your keystroke. That is the lower limit to the latency you can achieve - divide your MTU by your upstream speed to calculate. Typical values will be somewhat higher than that. Lower your MTU for better effects!
Next, two versions of this script, one with Devik's excellent HTB, the other with CBQ which is in each Linux kernel, unlike HTB. Both are tested and work well.
The actual script (CBQ)
Works on all kernels. Within the CBQ qdisc we place two Stochastic Fairness Queues that make sure that multiple bulk streams don't drown each other out.
Downstream traffic is policed using a tc filter containing a Token Bucket Filter.
You might improve on this script by adding 'bounded' to the line that starts with 'tc class add .. classid 1:20'. If you lowered your MTU, also lower the allot & avpkt numbers!
If the last two lines give an error, update your tc tool to a newer version!
15.8.3. The actual script (HTB)
The following script achieves all goals using the wonderful HTB queue. Well worth patching your kernel for!
If the last two lines give an error, update your tc tool to a newer version!
Article copied from http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
This means that downloading or uploading files should not disturb SSH or even telnet. These are the most important things, even 200ms latency is sluggish to work over. Allow 'surfing' at reasonable speeds while up or downloading.
Even though http is 'bulk' traffic, other traffic should not drown it out too much. Make sure uploads don't harm downloads, and the other way around. This is a much observed phenomenon where outgress traffic simply destroys download speed.
It turns out that all this is possible, at the cost of a tiny bit of bandwidth. The reason that uploads, downloads and ssh hurt each other is the presence of large queues in many domestic access devices like cable or DSL modems.
The next section explains in depth what causes the delays, and how we can fix them. You can safely skip it and head straight for the script if you don't care how the magic is performed.
Why it doesn't work well by default:
ISPs know that they are benchmarked solely on how fast people can download. Besides available bandwidth, download speed is influenced heavily by packet loss, which seriously hampers TCP/IP performance. Large queues can help prevent packet loss, and speed up downloads. So ISPs configure large queues.
These large queues however damage interactivity. A keystroke must first travel the upstream queue, which may be seconds (!) long and go to your remote host. It is then displayed, which leads to a packet coming back, which must then traverse the downstream queue, located at your ISP, before it appears on your screen.
This HOWTO teaches you how to mangle and process the queue in many ways, but sadly, not all queues are accessible to us. The queue over at the ISP is completely off-limits, whereas the upstream queue probably lives inside your cable modem or DSL device. You may or may not be able to configure it. Most probably not.
So, what next? As we can't control either of those queues, they must be eliminated, and moved to your Linux router. Luckily this is possible.
Limit upload speed
By limiting our upload speed to slightly less than the truly available rate, no queues are built up in our modem. The queue is now moved to Linux.
Limit download speed
This is slightly trickier as we can't really influence how fast the internet ships us data. We can however drop packets that are coming in too fast, which causes TCP/IP to slow down to just the rate we want. Because we don't want to drop traffic unnecessarily, we configure a 'burst' size we allow at higher speed.
Now, once we have done this, we have eliminated the downstream queue totally (except for short bursts), and gain the ability to manage the upstream queue with all the power Linux offers.
What remains to be done is to make sure interactive traffic jumps to the front of the upstream queue. To make sure that uploads don't hurt downloads, we also move ACK packets to the front of the queue. This is what normally causes the huge slowdown observed when generating bulk traffic both ways. The Acknowledgements for downstream traffic must compete with upstream traffic, and get delayed in the process.
If we do all this we get the following measurements using an excellent ADSL connection from xs4all in the Netherlands:
Baseline latency:
round-trip min/avg/max = 14.4/17.1/21.7 ms
Without traffic conditioner, while downloading:
round-trip min/avg/max = 560.9/573.6/586.4 ms
Without traffic conditioner, while uploading:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms
With conditioner, during 220kbit/s upload:
round-trip min/avg/max = 15.7/51.8/79.9 ms
With conditioner, during 850kbit/s download:
round-trip min/avg/max = 20.4/46.9/74.0 ms
When uploading, downloads proceed at ~80% of the available speed. Uploads
at around 90%. Latency then jumps to 850 ms, still figuring out why.
What you can expect from this script depends a lot on your actual uplink speed. When uploading at full speed, there will always be a single packet ahead of your keystroke. That is the lower limit to the latency you can achieve - divide your MTU by your upstream speed to calculate. Typical values will be somewhat higher than that. Lower your MTU for better effects!
Next, two versions of this script, one with Devik's excellent HTB, the other with CBQ which is in each Linux kernel, unlike HTB. Both are tested and work well.
The actual script (CBQ)
Works on all kernels. Within the CBQ qdisc we place two Stochastic Fairness Queues that make sure that multiple bulk streams don't drown each other out.
Downstream traffic is policed using a tc filter containing a Token Bucket Filter.
You might improve on this script by adding 'bounded' to the line that starts with 'tc class add .. classid 1:20'. If you lowered your MTU, also lower the allot & avpkt numbers!
#!/bin/bash
# The Ultimate Setup For Your Internet Connection At Home
#
#
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0
# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### uplink
# install root CBQ
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
# main class
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
allot 1600 prio 1 avpkt 1000
# bulk and default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
allot 1600 prio 2 avpkt 1000
# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# start filters
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
match ip dst 0.0.0.0/0 flowid 1:20
########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1If the last two lines give an error, update your tc tool to a newer version!
15.8.3. The actual script (HTB)
The following script achieves all goals using the wonderful HTB queue. Well worth patching your kernel for!
#!/bin/bash
# The Ultimate Setup For Your Internet Connection At Home
#
#
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0
# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### uplink
# install root HTB, point default traffic to 1:20:
tc qdisc add dev $DEV root handle 1: htb default 20
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
burst 6k prio 1
# bulk & default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
burst 6k prio 2
# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
########## downlink #############
# slow downloads down to somewhat less than the real speed to prevent
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1If the last two lines give an error, update your tc tool to a newer version!
Article copied from http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
Tuesday, March 23, 2010
Easy Route Summarization / Supernetting...
Some people get really confused when it comes to route summarization, probably more so with the different names given to it:
Route Summarization
Supernetting
Aggregate Address
Summary Address
Actually, I get more confused typing out this thing as being English I want to replace the z in "summarization" with an s, but as it's Cisco I best keep the z in. I also get this with "neighbor" versus "neighbour". Anyway, I digress. The above terms all mean the same thing.
What is summarization?
The process of taking a range of IP addresses and advertising them in one address block. The most well-known summarization/supernet is the RFC1918 Class B Range. More commonly we know the range to be 172.16.0.0 - 172.31.255.255, however the supernet is 172.16.0.0/12. You see what has happened there? We've taken a range of addresses and squashed it into one advertisement.
What are the benefits of summarization?
Quite clearly, if we have just one address instead of lots of individual addresses then the routing table is going to be smaller. This in turn means that memory requirements are reduced. The less obvious benefit is that summarization means you're tracking whether or not you're connected to some subnets of a summary, not the up/down state of every link. Thus when the link goes up or down, you don't have a flurry of traffic announcing the state change.
How to summarize/supernet?
This is what you really want to know isn't it? Well it's dead simple. The first method shows you the long way.
1. Starting from the left of the IP address, identify the first octet that has a change of address in it. For example, the Class B RFC1918 range, the IP address first changes in the second octet (i.e. 172.16.x.x - 172.31.x.x).
2. Write out the binary equivalent of the address up to and including the changing octet. So for example the range above is:
10101100.00010000 = 172.16
10101100.00010001 = 172.17
10101100.00010010 = 172.18
10101100.00010011 = 172.19
10101100.00010100 = 172.20
10101100.00010101 = 172.21
10101100.00010110 = 172.22
10101100.00010111 = 172.23
10101100.00011000 = 172.24
10101100.00011001 = 172.25
10101100.00011010 = 172.26
10101100.00011011 = 172.27
10101100.00011100 = 172.28
10101100.00011101 = 172.29
10101100.00011110 = 172.30
10101100.00011111 = 172.31
3. From this list, count from the left how many bits are the same in each address. If we look at it we see that the first 12 bits for each address is the same so that gives us our mask in slash notation. We therefore start at our first address 172.16.0.0 and append our mask so the summary address is 172.16.0.0/12.
Well that was quite simple. But can we be quicker? Yes we can is the good news, after all, you don't want to eat up time in the exam by writing out addresses in binary. So here goes:
1. How many subnets are in the range? The RFC1918 Class B range is 16 subnets.
2. What power of 2 equals our range? 16 subnets = 24 so the answer is four.
3. Subtract the figure from step 2 from the default mask of our address range. In this example our default mask is 16 so the mask after subtracting 4 is /12.
4. Add this mask to the first address in the range - 172.16.0.0/12 in this example
Quick, eh? This is how it works in my head, "mmmm, 16 addresses, 2 to the 4 is 16, mask is 16, minus 4 is 12, so summary address must be first address with /12 mask."
One last example:
Summarize the following:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
There are 4 subnets. 2 to the power of 2 gives us 4 so default mask of 24, minus 2, gives us /22. Address is therefore 192.168.0.0/22.
More difficult supernetting question
There are, however, a few pitfalls with supernetting/summarization. Sometimes you may not be able to get all of the addresses into a supernet without wasting addresses. Experience with supernetting questions will help you to identify this. An example below shows you how this could happen:
You need to summarize the following range:
10.16.31.0/24
10.16.32.0/24
10.16.33.0/24
10.16.34.0/24
10.16.35.0/24
10.16.36.0/24
10.16.37.0/24
10.16.38.0/24
10.16.39.0/24
10.16.40.0/24
What summary address should you use? Well there's 10 subnets. 2 to the power of 3 only gives us 8 subnets which is too small so we need to look at 2 to the power of 4 which is 16. The problem is that if we count in 16s our addresses straddle two subnets: 10.16.16.0 to 10.16.31.255 and 10.16.32.0 to 10.16.47.255. We have the same problem if we use the power of 5 giving us a range of 32 addresses (10.16.31.0 is in a different subnet than the other addresses in the range). We therefore have to go out to 2 to the power of 6 = 64 in order to get all of our addresses in the
range (i.e. 10.16.0.0 to 10.16.63.255). What a waste of address space!! The best answer is the following:
Break the space down into three ranges. We can summarize 10.16.32.0 to 10.16.39.255 with 3 bits (i.e. there are 8 subnets and 2 to the power of 3 is 8). We simply leave the other two address as they are. We have therefore avoided any wasted address space.
Reference: Please also see the comments!
http://subnettingmadeeasy.blogspot.com/2007/11/router-summarization.html
More Examples:
Question:
"Given the addresses 10.1.138.0/27, 10.1.138.64/26, and 10.1.138.32/27, which of the following is the best summary?"
Answer:
10.1.138.0/27 covers 10.1.138.0 to 10.1.138.31
10.1.138.32/27 covers 10.1.138.32 to 10.1.138.63
10.1.138.64/26 covers 10.1.138.64 to 10.1.138.127
Therefore you have to find out which summary covers 10.1.138.0 to 10.128.38.127. This is 128 addresses (1 network address, 1 broadcast address, and 126 host addresses). We therefore need to reserve enough bits to cover 128 addresses. We know that 2^7 = 128 so we must not subnet the last 7 bits of the address. As there are 32 bits in an IP address we subtract 7 from 32 to give us 25. Our summary address is therefore 10.128.38.0/25
Question:
A router has a summary route to network 192.168.32.0/20 installed in its routing table. What range of networks are summarized by this route?
Answer:
You have a /20 which is a block size of 16 in the third octet (i.e. 2^(24-20) = 16). Count in block sizes of 16 in the third octet so you would have 192.168.0.0, 192.168.16.0, 192.168.32.0, 192.168.48.0 etc Your summary will therefore cover 192.168.32.0 to 192.168.47.255 To prove this you could always use binary. If we just concentrate on the third octet and pick 32 (the subnet address, in binary 00100000) and the mask for that octet is 11110000 (i.e. the full mask for a /20 is 111111111.11111111.11110000.00000000)
Perform an AND on that octet:
00100000
11110000
=
00100000
=
32
What if we use 47 in the 3rd octet (binary 00101111)?
Perform an AND:
00101111
11110000
=
00100000
=
32
They both resolve to the same value in the third octet so we know it is in the same summary.
Let's go to 48 in the third octet (binary 00110000) and perform the same AND with a /20 mask:
00110000
11110000
=
00110000
=
48
This value is different and therefore is not in the summary. The binary way is the longest method but can be useful for you to see what is happening with the bits.
Question:
Which address can be used to summarize networks 172.16.0.0/24 thru 172.16.7.0/24?
Answer:
In this case you still follow the same principals as in the tutorial but subtract the number of bits required to cover the subnet range from the mask given in the question. The question has 8 subnets in all. 3 bits will give us 8 subnets as 2 ^ 3 = 8. Subtract 3 from the mask in the question (24 - 3) which equals 21. Take the first address in your range and change the mask to the new mask and that gives you the summarized address (i.e. 172.16.0.0/21)
Route Summarization
Supernetting
Aggregate Address
Summary Address
Actually, I get more confused typing out this thing as being English I want to replace the z in "summarization" with an s, but as it's Cisco I best keep the z in. I also get this with "neighbor" versus "neighbour". Anyway, I digress. The above terms all mean the same thing.
What is summarization?
The process of taking a range of IP addresses and advertising them in one address block. The most well-known summarization/supernet is the RFC1918 Class B Range. More commonly we know the range to be 172.16.0.0 - 172.31.255.255, however the supernet is 172.16.0.0/12. You see what has happened there? We've taken a range of addresses and squashed it into one advertisement.
What are the benefits of summarization?
Quite clearly, if we have just one address instead of lots of individual addresses then the routing table is going to be smaller. This in turn means that memory requirements are reduced. The less obvious benefit is that summarization means you're tracking whether or not you're connected to some subnets of a summary, not the up/down state of every link. Thus when the link goes up or down, you don't have a flurry of traffic announcing the state change.
How to summarize/supernet?
This is what you really want to know isn't it? Well it's dead simple. The first method shows you the long way.
1. Starting from the left of the IP address, identify the first octet that has a change of address in it. For example, the Class B RFC1918 range, the IP address first changes in the second octet (i.e. 172.16.x.x - 172.31.x.x).
2. Write out the binary equivalent of the address up to and including the changing octet. So for example the range above is:
10101100.00010000 = 172.16
10101100.00010001 = 172.17
10101100.00010010 = 172.18
10101100.00010011 = 172.19
10101100.00010100 = 172.20
10101100.00010101 = 172.21
10101100.00010110 = 172.22
10101100.00010111 = 172.23
10101100.00011000 = 172.24
10101100.00011001 = 172.25
10101100.00011010 = 172.26
10101100.00011011 = 172.27
10101100.00011100 = 172.28
10101100.00011101 = 172.29
10101100.00011110 = 172.30
10101100.00011111 = 172.31
3. From this list, count from the left how many bits are the same in each address. If we look at it we see that the first 12 bits for each address is the same so that gives us our mask in slash notation. We therefore start at our first address 172.16.0.0 and append our mask so the summary address is 172.16.0.0/12.
Well that was quite simple. But can we be quicker? Yes we can is the good news, after all, you don't want to eat up time in the exam by writing out addresses in binary. So here goes:
1. How many subnets are in the range? The RFC1918 Class B range is 16 subnets.
2. What power of 2 equals our range? 16 subnets = 24 so the answer is four.
3. Subtract the figure from step 2 from the default mask of our address range. In this example our default mask is 16 so the mask after subtracting 4 is /12.
4. Add this mask to the first address in the range - 172.16.0.0/12 in this example
Quick, eh? This is how it works in my head, "mmmm, 16 addresses, 2 to the 4 is 16, mask is 16, minus 4 is 12, so summary address must be first address with /12 mask."
One last example:
Summarize the following:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
There are 4 subnets. 2 to the power of 2 gives us 4 so default mask of 24, minus 2, gives us /22. Address is therefore 192.168.0.0/22.
More difficult supernetting question
There are, however, a few pitfalls with supernetting/summarization. Sometimes you may not be able to get all of the addresses into a supernet without wasting addresses. Experience with supernetting questions will help you to identify this. An example below shows you how this could happen:
You need to summarize the following range:
10.16.31.0/24
10.16.32.0/24
10.16.33.0/24
10.16.34.0/24
10.16.35.0/24
10.16.36.0/24
10.16.37.0/24
10.16.38.0/24
10.16.39.0/24
10.16.40.0/24
What summary address should you use? Well there's 10 subnets. 2 to the power of 3 only gives us 8 subnets which is too small so we need to look at 2 to the power of 4 which is 16. The problem is that if we count in 16s our addresses straddle two subnets: 10.16.16.0 to 10.16.31.255 and 10.16.32.0 to 10.16.47.255. We have the same problem if we use the power of 5 giving us a range of 32 addresses (10.16.31.0 is in a different subnet than the other addresses in the range). We therefore have to go out to 2 to the power of 6 = 64 in order to get all of our addresses in the
range (i.e. 10.16.0.0 to 10.16.63.255). What a waste of address space!! The best answer is the following:
Break the space down into three ranges. We can summarize 10.16.32.0 to 10.16.39.255 with 3 bits (i.e. there are 8 subnets and 2 to the power of 3 is 8). We simply leave the other two address as they are. We have therefore avoided any wasted address space.
Reference: Please also see the comments!
http://subnettingmadeeasy.blogspot.com/2007/11/router-summarization.html
More Examples:
Question:
"Given the addresses 10.1.138.0/27, 10.1.138.64/26, and 10.1.138.32/27, which of the following is the best summary?"
Answer:
10.1.138.0/27 covers 10.1.138.0 to 10.1.138.31
10.1.138.32/27 covers 10.1.138.32 to 10.1.138.63
10.1.138.64/26 covers 10.1.138.64 to 10.1.138.127
Therefore you have to find out which summary covers 10.1.138.0 to 10.128.38.127. This is 128 addresses (1 network address, 1 broadcast address, and 126 host addresses). We therefore need to reserve enough bits to cover 128 addresses. We know that 2^7 = 128 so we must not subnet the last 7 bits of the address. As there are 32 bits in an IP address we subtract 7 from 32 to give us 25. Our summary address is therefore 10.128.38.0/25
Question:
A router has a summary route to network 192.168.32.0/20 installed in its routing table. What range of networks are summarized by this route?
Answer:
You have a /20 which is a block size of 16 in the third octet (i.e. 2^(24-20) = 16). Count in block sizes of 16 in the third octet so you would have 192.168.0.0, 192.168.16.0, 192.168.32.0, 192.168.48.0 etc Your summary will therefore cover 192.168.32.0 to 192.168.47.255 To prove this you could always use binary. If we just concentrate on the third octet and pick 32 (the subnet address, in binary 00100000) and the mask for that octet is 11110000 (i.e. the full mask for a /20 is 111111111.11111111.11110000.00000000)
Perform an AND on that octet:
00100000
11110000
=
00100000
=
32
What if we use 47 in the 3rd octet (binary 00101111)?
Perform an AND:
00101111
11110000
=
00100000
=
32
They both resolve to the same value in the third octet so we know it is in the same summary.
Let's go to 48 in the third octet (binary 00110000) and perform the same AND with a /20 mask:
00110000
11110000
=
00110000
=
48
This value is different and therefore is not in the summary. The binary way is the longest method but can be useful for you to see what is happening with the bits.
Question:
Which address can be used to summarize networks 172.16.0.0/24 thru 172.16.7.0/24?
Answer:
In this case you still follow the same principals as in the tutorial but subtract the number of bits required to cover the subnet range from the mask given in the question. The question has 8 subnets in all. 3 bits will give us 8 subnets as 2 ^ 3 = 8. Subtract 3 from the mask in the question (24 - 3) which equals 21. Take the first address in your range and change the mask to the new mask and that gives you the summarized address (i.e. 172.16.0.0/21)
Easy Subnetting...
This technique requires you to know how to work with the powers of 2. We need to start with the fundamentals of IP addressing. An IP address is made up of 32 bits, split into 4 octets (oct = 8). Some bits are reserved for identifying the network and the other bits are left to identify the host.
There are 3 main classes of IP address that we are concerned with.
Class A Range 0 - 127 in the first octet (0 and 127 are reserved)
Class B Range 128 - 191 in the first octet
Class C Range 192 - 223 in the first octet
Below shows you how, for each class, the address is split in terms of network (N) and host (H) portions.
NNNNNNNN . HHHHHHHH . HHHHHHHH . HHHHHHHH Class A
NNNNNNNN . NNNNNNNN . HHHHHHHH . HHHHHHHH Class B
NNNNNNNN . NNNNNNNN . NNNNNNNN . HHHHHHHH Class C
At each dot I like to think that there is a boundary, therefore there are boundaries after bits 8, 16, 24, and 32. This is an important concept to remember.
We will now look at typical questions that you may see on subnetting. More often than not they ask what a host range is for a specific address or which subnet a certain address is located on.
Examples:
What subnet does 192.168.12.78/29 belong to?
You may wonder where to begin. Well to start with let's find the next boundary of this address. Our mask is a /29. The next boundary is 32. So 32 - 29 = 3. Now 2^3 = 8 which gives us our block size i.e. 2 to the power of 3 equals 8.
We have borrowed from the last octet as the 29th bit is in the last octet. We start from zero and count up in our block size. Therefore it follows that the subnets are:
192.168.12.0
192.168.12.8
192.168.12.16
192.168.12.24
192.168.12.32
192.168.12.40
192.168.12.48
192.168.12.56
192.168.12.64
192.168.12.72
192.168.12.80
.............etc
Our address is 192.168.12.78 so it must sit on the 192.168.12.72 subnet.
What subnet does 172.16.116.4/19 belongs to?
Our mask is /19 and our next boundary is 24. Therefore 24 - 19 = 5. The block size is 2^5 = 32. We have borrowed into the third octet as bit 19 is in the third octet so we count up our block size in that octet. The subnets are:
172.16.0.0
172.16.32.0
172.16.64.0
172.16.96.0
172.16.128.0
172.16.160.0
.............etc
Our address is 172.16.116.4 so it must sit on the 172.16.96.0 subnet.
What subnet does 10.34.67.234/12 sit on?
Our mask is 12. Our next boundary is 16. Therefore 16 - 12 = 4. 2^4 = 16 which gives us our block size. We have borrowed from the second octet as bit 12 sits in the second octet so we count up the block size in that octet. The subnets are:
10.0.0.0
10.16.0.0
10.32.0.0
10.48.0.0
.............etc
Our address is 10.34.67.234 which must sit on the 10.32.0.0 subnet.
We will now change the type of question so that we have to give a particular host range of a subnet.
What is the valid host range of of the 4th subnet of 192.168.10.0/28?
The block size is 16 since 32 - 28 = 4 and 2^4 = 16. We need to count up in the block size in the last octet as bit 28 is in the last octet.
192.168.10.0
192.168.10.16
192.168.10.32
192.168.10.48
192.168.10.64
.................etc
Therefore the 4th subnet is 192.168.10.48 and the host range must be 192.168.10.49 to 192.168.10.62, remembering that the subnet and broadcast address cannot be used.
What is the valid host range of the 1st subnet of 172.16.0.0/17?
/17 tells us that the block size is 2^(24-17) = 2^7 = 128. We are borrowing in the 3rd octet as bit 17 is in the 3rd octet. Our subnets are:
172.16.0.0
172.16.128.0
The first subnet is 172.16.0.0 and the valid host range is 172.16.0.1 to 172.16.127.254. You must remember not to include the subnet address (172.16.0.0) and the broadcast address (172.16.127.255).
What is the valid host range of the 7th subnet of address 10.0.0.0/14?
The block size is 4, from 16 - 14 = 2 then 22 = 4. We are borrowing in the second octet so count in the block size from 0 seven times to get the seventh subnet.
The seventh subnet is 10.24.0.0. Our valid host range must be 10.24.0.1 to 10.27.255.254 again remembering not to include our subnet (10.24.0.0) and the broadcast address (10.27.255.255).
What if you're given the subnet mask in dotted decimal?
If you're lucky and they give you a mask in dotted decimal format then you should have an even easier time. All you need again is your block size. Let's say they have given a mask of 255.255.255.248 and you wish to know the block size. Here's the technique:
1. Starting from the left of the mask find which is the first octet to NOT have 255 in it.
2. Subtract the number in that octet from 256 to get your block size e.g. above it is 256 - 248 = block size of 8.
3. Count up from zero in your block size in the octet identified in step 1 as you have learned above (the example above would be in the last octet).
Another example is a mask of 255.255.192.0 - you would simply count up in 256 - 192 = 64 in the third octet.
One more example is 255.224.0.0 - block size is 256 - 224 = 32 in the second octet
There are 3 main classes of IP address that we are concerned with.
Class A Range 0 - 127 in the first octet (0 and 127 are reserved)
Class B Range 128 - 191 in the first octet
Class C Range 192 - 223 in the first octet
Below shows you how, for each class, the address is split in terms of network (N) and host (H) portions.
NNNNNNNN . HHHHHHHH . HHHHHHHH . HHHHHHHH Class A
NNNNNNNN . NNNNNNNN . HHHHHHHH . HHHHHHHH Class B
NNNNNNNN . NNNNNNNN . NNNNNNNN . HHHHHHHH Class C
At each dot I like to think that there is a boundary, therefore there are boundaries after bits 8, 16, 24, and 32. This is an important concept to remember.
We will now look at typical questions that you may see on subnetting. More often than not they ask what a host range is for a specific address or which subnet a certain address is located on.
Examples:
What subnet does 192.168.12.78/29 belong to?
You may wonder where to begin. Well to start with let's find the next boundary of this address. Our mask is a /29. The next boundary is 32. So 32 - 29 = 3. Now 2^3 = 8 which gives us our block size i.e. 2 to the power of 3 equals 8.
We have borrowed from the last octet as the 29th bit is in the last octet. We start from zero and count up in our block size. Therefore it follows that the subnets are:
192.168.12.0
192.168.12.8
192.168.12.16
192.168.12.24
192.168.12.32
192.168.12.40
192.168.12.48
192.168.12.56
192.168.12.64
192.168.12.72
192.168.12.80
.............etc
Our address is 192.168.12.78 so it must sit on the 192.168.12.72 subnet.
What subnet does 172.16.116.4/19 belongs to?
Our mask is /19 and our next boundary is 24. Therefore 24 - 19 = 5. The block size is 2^5 = 32. We have borrowed into the third octet as bit 19 is in the third octet so we count up our block size in that octet. The subnets are:
172.16.0.0
172.16.32.0
172.16.64.0
172.16.96.0
172.16.128.0
172.16.160.0
.............etc
Our address is 172.16.116.4 so it must sit on the 172.16.96.0 subnet.
What subnet does 10.34.67.234/12 sit on?
Our mask is 12. Our next boundary is 16. Therefore 16 - 12 = 4. 2^4 = 16 which gives us our block size. We have borrowed from the second octet as bit 12 sits in the second octet so we count up the block size in that octet. The subnets are:
10.0.0.0
10.16.0.0
10.32.0.0
10.48.0.0
.............etc
Our address is 10.34.67.234 which must sit on the 10.32.0.0 subnet.
We will now change the type of question so that we have to give a particular host range of a subnet.
What is the valid host range of of the 4th subnet of 192.168.10.0/28?
The block size is 16 since 32 - 28 = 4 and 2^4 = 16. We need to count up in the block size in the last octet as bit 28 is in the last octet.
192.168.10.0
192.168.10.16
192.168.10.32
192.168.10.48
192.168.10.64
.................etc
Therefore the 4th subnet is 192.168.10.48 and the host range must be 192.168.10.49 to 192.168.10.62, remembering that the subnet and broadcast address cannot be used.
What is the valid host range of the 1st subnet of 172.16.0.0/17?
/17 tells us that the block size is 2^(24-17) = 2^7 = 128. We are borrowing in the 3rd octet as bit 17 is in the 3rd octet. Our subnets are:
172.16.0.0
172.16.128.0
The first subnet is 172.16.0.0 and the valid host range is 172.16.0.1 to 172.16.127.254. You must remember not to include the subnet address (172.16.0.0) and the broadcast address (172.16.127.255).
What is the valid host range of the 7th subnet of address 10.0.0.0/14?
The block size is 4, from 16 - 14 = 2 then 22 = 4. We are borrowing in the second octet so count in the block size from 0 seven times to get the seventh subnet.
The seventh subnet is 10.24.0.0. Our valid host range must be 10.24.0.1 to 10.27.255.254 again remembering not to include our subnet (10.24.0.0) and the broadcast address (10.27.255.255).
What if you're given the subnet mask in dotted decimal?
If you're lucky and they give you a mask in dotted decimal format then you should have an even easier time. All you need again is your block size. Let's say they have given a mask of 255.255.255.248 and you wish to know the block size. Here's the technique:
1. Starting from the left of the mask find which is the first octet to NOT have 255 in it.
2. Subtract the number in that octet from 256 to get your block size e.g. above it is 256 - 248 = block size of 8.
3. Count up from zero in your block size in the octet identified in step 1 as you have learned above (the example above would be in the last octet).
Another example is a mask of 255.255.192.0 - you would simply count up in 256 - 192 = 64 in the third octet.
One more example is 255.224.0.0 - block size is 256 - 224 = 32 in the second octet
Subscribe to:
Posts (Atom)