New technology should simplify things, not complicate them

An old-school guy like me adheres to an old-school mantra on network and system administration: "If it 'ain't broke, don't fix it"

Rookie Netads and Sysads tend to be too excited when new technologies are available on the market. Under the impression that it will make their jobs and responsibilities easier, they jump to the bandwagon. First they sign up for a trial, then they extend the trial and eventually purchasing the product in the end. "Hey boss, this software/product will cut off costs and man-hours of working on _______ manually, blah, blah"

In other words, please buy this software for me. But sometimes we fail to put into consideration that introducing a new technology on our network most of the time tends to complicate things, especially in troubleshooting when problems start to surface.

There's this company based in the East Coast. They have a corporate size network, with a couple of WAN connections to connect to their regional offices and remote employees. Things were doing good until after they implemented redundancy across all routers and Layer 3 devices on their network. How ironic that they started experiencing major issues when they tried to implement a technology that address the availability of their network.

These guys implemented a technology that they fail to test first on at least half of the nodes/workstations on their network. They fell prey to the "herd mentality". Hey, customer ABC and XYZ are doing it, we should to, that type of herd mentality in IT. And hearing this directly coming from their "seasoned" IT Director saddens me.

Again, I am big fan of keeping things simple. A simple network consumes less resources in all aspects of your business or organization. From technical to administrative. If you want redundancy in your network, study the technology t first before implementing it. Try to look beyond brochures, case studies and white papers. Not all networks are the same despite what those "Best Practices" guide say.

Configuring ACLs on Huawei

-->

First of all, why ACLs? Did it have to be specific? Not really, it's just that I find configuring ACLs on Huawei a bit more complex or should I say. .structured. More complex in a sense that if you know how to configure ACLs on Cisco, you might find configuring it on Huawei a bit weird because it's kind of like the way route-map or a QoS policy is configured in Cisco. But don't get me wrong it's not that hard, really, all I'm saying is that its pretty similar as to the way those are configured but it doesn't necessarily mean its hard. It only takes a little bit of time to understand the equivalents especially for guys who had their basics the Cisco way just like me.

Now if you're already good at Cisco ACLs then this might be just a piece of cake for you to understand. There's just a little bit more to it but it's pretty easy to digest. First up, there are three new terms you would need to know – Traffic Classifier, Traffic Behavior and Traffic policy. Now let me introduce you to these terms (actually they're already the exact commands lol).

Sorry, this post has been moved to my new blog. Please continue to the new site: Configuring ACLs on Huawei

IPv6 address types

One of the topics to focus on in IPv6 is the addressing part, greatly because its a totally new addressing scheme. As compared to IPv4 which has 32 bits, the IPv6 address is 128 bits long and is in hexadecimal format (0-9 A-F) or four bits per digit.

0000:0000:0000:0000: 0000:0000:0000:0000

NOTE: In IPv6, due to the length of the address itself there were rules that were made to somehow shorten the address into a bit more human-readable format. These two rules are zero compression and leading zero compression.

zero compression - in case there are consecutive zeros within the address you may replace it by putting in double colons (::). However you can only do this once within an address as the device would have no way of determining how many zeros are there in each '::' theres is if there were more than one. For an example 2001:0005:0000:0000:0201:50FF:FE68:AF50 could be compressed as 2001:0005::0201:50FF:FE68:AF50. The zeros in between were omitted and was replaced by ::.

leading zero compression - for any leading zeros you can go ahead and exclude them to make the address a bit more shorter. However in case there are all zeros within colons you must leave at least one zero to specify that it is all zeros before that hex digit. Using our previous example our address would look like 2001:5:0:0:201:50FF:FE68:AF50.

We could use these two rules simultaneously. And therefore our fully compressed IPv6 address would be 2001:5::201:50FF:FE68:AF50.

One major difference also is there is no ‘class’ system here (class A, B, C, D). In IPv6, we more refer to them as types. Now lets go through them one by one.

Unicast Address – used for sending to one host or interface. Currently there are two types of IPv6 unicast addresses:

Global Unicast – formerly known as Global Aggregatable Unicast address but the ‘Aggregatable’ has now been omitted in the latest RFC. Global Unicast is equal to IPv4s public or Internet address. Knowing this we can understand that this address type will be the ones we use to communicate to the Internet. These addresses composes of the global routing prefix (as of today IANA is assigning numbers that starts with 2000::/3) plus the 64-bit Interface Identifier (EUI-64 format) which we will discuss later.

