OSPF: Peering Basics (IPExpert VoD) – Part I December 5, 2008
Posted by cauew in L3 Stuff, Routing Protocols, Video On Demand.1 comment so far
Ok, it has been a while I don´t post anything, but believe me, it´s not because I don´t want too… I´m really away from everything due to a huge project to implement before christmas, hopefully!
That means… I do have "ocasional" internet access (like, 1h every 5 days, can you believe that?! Me neither! It´s really difficult for a "Internet Addicted" guy like me)!!!
Anyway… That´s why I´m a bit away from all the news (I can see some exciting news regarding EverythingIE and Dynamips support from IPExpert), also a new online vClass from them, and a new introductory class from Internetwork Expert! Cool! As always, the most they try to be better than the other, we win! 
Wonderful man!
Also, Joe, I saw your email – sorry for taking so long to reply, but I´ll do it soon! Very NICE diagram and observations there! Sorry for taking too long to reply it to you, but I´ll do it soon! :S
So… let´s get a bit more technical, into OSPF, those are some notes, personal understandings and mostly the instructions, tips and advices from IPExpert VoD (awesome material). OSPF is splitted in several parts on those VoD starting with peering basics, which in my opinion, makes sense, why implement other features like security before having full reachability ?! Insane if you ask me! That means, when you get into the OSPF section, don´t worry about authentication, or area type, or things like that! Get the basics peering up and functional! Period!
That means, assign the correct router/interfaces in the correct areas, like area 0, area 1, and forget everything else, like stub, nssa, and others! Take one step at a time!
Look at your diagram and check the issues you could have to peer between the routers using OSPF… For sure the first thing that will cause us problems will be OSPF and Frame-Relay…
Oh yeah… just to remember, the Frame-Relay world has 3 different Frame-Relay interface types: Physical, Multipoint and point-to-point.
Now… as far as OSPF is concerned, we have 5 different network types. Out of that, either Multipoint and Physical Frame-Relay interfaces are both going to default to an OSPF Non-Broadcast Network Type.
On the other hand, the Point-to-Point Frame-Relay subinterface is going to default to a Point-to-Point Network Type in OSPF.
That can lead us to some mismatches, depending on the frame-relay network setup and topology. As Scott likes to say, little things to be looking at, but very important!
Match your network and interface types together! First of all, timers may not match if you try to mix different interface types!
There´s also the DR Router! We must take care to make our HUB router the DR! Also, if running over a Non-Broadcast link, don´t forget the broadcast parameter in the frame-relay maps, to have OSPF actually "working" on your network (even better, on your exam!). One piece of advice is, on a point-to-point subinterface this is enabled by default.
There are some tools (AKA debug) that we can use to check this "broadcast" issue, like debug ip packet, if you get encapsulation failed, that pretty much tells you that there´s something missing (that could be the broadcast parameter in your maps, or some other kind of little thing we usually forget about).
Also, keep in mind the neighbor command! They may forbidden you from changing the network types, and things like that, we can always use the neighbor command to try to achieve neighbor relationship.
You MUST read your exam carefully and understand how it´s worded! It might tell you: don´t change the network type on the spokes, or on the HUB change to a network type other than broadcast! At the VoD Scott suggest us to start looking at the details, looking at the things that match, looking at the things that NEEDS to match in order to perform peer! Start thinking and choosing how you´re going to do stuff! A great advice!
Any interface that is Point-to-Something does NOT elect a DR, keep that in mind! But, Broadcast and Non-Broadcast will!
Broadcast – Elects a DR, and it has what we call fast timers, 10/40 sec (hello/dead) timers.
Non-Broadcast – Elects a DR, but has slow timers, 30/120 sec! It also works in the unicast fashion, it "must" have the neighbor command! Very important! It MUST have it! In order to actually operate!
But the real question is: Can we mix and match those types?! If our spokes are Non-Broadcast, can we make the HUB Broadcast?! Sure! Absolutely! We´ll have to change timers, they need to match, either fast or slow, doesn´t matter, but they have to be the same at each end.
Also… the neighbor command… where to put it on this situation?! On this "scenario" the neighbor command goes into the spokes, even knowing that we may normally have to put them on the hub! If your HUB is in Broadcast type, the neighbor command is not accepted!
As long as the timers match, and your choices about the DR, we´re good to go!
Point-to-Point and Point-to-Multipoint, same thing, you can mix and match those if I want too, just adjusting timers!
Point-to-Multipoint Non-Broadcast (Cisco Proprietary) It assumes the same type of idea the point-to-multipoint does, uses the same slow timers and stuff, but, it must use unicast packets, that means, it uses the neighbor command …
Now, in order to form a peering relationshipe, there are a number of things that needs to match!
Timers for example, it needs to match! We can change it! Like the OSPF Hello Timer, if we change the Hello Timer, the Dead Timer automatically changes (by the way, the Dead Timer can also be changed independently, to achieve any weird task if needed)!
Other things that must match:
MTU Size must match!
Area ID must match! That makes sense! We can´t peer an Area 0 guy with an Area 1 guy!
Stub Flag must match! Now, this highlights a very important rule in OSPF, one of the OSPF rules is that everybody in an Area must have the same database information! Well… what the Stub flag does?! It says a variaty of things, but it´ll tell your router it can´t have external routes as an example, what about the other router in the area, if it "wants" to have external routes!? Things are not going to work very well in this situation! Everybody MUST agree about the Stub Flag!
The same applies to Netmask! It´s important to know "we´re" all in the same network in there! There are some exceptions with Virtual-Links and Point-to-Point interfaces, don´t need to worry about that part, but, as we go through, all of these things have to match!
One very important thing is missing out of this list! That will be the DR!
Technically you can peer "something" that requires a DR with "something" that doesn´t requires a DR. However, things will be all messed up if we do that! In the DR world, somebody believes they´re in charge, and they´re the ones who can announce the routes officially!
On the non-DR network everybody has the right to announce routes, and that will mess up all of your database and reachability.
So, even knowing the DR is not a poart of the list here, you do have to match and agree to who is or is not the DR!
The neighbor command (we´re talking about it very much, don´t you think?!), is basically used when I can´t use multicast in order to get to the other side!
Technically it´s only necessary in one side of the connection, so, in a Hub and Spoke network I would probably use my Hub to put this. One place, put all the neighbors, keep life simple! But, this is not necessary! You can do it in the spokes if you want! You can do in both if you want! No big deal! But you have to have the neighbor command some place in order to initiate the conversation!
So, in our example, making the HUB Broadcast, and the Spokes Non-Broadcast, the neighbor command HAS to go on the spokes, the broadcast guy (the HUB in this situation) won´t even accept the neighbor command!
Your HUB will be sending out it´s multicast frames, no one will be talking back to it, and them, it gets an unicast from one of the spokes and says "Oh, ok! This is how you wanna talk?! Not a problem" and it´ll respond to that spoke.
Back in our example scenario… the neighbor command MUST be used in every spoke in order to trully operate! Once each of them initiates the unicast conversation the HUB will reply just fine, and everything will be working great! It takes a while, like a couple minutes, but it´ll happen just fine!
And that´s just the neighbor command!
Next post we´ll talk about the other features presented in the VoD, like loopbacks, DR, and MTU… I really gotta go now!
Nice weekend to everybody, and don´t ever give up! Keep going on your studies (check this wonderful post from Ethan Banks about this).
Cheers!
How to check your Diagram for potential Routing Loops November 4, 2008
Posted by cauew in L3 Stuff, Routing Protocols, Workbooks.2 comments
One of the most challenging tasks in the CCIE Lab is how to deal with routing loops, specially when dealing with redistribution. I still working my way through it and I still missing alot (any comments, thoughts, suggestions will be welcome!).
Anyway… I will not deal here (in this specific post of course) with the details about redistribution, and anything else. I will just check the topology for potential routing loops, and redistribution points! (and please, correct me if I´m wrong, ok?!).
Let´s check this diagram from IPExpert Workbook Vol. 3 – Lab. 1 (this Lab 1 is available for download at IPExpert Website, go get yours).
To keep things simple, forget that R4 Serial connection is also connected to R5 through Frame-Relay network, just pretend it is connected direct through Serial Interfaces, ok?!
So we have EIGRP, OSPF and RIP all over our topology, and guess which protocol was choosen to be in the Frame-Relay network?! Yes, you´re right! OSPF!
Anyway, checking it a little deeper, we can see that routers BB2, R4, R5 and R2 have direct connections and those routers are using RIP. Also, R1 and SW1 are using RIP between them! That should not take too long to be configured (depending on what is being asked), but probably not very challenge.
In the EIGRP "world" we have BB1, R6, R7 and R9 routers. Note that there are two interfaces between R6 and R9. Again, that also should not take too long to be configured depending on what the task is asking and the restrictions applied!
Now… OSPF! It´s being used between R2, R5 and R6 in the OSPF Area 256, and between R1 and R2 in OSPF Area 12.
Now that we checked the IPv4 IGP Routing Protocols in this diagram, we also need to verify it for potential Routing Loops. Check the bellow drawing:
Starting from BB2, to the top of the topology, we can see two loops in our network. One represented by the "ORANGE" arrows and the other by the "RED" arrows.
First, let´s analyze the loop in "ORANGE" between R6 and R9. It´s inside EIGRP AS679. So, this loop is "contained" inside one routing protocol. The routing protocol will deal with it. No worries!
Now… the loop between R2 and R5 (represented by the "RED" arrows). This one involves two distinct routing protocols! So we must take care when doing redistribution between those routing domains, either by using different Administrative Distance (AD), route-maps, access-list or any tool that we´re allowed to use to avoid it!
Regarding the redistribution points… we´ll need to redistribute routes in R2, R6 and "maybe" in R1, it´ll all depend on the connections!
Just keep in mind that, when dealing with routing loops we can have situations like:
Routing Loop with a single IGP: That kind of situation will not create a routing loop when redistribution is performed, because, it´ll be filtered by the IGP in use.
Routing Loops with two or more IGPs: In this situation we´ll need to take care off "manually", using filters, maps, access-lists, and other tools when dealing with redistribution, avoiding for example that RIP domain learn OSPF routes, and them send those routes back to the OSPF domain!
This analysis seens simple, but try to do it in some different diagrams on your own to get more practice, I´ll do the same!
Later we´ll discuss the details involving the redistribution and the IGPs!
Cheers!
OSPF Virtual-Links October 22, 2008
Posted by cauew in L3 Stuff, Routing Protocols.add a comment
OSPF Virtual-Links are used to extend Area 0 to routers without direct connection to OSPF Area 0.
A diagram will help us to understand this requirement a bit better:
The link between R1 F0/0 and R2 F0/0 belongs to the Backbone Area, or Area 0. The Frame-Relay connection between R2 S0/0 and R3 S0/0 belongs to the OSPF Area 1. As far as R2 has a direct connection to Area 0 (through it´s F0/0 interface) no Virtual-Links are needed.
BUT, for example, if we create a Loopback Interface in R3, and place this Loopback Interface in OSPF Area 2, what will happen?!
R3 doesn´t have any connections to Area 0, it has connections to OSPF Areas 1 and 2, but not Area 0. Check this new diagram including the newly created Loopback Interface in R3:
Hmmm… This situation will require the use of Virtual-Links between R3 and R2 using Area 1 as a "connection" to Area 0. In situations like this, where the router (in our case R3) has two or more interfaces in different areas, and none of those interfaces belongs to Area 0, we´ll need to use an OSPF Virtual-Link.
You may ask yourself: why R3 S0/0 in Area 1 doesn´t need a Virtual-Link connection also?! It´s on the same router as the Area 2 Loopback Interface, so why R3´s Loopback in Area 2 need a Virtual-Link connection, but R3´s S0/0 interface in Area 1 doesn´t?!
The answer is simple, R3 is direct connected to R2 using Area 1, and R2 is connected to Area 0, so it´ll get advertised due to R2 connections! 
Without Virtual-Links Area 2 (in this situation) would never get advertised to either R2 and R1!
First, let´s go ahead and configure all routers according to our diagram (except by the Virtual-Links):
|
R1: int f0/0 R2: int f0/0 R3: interface loopback 2 |
Ok! The above configuration is done, let´s check the OSPF Neighbor Relationship and the IP Routing Tables of our routers:
| R1:
R1(config)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set C 192.168.10.0/24 is directly connected, Ethernet0/0 R1(config)#do sh ip ospf neig Neighbor ID Pri State Dead Time Address Interface ================================================================= R2: R2(config)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set C 192.168.10.0/24 is directly connected, Ethernet0/0 R2(config)#do sh ip ospf neig Neighbor ID Pri State Dead Time Address Interface ================================================================= R3: R3#sh ip route Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Loopback2 R3#sh ip ospf neig Neighbor ID Pri State Dead Time Address Interface |
See?! Neither R1 and R2 have the 192.168.12.0/24 Network from Area 2! That´s because R3 is not directly connected to Area 0! To solve that, we´ll need to configure a Virtual-Link between R2 and R3 using Area 1 as a "connection" to Area 0.
The command to do that is: area <area-id> virtual-link <rid of the router in the other end>, for example: R3 will have the following command added to it´s configuration: area 1 virtual-link 2.2.2.2 . The same command (just changing R2´s rid by R3´s rid) needs to be configured in R2. To make things a little bit easier, here follows the configuration:
| R2:
router ospf 1 R3: |
Oh yeah! If you´re unsure about the Router ID (rid) of the router, just issue a show ip ospf command and it´ll show you the Router ID, see below:
|
R3(config)#do sh ip ospf <output omitted> |
Now, with the virtual-link configured between R2 and R3, let´s check again the OSPF Neighbor Relationship and the IP Routing Table of all our three routers:
| R1:
R1(config)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set 192.168.12.0/32 is subnetted, 1 subnets R1(config)#do sh ip ospf neig Neighbor ID Pri State Dead Time Address Interface ================================================================= R2:
R2(config-router)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set 192.168.12.0/32 is subnetted, 1 subnets R2(config-router)#do sh ip ospf neig Neighbor ID Pri State Dead Time Address Interface ================================================================= R3:
R3(config-router)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Loopback2 R3(config-router)#do sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface |
AH! Much better! Now ALL routers have ALL OSPF Routes in their IP Routing Tables! Our "hero" Virtual-Link solved our problem!
Another really usefull tip is… sometimes when you issue a show ip ospf virtual-link the output shows that the Virtual-Link is UP, but you see no communication going on, neither a OSPF Relationship established… well… sometimes that happens, to make sure that the Virtual-Link is "really" working, issue a show ip ospf virtual-link command and see if the output is just a portion of what it´s supposed to be (that will indicate a not working virtual-link) or if you have the full output. That can also be a temporary situation (while the link gets up). See the example of a BAD and a GOOD Virtual-Link output:
|
Virtual-Link with Problems (BAD): R2(config-router)#do sh ip ospf virtual-link ================================================================= Working Virtual-Link (Good): R2(config-router)#do sh ip ospf virtual-link |
To finish, another useful command (not only to Virtual-Links, but to OSPF), is the show ip ospf interface brief. This command will show you a brief of all OSPF configured interfaces, with some other nice things to know!
|
R2#sh ip ospf interface brief |
Seens a bit easier now, don´t you think?! I do!
General Routing Overview August 16, 2008
Posted by cauew in L3 Stuff, Routing Protocols, Video On Demand.2 comments
Finally I´m back at home, things are getting better, these cool pills they gave me will probably end next week (those little things are really getting me down, you have no idea of how much I´ve been sleeping last couple days because of it, I look like one of my cats now!) But that´s ok!
Well… today besides some house keeping and a little shopping at the supermarket, I was able to rest a while more, and watch the General Routing Video-on-Demand from IPExpert CCIE R&S Blended Learning Solutions.
Very informative. Everytime you see a guy saying: Ah… I don´t need general or basic concepts, I do know it already… well… ok, he may know his stuff really good, but you can ALWAYS learn a new trick, or finally put an end to that doubt that´s bothering you for so many years!
And of course! Those videos are the real concept of " State of Art" Class on Demand!
Enough on that… let´s get into the part that really pays for the product, the technical details…
The Network Command:
It starts with our friend the network command… As we all learned back in the CCNA days (on the CCNP, specially in the OSPF part of it, we start change our mind) the network command is used to advertise networks… we can´t say that´s incorrect, but there´s not the full true either! The network command actually enables an interface to participate in the Routing Protocol, thus this interface will advertise it´s network, and the Routing Protocol brings it to the RIB.
Check the example (exactly the same one on the video):
- F0/0 IP Address: 10.1.1.1/24
-
network 10.0.0.0 0.255.255.255
-
network 10.1.0.0 0.0.255.255
-
network 10.1.1.0 0.0.0.255
-
network 10.1.1.1 0.0.0.0
Regarding only this interface F0/0, no matter which of the above network statements you choose, they all do the same thing! It´ll bring the F0/0 (10.1.1.1) interface into the Routing Protocol. The network command only tells which interface will be participating in the Routing Protocol, not how the network is going to be advertised, advertising actually is a secondary reaction of it!
Secondary Address:
Also, there is a really nice explanation on the video about Secondary Addresses! Follows some concepts learned from it:
You can´t just advertise the secondary address, you need to advertise the primary first, than, the secondary if you want to. Also you can´t do passive-interface on your primary address and still send things out with your secondary address! A general rule for that is: when you send any packet out of an interface (keep in mind that routing updates are packets too) ALWAYS the source IP Address for that packest will be the Primary IP Address of that interface!
Check this example for RIP (it works for EIGRP too):
Ok, so, everyone is on the same ethernet segment… and everyone will hear about each others Broadcast and Multicast packets which is good in our scenario. When R3 sends Routing Updates to R2, R1 will listen to this too, but it´ll treat it as invalid, because, it´s not on the same subnet as R3. The same happens when R1 sends it´s Routing Updates to R2.
So… how to make this happen?! Hmmm… R2 has both networks, so if we disable the split-horizon in it´s F0/0 we´re good?! Not exact like that… Remember… R2 Packets will ALWAYS use the Primary Address (in this case 10.1.1.2) as the source, so R3 will still having problems, it works for R1, but not for R3.
The solution would be (in this particular RIP example) to use the no validate-update-source command under the Router RIP, that will tell your router to not validate the source IP Address of the routing updates when they´re received, just allow they to come in! So, to solve the problem, we can do that on both R1 and R3 of the example. Other solution would be disable split-horizon on R2 and use the no validate-update-source under Router RIP of R3, that work as well, but, doesn´t look "clean" if you know what I mean!
That basically says "I don´t care from who you learned, go ahead and allowed it to come in!"
IP Unnumbered:
Another topic brought up on this video regards IP Unnumbered!
The IP unnumbered interface configuration allows you to enable IP processing on an interface without assigning it an explicit IP Address. The IP unnumbered interface can "borrow" the IP Address from another interface that is already configured on the local Router, or Layer 3 equipment, thereby conserving network and address space.
Check out this topology:
So how can we get this topology to work?! One side of the link is 10.1.1.0/24, the other end is using 11.1.1.0/24… How can that work?! Well… if you´re allowed to use PPP we´re good! PPP has a feature called "peer neighbor-route", that will get the exact IP Address of the router on the other end of the link, and show it as connected in our local router!
Take a look at the Routing Table with this setup:
|
R1(config-if)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set Gateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets R2(config-if)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set 10.0.0.0/32 is subnetted, 1 subnets |
Of course, we may not be able to use PPP over this link, they may ask for GRE Tunnels or something else, if so, another solution that meets their requirements would need to be implemented, like static routes or something like that!
Administrative Distance:
I thought I knew almost everything about Administrative Distance… again… I was wrong… the Master Jedis showed me once again, that, there´s ALWAYS something to learn.
Lets check some examples, like RIP and OSPF (the ones in the video) :
If you want to change the administrative distance for RIP, you´ll just change it for RIP at all, I mean, there´s no internal, external routes or anything else in it! So you just change the Administrative Distance for RIP. Example:
| router RIP distance 140 |
After that, all RIP learned routes in the Routing Table will have the Administrative Distance of 140!
Things get a little more complicated with OSPF… In OSPF we have intra-area, inter-area and external routes! Check this example:
| router OSPF 1 distance ospf intra-area 110 inter-area 110 external 80 |
So, what that means, External Routes in OSPF will be preferred over Intra-Area routes?! Hmmm… not so fast buddy! That command does NOT change how the OSPF makes it´s decisions! It´ll always preffer intra-area routes first, than inter-area routes, and just after that the external routes!
The command only says if an external LSA wins the OSPF RIB election, than give it the administrative distance of 80, so it will be preferred over EIGRP for example! But, if it doesn´t win the election, if you get the same route announced internally from OSPF, the internal one will be used with the administrative distance of 110 and that´s it! The distance command only works if the routes gets handled to the Routing Table, that´s the order of operation!
As said earlier, it´ll NOT affect HOW OSPF makes it´s decisions!
Cool, isn´t it?!
Now, to manipulate distance for specific routes, we first need to create an access-list with the routes you want to change the Administrative Distance, the diagram bellow will give you all the reference you need specially for OSPF:
Or… instead of that, you can use 0.0.0.0 255.255.255.255 and that will tell the router to really don´t care from who it learned the route from, just change the Administrative Distance on it!
So, the command now will look like:
| router ospf 1 distance 190 0.0.0.0 255.255.255.255 20 |
Much easier, don´t you think?!
ODR:
On Demand Routing, or ODR, it´s normally used in the Frame-Relay HUB Router. It is a feature that provides IP Routing for Stub Sites, with minimum overhead!
ODR uses CDP (Cisco Discovery Protocol) to carry the "routing" information between the hub and stub routers. The stub routers send IP Prefixes to the hub router via CDP, and the hub router will send a default-route to the stub also, via CDP. Oh yeah, almost forgot, ODR supports VLSM!
It is a nice solution to be used in a HUB and Spoke topology, if your Spoke is also a Stub Router.
The only thing you need to do is: start the ODR proccess in the HUB Router, nothing else, considering that your network is already configured. The command to achieve this is: router odr.
Don´t forget…ODR uses CDP, so in our frame-relay example, we´ll need to allow broadcasts in the map statements, and also, enable CDP in the frame-relay interface (you can check in CDP is already enabled or not with the command show cdp interface, if it is not you can enable it with the command cdp enable).
So what will happen now?! The HUB Router will send a default-route to the Spoke (that will set up the gateway of last resort to the ODR hub router), and the Spoke will send it´s IP Prefixes to the HUB Router, check the diagram below, you´ll get the idea:
Check the Routing Table for R1 (HUB) and R2 (Spoke):
|
R1(config-router)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is not set 15.0.0.0/24 is subnetted, 1 subnets R2(config-if)#do sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP Gateway of last resort is 10.1.1.1 to network 0.0.0.0 17.0.0.0/24 is subnetted, 1 subnets |
Also, keep in mind that as soon as you enable any other Routing Protocol in the Spoke, that ceases to work. The Spoke will still learne the 0.0.0.0/0 default-route, but it´ll no longer send up to the HUB any detailed information about it´s networks, that will be done by the Routing Protocol if you configure it to do so!
So, to summarize:
HUB –> Spoke = 0.0.0.0/0
Spoke –> HUB = advertise it´s connected networks.
One more piece of advice… this may be a way to get a default-route without using any static route or default-information originate in the exam!
You can find more information about ODR either on IPExpert CCIE R&S Blended Learning Solutions or in Cisco´s Website, the following link is a good start:
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080093fde.shtml#t7
Last thing… those Videos from IPExpert ROCKS man! If you´re following my posts till now, you now that already! It really looks like I´m attending a "on-site" bootcamp! I´m loving it!
ARP, RARP, Proxy ARP, Gratuitous ARP and IP Redirect August 14, 2008
Posted by cauew in L3 Stuff, Layer 2 Protocols, Switching.2 comments
Well… after a while away from my computer (in fact, away from any computer) due to some medical issues I´m back! Don´t worry, nothing bad, it was scheduled already, and I had the company of my wife, and guess who?! Yeah! Him! Mr. Jeff Doyle, not in person, but in his book version!
Books like TCP/IP Vol. 1 and 2 MUST be read from cover to cover! Always a good thing to learn!
Some of you may think, ARP, too basic… Yeah, I think too, but there were more than 10, 20 times that people who were supposed to know this asked me HOW it works… so here (with mr. Doyle´s help) you´ll find ARP some variations of it.
ARP
Address Resolution Protocol (ARP) is used to map a known IP Address to a unkown data-link identifier (for example MAC Address). The ARP Request will contain:
-
Source IPv4 Address;
-
Source data-link identifier address (MAC Address for example);
-
Destination IPv4 Address;
-
Destination data-link identifier (MAC Address in our example) will be set to 00:00:00:00:00:00.
Check this ARP Request capture:
|
Ethernet II, Src: 00:30:b8:83:cb:40, Dst: ff:ff:ff:ff:ff:ff |
By default Cisco Routers holds the ARP entries for 4 hours. You can change this value per interface basis with the command: arp timeout <value in seconds>. Example:
| interface fastethernet 0/0 arp timeout 3600 |
RARP
RARP is the opposite of ARP, it maps an IPv4 Address to a know MAC Address, for example, old workstations (dumb terminals) could have it´s firmware programmed to send a RARP request as soon as it was powered up, and a RARP Server would answer this RARP request with the workstation´s IP Address (Airline Companies used it ALOT in the past). Hmmm.. looks like DHCP right?! Yeah.. it looks, but it ISN´T ok?!
RARP Request will contain:
-
Source and Destination data-link identifier (MAC Address in this example) will be the local host MAC Address;
-
Source and Destination IP Address will be set to 0.0.0.0.
Check this example capture of a RARP Traffic:
|
Ethernet II, Src: Marquett_12:dd:88, Dst: ff:ff:ff:ff:ff:ff
—> EXAMPLE TOOK FROM Wireshark Wiki <— |
Proxy ARP
A Proxy ARP enabled Router answers ARP requests intended for another machine, it does that by making the local host believe that the Router is the "owner" of that IP Address, local host will forward the traffic to the Router and the Router will be responsible to "route" the packets to the real destination.
For example, a Host in Subnet A wants to send traffic to Host in Subnet B, Host A and Host B are in the same subnet, but in different broadcast domains. Host A will send an ARP Request with Host B IP Address, the Router connected to both subnets will answer to Host A request using it´s own MAC Address instead of Host B MAC Address.
Now when Host A wants to transmit traffic to Host B, it´ll send to the Router MAC Address and the Router will just forward the traffic to Host B. That´s why "Proxy ARP".
It´s used on networks where the hosts are not configured with a default-gateway.
Oh yeah… it´s enabled by default in the Cisco IOS, and you can disable it on a per-interface basis with the command: no ip proxy- arp
Gratuitous ARP
In some circunstances a Host (Router, Switch, Computer, etc) might send an ARP Request with it´s own address as the target address… But, to his own address?! Why a host would do that!?
Well… there are some reasons… for example:
-
It´s use to update other devices ARP Table (when a device receives an ARP Request with an IP that it´s already in it´s cache, the cache will be updated with the new information;
-
HSRP Routers that takes over the control will send Gratuitous ARP out the network to update the cache table of other devices ;
-
To check for duplicate addresses (if the host receives a response, it´ll know that somebody is using the same IP Address).
You can check this Gratuitous ARP traffic captured with Wireshark (the best opensource sniffer out there):
|
Ethernet II, Src: 02:02:02:02:02:02, Dst: ff:ff:ff:ff:ff:ff
—> EXAMPLE TOOK FROM Wireshark Wiki <— |
IP Redirect:
IP Redirect is used by routers to notify hosts of another router on the data link that should be used for a particular destination.
For example, Router A and Router B are connected to the same Ethernet Segment, so as Host C. Host C has Router A set as default-gateway, Host C will send the packets to Router A, and Router A sees that the destination address of the packet is reachable via Router B, so Router A must forward the packets out the same interface it has received to Router B. Router A does that, and also, sends an ICMP Redirect to Host C informing to use Router B to reach this particular destination next time.
IP Redirect is enable by default in IOS Routers and can be disabled on a per interface basis with the command: no ip redirects.
That´s it! I´ll lie down a while, my head is a little fuzzy right now!