Link-Local Unicast – are the addresses our devices use to communicate with other nodes on the same local network even without a global unicast address. You may compare this type of address to the layer 2 address or data-link layer address we have in IPv4. Note that these address are autoconfigured on the interfaces using FE80::/10 prefix plus the EUI-64 format Interace Identifier, which again will be discussed later.

Anycast Address – an anycast address is a global unicast address assigned to two or more devices. Packets coming from nodes who wants to access this address will be routed to the closest active device with the anycast address. This is determined by the routing protocol metric or rather the router which receives this packet then routes to the closest one to it.

Multicast Address – a multicast address identifies a group of interfaces. Traffic sent to these addresses are sent to all of the interfaces in that group. Mulicast in IPv6 is not that different in IPv4, its just that in IPv6 only multicast exists. There is no such thing as broadcast in IPv6 (except for some that is specifically addressed to interfaces that maybe within one segment or layer 2 domain like in IPv4). Interfaces may belong to many multicast groups simultaneously. Multicast addresses are addresses that start with FF00::/8. All IPv6 multicast address are within this prefix and so when you see an address that starts with this you will know that this is an IPv6 Multicast address.

Now lets get to the Interface Identifier as promised. Knowing how this address is made is important as you don’t really get to configure this since this is autoconfigured already on the IPv6 enabled interface.

Interface Identifiers (IDs) – are addresses used to identify a unique interface on a link and are sometimes referred to as the ‘host portion’ of the IPv6 address. These address are 64-bits long and is can be dynamically created based on the data-link layer address of the interface. IPv6 Interface IDs are determined depending on the specific data-link layer type of interface there is. In this topic we will discussing Ethernet Interface IDs as this is what we commonly use almost everywhere (even on non-ethernet mediums). Now we can determine its ID based on its MAC address, using a format called Extended Universal Identifier 64-bit (EUI-64). The EUI-64 format Interface ID is derived from the 48-bit MAC address by inserting the hexadecimal digits FFFE between the Organizationally Unique Identifier (OUI), which is the upper three bytes, and the vendor code, which is the lower three bytes of the MAC address. I hope you guys could still remember your MAC addressing fundamentals back in the days because yes it back and used a lot in the IPv6 world. In addition to this the 7^th bit in the first byte in the resulting Interface ID, which is the Universal/Local (U/L) bit is always set to binary 1. The U/L bit indicates whether the Interface ID is locally unique on the link or universally (globally) unique. IDs derived from universally unique MAC addresses are assumed to be globally unique so no worries if your already using the Burn In Address of your Interfaces. The 8^th bit on the first byte then is the Individual/Group (I/G) bit for managing multicast groups, it is not altered.

As you can see in this example it is pretty easy to understand how an IPv6 Interface ID is composed. You just have to remember two steps. First insert FFFE in between the 48 bit MAC address (in between the two sets of three bytes or 24bits) and then the 7^th bit is set to 1. MAC addresses almost always starts with 00 as of yet (I haven’t seen one which isn’t or at least not that I can remember at this time) so you will always see this as ‘02’ (0000 0010).

Now going back to the Glocal Unicast and Link-Local Unicast where we used this Interface IDs. For Global Unicast for example we have a IPv6 public address assigned by APNIC 2001:1F14::/32 (/32s are assigned to ISPs). We now then assign a subnet to our main PoP the subnet 1 and assign a Network Access Server located there an IPv6 address. The server happens to have the MAC address of 00:53:07:2B:AE:09. Knowing this we now determine the Globally unique IPv6 address of this server. The public IPv6 address assigned to us with a subnet of 1 – 2001:1F14::1:, plus the EUI-64 format Interface Identifier derived from the MAC address of the device - 0253:07FF:FE2B:AE09. Our Global Unicast address for our server would be 2001:1F14::1:0253:07FF:FE2B:AE09/64. Now for our Link-Local address we only have to use FE80:: along with our Interface ID. We then now get FE80::0253:07FF:FE2B:AE09. Please note again that this is autogenerated (you will see that once you start assigning an IPv6 address on a router) and that you have to get use to these addresses as these addresses are the ones used by routing protocols for IPv6 e.g OSPFv3, RIPng & MP-BGP.

I hope you guys learned something new and I’ll probably post more topics about IPv6 if I find the time. Yes its been busy these days so it sort of feels good to be able to post a topic again. If you have any questions about this topic just post you may visit the forum.

VoIP Application Layer 1: The Packet Infrastructure

Thinking of creating your own VoIP application Part II.
Layer 1: The Packet Infrastructure

Let's say I am Superman and I have X-ray vision. My goal is to look at the inner-workings of a VoIP application or clients like Skype, Yahoo Messenger and Five9 Virtual Contact Center (VCC) Agent.

Like Superman, my goal is to "see-through" this VoIP application because I need to investigate on something. Apparently, Lex Luthor, being a rich genius that he is, has managed to create his own secure VoIP client. Lex Luthor is using this VoIP client application to make calls to his henchmen. So its up to me to investigate on this, retrieve evidence and prove to that he is the mastermind.

If I was Superman, all I need to do is use my X-ray vision to see-through the VoIP application Lex Luthor is using. I will immediately see hundreds of lines of programming codes, specifically variables, commands, and on the networking side, what communication protocols and their corresponding ports this application is using to communicate over the Internet. Now that's interesting.

Luckily, we do not need to be a man of steel or someone who wears blue and red tights and fly around the city saving people and still look cool in the process. Thank goodness for protocol analyzers. It is the X-ray vision of us guys in the voice and data networking field.

Wireshark, (known as Ethereal from its early days) is one of the leading protocol analyzers out there, and its free. If you need to investigate the inner-workings of an application connected to a network, Wireshark is your answer. It is slowly becoming the tool of choice for network sniffers and VoIP phreakers, black hat or white hat. There's tons of things you can do with Wireshark once you have it installed and running on your network, but that is beyond the topic of this post.

For this post, I will refer and use Wireshark extensively to show to you what networking protocols and ports Five9 Agent VCC is using. Five9 Agent VCC is a VoIP client used by Call Center Agents around the globe in making and receiving calls. Five9 VCC Agent utilizes a Softphone feature, the dial pad and other telephone features are on the screen, just push the buttons you need. All you need is a reliable Internet connection, a USB headset with microphone and an account with Five9, and that's it.

(To be continued on next post)

Thinking of creating your own VoIP application?

Voice-Over-Internet Protocol, a.k.a VoIP, was labeled as a disruptive technology during its infancy. Disruptive in a sense that it will have a massive effect on the current Telecom industry. There were even rumors that it will totally replace the traditional Public Switched Telephone Network (PSTN), or what Cisco-fellows commonly call as POTS for Plain-Old Telephone Service. My belief is that VoIP was and should be developed to work with PSTN, not make it obsolete. Using PSTN and VoIP technology together is even better.

Contrary to public notion, VoIP is not that new to Telecom providers or carriers. In fact, a lot of them has been using VoIP for years now. Carriers mostly use VoIP in transferring international calls and trunking with other major carriers around the globe. They still use Signaling System 7 or SS7 (SS7 is the standard signaling method/protocol of PSTN, which is digital as well) as the primary method of signaling for the majority of their calls, but a consumer doesn't know that sometimes, to cut costs and connect with other carriers faster, a specific international call made by a subscriber is routed using VoIP to connect to another country. Then once the call hits the terminating carrier, the call is then transformed and/or encoded back to analog, then routed using SS7 to the destination telephone number. This method has been saving carriers around the world thousands of dollars.

The beauty of VoIP communication on a technology level is you do not need a dedicated physical or virtual circuit, always reserved for a communication to take place. With IP technology, the voice traffic can use the current available bandwidth of a circuit, then make it open and available for other applications or traffic once the communication has ended. This has been made possible because of Time-Division Multiplexing (TDM) technology.

The current state of VoIP is amazing. Despite not yet being fully-mature in my opinion, hundreds of start-up companies are now offering top-notch carrier-grade, easy to setup VoIP technology. I for one uses Skype as my major tool of communication with my family in the Philippines. I am hoping that someday Skype will decide to make public their proprietary P2P Signaling Protocol that makes their Skype Video Chat light-years ahead with the current competition.

If you want to test this, go and make a video chat session using the latest version of Yahoo Messenger. Observe and compare the delay and quality of the audio and video. Now launch Skype, and you will immediately notice the difference. The WiFi latency inside our house in Manila averages between 190 to 250ms when pinging a US gateway, but this doesn't seem to have a big effect with the quality of my Skype Video Chat session. I live here in the Bay Area, using Comcast Cable Internet with basic 1024K up and 325K download. My laptops are hooked on wireless so I can blog even while I watch my roommates outside skating on our homemade half-pipe at our backyard. Skype is utilizing an excellent proprietary protocol for their signaling resulting in an excellent performance of their VoIP product.

If you are code geek, someone who can easily develop their own application using various programming languages, you will find it relatively easy to develop your own VoIP application.

So what makes up a VoIP application?

A conceptual model has been developed by various leading companies and developers in the VoIP industry. The Internet Engineering Task Force (IETF) is one of the major contributors for the success of VoIP because of the excellent Standardization and Drafts members contributed.

Remember the Open System Interconnect Model a.k.a. OSI Model? Traditional Data Network guys use this conceptual model as a guide in developing and troubleshooting applications and processes that are made for transferring data from one network to another, regardless of its geographical location. A computer network's primary function is to transfer data in form of packets or radio signals from point A to point B. Everything else is optional and for maintenance purposes.

A VoIP application in a nutshell is composed of 3 Layers:

Layer 3: Application
Layer 2: Call Control
Layer 1: Packet Infrastructure

Layer 1, the Packet Infrastructure in a nutshell would map to the Transport Layer, (Layer 4) of the OSI Model. On this layer, you define if your application will use TCP, UDP, RTP over UDP or a combination of the identified standard communication protocols for your VoIP application to establish communication channels to carry the signal and actual voice payload from source to receiver.

Layer 2, Call Control, or Signaling, is the layer where you define how your VoIP application will be able to establish a connection from source to destination. This is where you define if your VoIP application will be using the signaling standards such as Session Initiation Protocol (SIP), H.323, MeGaCo and others to name a few.

Layer 3, Application, defines the actual capabilities of your VoIP application. Features such as Call Waiting, 3-way conferencing, Hold Music, Voicemail and Click-to-Call functionalities are defined here. This is where you make your application unique and stand-out among other VoIP products.

Stay tuned and I will explain and breakdown the 3 Core Layers of VoIP in details on my next post. I will include sample applications and opensource source codes that developers out there can use as a guide in discovering the inner-works of a VoIP application. Just be sure to credit me if you were able to create a wonderful Skype-like proprietary VoIP application after reading this series of blog :-)

Reach for the sky!
Ron

Route Summarization – make your network scale

Probably one of the most critical parts of deploying and maintaining a network is route summarization. Many of you may find this easy, may be in an ideal network yes, however it is never perfect out there in the real world. Even I would admit that the summarization of our IPv4 addresses is not that good, at least to a point that we know we coud do better, but its already there and its virtually impossible to re-address an ISP network. That is why, planning out your address scheme is very critical into having a fine tuned and well summarized network.

Route Summarization is defined as – the technique of grouping IP networks together to minimize advertisements.

Why is summarization important anyway? Here are some of the benefits you will get in a well summarized network.

Faster routing – the smaller the routing table you have, the better. When it comes to network performance, speed is the key. We must make our routing table smaller whenever we can as this will make our routers forward traffic faster and thus resulting into a faster, more efficient network.

Hides route information details – this is to simplify your routing process. This is the key scalable routing, taking a huge set of advertisements and reduce it down to a single(if possible) or a fewer set of advertisements. You guys may refer to this as ‘supernetting’ – consolidating smaller networks into one route entry that represents a bigger network. This is good for hiding unimportant details like flapping routes. Information as detailed as this may not be significant to the neighboring routers as they may not be able to do anything about it anyway.

Reduces router resources – summarization reduces resource consumption because you save processor times for calculating routing information and reduced memory utilization due to the reduced number of routes. This would also save on network capacity there would be fewer and smaller advertisements to send around the network.

Speeds up convergence – because router with fewer routing entries has less routes to process and routers will receive updates faster. This advantage may even tuned more and may just depend on the routing protocol you are using.

Now let’s get to an example. Lets say we have 3 routers., and Router A has the networks 112.89.0.0/24 through 112.89.13.0/24 and we will be summarizing routes to advertise to routers B and C. As you can see this is a class A range chopped down into smaller class C (/24) blocks and that the first 2 octects will be the same for each and every network either we put them down in decimal or in binary.

112.89.0.0 – 01110000.01011001.00000000.00000000

112.89.1.0 – 01110000.01011001.00000001.00000000

112.89.2.0 – 01110000.01011001.00000010.00000000

112.89.3.0 – 01110000.01011001.00000011.00000000

112.89.4.0 – 01110000.01011001.00000100.00000000

112.89.5.0 – 01110000.01011001.00000101.00000000

112.89.6.0 – 01110000.01011001.00000110.00000000

112.89.7.0 – 01110000.01011001.00000111.00000000

112.89.8.0 – 01110000.01011001.00001000.00000000

112.89.9.0 – 01110000.01011001.00001001.00000000

112.89.10.0 – 01110000.01011001.00001010.00000000

112.89.11.0 – 01110000.01011001.00001011.00000000

112.89.12.0 – 01110000.01011001.00001100.00000000

112.89.13.0 – 01110000.01011001.00001101.00000000

We just wrote down each network in binary and the next thing to do is to the number of bits that match on these networks. This will result into a single summary that includes all the routes.

Looking at our example we can see that all networks are identical upto the 20^th bit starting from the left. Therefore we could assume that we can summarize all these networks as 112.89.0.0/20 or 255.255.240.0. Now to check if we are correct we have to lay out the possible networks that this summary will include. The fastest way to achieve this is to simply put down in binary the first and last network within this summary route. The first network in the range will be put down as is in binary and the remaining bits will be turned on to determine the last network in the summarized range.

Using our example here is the binary to decimal conversion:

01110000.01011001.00000000.00000000 – 112.89.0.0/20

There we understand that the bits in bold are our network bits right? So we can only turn on bits upto the 24^th bit or the last bit in the octet were we are in (3^rd) and stop at that classful boundary. If all those remaining bits are turned on the result would be:

01110000.01011001.00001111.00000000 – 112.89.15.0/20

Based on the results, the range of 112.89.0.0/20 covers upto 112.89.15.0/20. What does this mean? Obviously this network summary summarized all our networks in Router A which is 112.89.0.0/24 through 112.89.13.0/24 however It also included 2 more networks, 112.89.14.0/24 and 112.89.15.0/24. This simply shows that we over summarized and that we actually included the networks that we are not even advertising. This is fine if we own these remaining networks and were to advertise them anyway in the future however if this isn’t the case we can’t just do that, specially in public IP routing because you can only advertise the range that was assigned to you and nothing more.

The next step would be to find the range in between wherein we can summarize properly without over summarizing. To find that out we just have to move our summarization 1 bit smaller. When I say this I mean we have to move 1 bit to the right and check upto which network we can summarize and stop there then move on to summarize the remaining networks that were left out.

Going back to our example we used a /20 mask and since we have to move 1 bit to the right we then have to use /21 as our mask. Let us check again to see the range of this mask.

01110000.01011001.00000000.00000000 – 112.89.0.0/21

Setting the remaining bits to 1 will result to:

01110000.01011001.00000111.00000000 – 112.89.7.0/21

Knowing this we determine that the networks that have the same matching bits is from 112.89.0.0 through 112.89.7.0 and thus can be summarized without over summarizing.

What happens now to the remaining networks? Ofcourse we start all over again and try to summarize what is left.

112.89.8.0 – 01110000.01011001.00001000.00000000

112.89.9.0 – 01110000.01011001.00001001.00000000

112.89.10.0 – 01110000.01011001.00001010.00000000

112.89.11.0 – 01110000.01011001.00001011.00000000

112.89.12.0 – 01110000.01011001.00001100.00000000

112.89.13.0 – 01110000.01011001.00001101.00000000

Looking at the remaining networks in binary we can see that we have the bits matched upto the 21^st bit. Will we over summarize if we use this mask? Lets find out.

01110000.01011001.00001000.00000000 – 112.89.8.0/21

Turning on the remaining bits will give:

01110000.01011001.00001111.00000000 – 112.89.15.0/21

It’s over summarized again and so then we try again and move 1 bit to the right.

01110000.01011001.00001000.00000000 – 112.89.8.0/22

Turning on the remaining bits will give:

01110000.01011001.00001011.00000000 – 112.89.11.0/22

The proper summarization then would be 112.89.88.0/22. The remaining networks will be just easy for you:)

112.89.12.0 – 01110000.01011001.00001100.00000000

112.89.13.0 – 01110000.01011001.00001101.00000000

The matching bits for these last 2 networks is upto the 23^rd bit. We actually don’t even have to check because obviously were already looking at the first and last network in the range. Therefore the last summary we have is 112.89.12.0/23.

In summarizing our networks we ended up with 3 summary routes. We weren’t able to advertise a single route but this the best we do and is way much better than advertising 14 individual class C networks.

Here’s what we our neighbors will get in their routing tables.

112.89.0.0/21

112.89.8.0/22

112.89.12.0/23

But then wait what if we say 112.89.14.0/22? Is that possible? Just for the sake of example let’s say a colleague of yours was being cocky and asked you wether this can be summarized or not on the spot. There is no way you would get a paper and convert these networks in binary. So the real question im trying to imply here is; Is there an easy way? Ofcourse there isJ But you still got to have a pretty good math to answer it quickly. For that we have to at least have an idea how much addresses are there in a summary or in a CIDR notation.

Here's the table for this. It shows the summary mask and how many addresses are there in that specific summary.

class C	/24	/23	/22	/21	/20	/19	/18	/17	/16
/24	1
/23	2	1
/22	4	2	1
/21	8	4	2	1
/20	16	8	4	2	1
/19	32	16	8	4	2	1
/18	64	32	16	8	4	2	1
/17	128	64	32	16	8	4	2	1
/16	256	128	64	32	16	8	4	2	1
class B	/16	/15	/14	/13	/12	/11	/10	/9	/8
/16	1
/15	2	1
/14	4	2	1
/13	8	4	2	1
/12	16	8	4	2	1
/11	32	16	8	4	2	1
/10	64	32	16	8	4	2	1
/9	128	64	32	16	8	4	2	1
/8	256	128	64	32	16	8	4	2	1

I had it illustrated as using class C and class B summaries as these are the most common

summarization on the internet. If ever you get the chance to see the Inernet routing table these CIDR notations are the most that you will see.

So how are we going to use this anyway? Going back to our example we have 112.89.14.0/22 and we want to determine of this is a proper summarization without converting it to binary or any long method. The trick is to know how many addresses are there within the range of the mask used. We have a /22 mask and looking at the table we can see that it is composed of 4 class C or /24 blocks and it could also consist of 2 /23 blocks. We then take the the number on the class C octet (3^rd octet) and divide it with how many class blocks we have for the given mask, in our case we’ll ofcourse try 4 class Cs first as this is the most number of class Cs. So 14 divided by 4 is equal to what? We have 3 but we still have a remainder of 2. What does this mean? It means we over summarized and cannot use the /22 mask therefore we move on then to the next possible divisor which is 2 which then equals to a 23 block or 2 /24 blocks. So 14 divided by 2 is equals to 7 and we don’t have any remainder. This just means that 112.89.14.0/23 is properly summarized network and this range consists of 2 class C blocks. To make it clearer lets check it on binary.

01110000.01011001.00001110.00000000 – 112.89.14.0/23

If we turn on the remaining bit, this range also includes:

01110000.01011001.00001111.00000000 – 112.89.15.0/23

So we were able answer the question by familiarization with how many addresses are there in a specified mask and simple division. We then were able to check and prove our answer using binary. Doing a lot more of these would actually make yourself much faster in route summarization. Not that you need to be fast but having to determine if a route is summarized correctly by a single glance will be an advantage. Having the ability to do so saves you time in preparing configurations for your routers or layer 3 switches.

Just some final tips before I end this topic. Having to know how to properly summarize routes is good but having to know how to use summarization on different routing protocols is a different story. Routing protocols behave differently when it comes to route summarization and this means that you may have to use different techniques in doing so. Not that there are other ways of summarization but on techniques to implement with your routing protocol. For example, summarization in OSPF can only be done on Area Border Routers (ABRs) and Autonomous System Boundary Routers (ASBRs). For EIGRP on the other hand, summarization can be done on the interface level and therefore gives you more flexibility on were to advertise your summary routes. You will be taking these things in consideration when planning and designing your network along with your addressing scheme.

One common practice you must always do along with summarizing your routes on a router is creating a route to Null 0 or better known as the bit bucket interface (blackhole). Because you are advertising a summary route, other routers on your network will send packets to any network within your summary route regardless wether that network is up or down. Your neighboring routers don’t know the status of that network as information such as that doesn’t even get to them. Remember that summary routes hides the detailed information for the specific networks within your summary route. This is because when you advertise a summary route you are basically saying “For all the addresses starting with ‘n’ bits, can be found behind me – do not worry about the details, just pass on the packets and leave the forwarding of your traffic to me”. If a packet gets to that router and the destination network or address happens to be down, it either gets dropped, or it will loop around until its time-to-live expires. So in order to be sure that traffic destined to unavailable networks get dropped we put in Null 0 routes to catch all those packets.

note: in EIGRP when you create a summary route it automatically creats a Null 0 route for that summary.

I hope this has been another informative topic and you guys learned something out of it.