1. “The proctor messed with my pod”



You are going to see this come up time and time again and I can assure you that it is not true, maybe. My personal experience is that it was true one time out of the three times I took the exam.

2. You are not allowed to leave the room during the exam.



This is not true, you may leave the room for the bathroom and to refresh yourself with drinks etc.

3. The proctors are aggressive and unhelpful.



I have found the proctors to be hugely helpful and very patient despite my provocation with stupid questions.

4. During lunch you are searched when you leave/enter the room.



I only ever heard of this once. The guy apparently tried to go outside during lunch break for a smoke...

5. The VOIP guys turn up their phones to distract you.



I can honestly say that the VOIP guys in my labs have always been extremely courteous and turned their phones down.

6. When you pass the exam a company will employ you for your # and you won’t even have to work



Actually this is a truth...nah just kidding. Cisco have strong rules about this sort of thing going on. ‘Rent-a-CCIE’ no longer operates.

7. You are not allowed to wear ear plugs in the exam.



Yes you are so long as they are not also connected to a short wave radio with your mate outside passing you football scores.

8. I failed because kit in my pod was broken.



Well all I can say on this one is that you are allowed time at the end of the exam if you have some fault with your pod so failing because you ran out of time is probably your fault for not finding the fault soon enough or sitting on your hands.

9. You run out of time because the proctor finished the exam early.



The exam is a fixed length of time. From the minute you start you will have a goal finish time and that's that.

10. You can't leave early even if you are finished.



It's not prison man, you can leave that exam whenever you want to. If you walked out because it wasn't working out for you then thats time you lost to study so far as I am concerned. If you left early because you finished just be sure you saved your configurations!
View Comments

1. Learn the DOC-CD.



No-one ever passed without touching the Cisco documentation resource. It used to come on a CD, then briefly I saw a few DVD's, but right now the Cisco documentation is only available on the web. Make it a part of your study regime and always make a point to learn new technology using the Cisco Support documentation. Go to cisco.com and use the support (Doc-CD) during your studies - it is the only reference you get in the lab and I used this a lot - I don’t know anyone who passed without knowing where to find configuration using the doc-cd.

2. Participate in online forums and study groups.



Places like ieoc.com and studygroup.com bring thousands of like-minded people together. These are usually busy places and can be intimidating if you are just starting your journey but you will find them friendly and rewarding. Commercial entities like cisco.com and ipexpert can also be valuable places to socialise. Challenge what you know and do not be afraid to ask stupid questions. Like my teachers used to say, the only stupid questions are the ones you don't ask.

3. Read before you 'do'.



One of the biggest challenges for engineers is not rushing the process and jumping in with both feet first. I always make if a point to read about a technology before I start to 'lab it up'. Think of it as ‘mental fasting’ try to force yourself not to lab up without understanding first. Putting into practice something which you have understood is more rewarding because you can push the boundary of what you know and try out new ideas. Make the lab the 'carrot' for your reading 'cart' and pull your study plan along.

4. Prepare yourself to study.



The worst thing you can do is study when you are tired, you won't learn anything. Did your parents never tell you the old saying. “Early to bed and early to rise makes a man healthy, wealthy and wise”. One of the most common mistakes I made were done when I was tired. Take time out to rest yourself or you will read and re-read and re-read. You may stay up for long hours trying to study but fatigue means you will end up learning nothing. The next day you beat yourself up and work harder the next night etc etc. Studying while tired is self-defeating and more importantly demoralising.

5. Drink me, eat me.



So the CCIE lab is not the same as ‘Alice in Wonderland’? Well getting to the exam in the morning does feel a little like the late rabbit. 'Drink Me' is all about hydration and is probably just as important as getting to the exam on time. If you don't believe me just do a search for studies done comparing people who do and don't drink water while they study. Didn't you ever ask why kids drink water in school? It’s not just because they are thirsty, proper hydration is essential for concentration.

So waht about 'Eat Me'? Well food is essential of course but I find it can also be a distraction to study. If you eat well before you start studying you may not be as tempted to get out of your seat to raid the fridge! Snacks are a great excuse to stop studying so instead give yourself comfort breaks at regular intervals. Set a goal or target, achieve the goal and take a break.

6. Get rid of distractions.



Now I'm not telling you to leave your partners here or palm off your kids to family and friends but you need ‘me’ time Have a look around your 'study place'. Are you nervous of interruptions while you sit there? If you expect things to happen like the phone to ring or someone to disturb you then you will not immerse yourself properly. Find a quiet place, move away all distractions. You really don’t need that ‘Newtons Cradle’!

7. Plan the work.



Have a diary of things to study. Look at the blueprint for your exam from cisco.com/go/ccie and segment the time you have between now and the day you are going to sit it. Be sure to each day as it comes and achieve your study goal for that day.

8. Make your goal achievable.



Be completely realistic about what you can achieve in your life. You know your strengths and weaknesses and how much time you'll need to work on each technology. Consider your life, which brings us to point 9.

9. Consider your time.



Consider your family and friends as well as your social life. Make sure to keep your mind healthy by not compromising everyone and everything in your challenge. Forgetting the world could lead you to get depressed and frustrate those around you. When you fly back with that PASS you want people around you to be there to celebrate with you so be careful not to push them away.

10. Work the plan.



Luckily you've got a lot of of 'knowns' in the plan. You’re studying for the CCIE and that means you get a blueprint. You know what you want to achieve and crucially (if you followed point 7) you know what you don't know (this is key, "know the unknowns"). Finally you know how long you've got before the exam so you can and should put some thought into your study diary. What can you achieve? Put your goals down on a piece of paper and stamp it to the wall, door etc. Focus on the goal, work through your plan, don’t be distracted and you will achieve!

11. This Top-10 goes to Eleven



I'll leave you with a piece of mumbo jumbo. My wife is a pretty spiritual soul and one day she came to me with an idea from the 'Ether'. I was told to take my goal and write it down on a piece of paper and stick it to the computer monitor. My goal took the form of a CCIE badge with a fake # on it and a pass date of my booked exam date. Looking back now it did definitely help me focus and as mumbo jumbo goes, it's not a bad idea to set a focus. I know this technique has worked for a lot of people and won't dismiss it. Each to their own.

I wish you all the very best of luck in your studies
Rich
View Comments
Before you start this article you should get your time sorted - read all about setting up NTP in IOS with our NTP article. Remember logs are useful when taken in context. If the time is wrong on your router then you can forget using them in any meaningful way when it comes to diagnosis.

Just so we are clear, logs and debugging is useless without context - you need to have your networked devices synchronised with each other and with a common time source. If you time is out then your logs have little or no value for things like event analysis, trending, capacity planning and forensic analysis.

*** SO STOP READING THIS AND SORT YOUR TIME OUT FIRST ***

Time right now? Then we’ll begin...

Logging the messages created from your device is a very useful for troubleshooting a variety of issues we’ve already discussed like event analysis (i.e. a fault on your device caused x,y and z to occur at this time) and forensics (e.g. during or after a security incident). So what happens when your router reboots and you want to see those logs? Well it’s likely you’ve only setup logging to the buffer (in volatile RAM) on the device so when it reboots you’ve lost all of that useful data. What if your device is being hammered by bad traffic or a flapping interface which fills up the available buffer space (the amount of RAM allocated to log messages). Wouldn’t it be great to keep those logs for historical purposes?

Damn right - here are some logging options.

First of all we need to enable logging with the global configuration mode command ‘logging on’. You should perhaps note that this is the default...hopefully nothing to worry about unless some unscrupulous or crap engineer has disabled logging.

In this screenshot the router has booted with a clean configuration. Basic things like hostname, interface IP and VTY access have been setup but rest assured, no logging configuration has been done...so what do we get enabled by default?

show logging

Syslog, enabled; Console, enabled; Monitor, enabled...what does all this mean?

Syslog monitoring is a double-edged sword. In this regard we could (if on a PIX/ASA) be talking about SNMP traps but in this case we’re saying what logging information should be sent over the network to a syslog server.

Monitor logging is all about remote sessions to the device. When you telnet or SSH onto the device you wouldn’t see any logging information even if this is turned on. To see this logging data the operators needs to issue the ‘terminal monitor’ command.

Console logging is all about local access to the device. By local we mean access from devices connected via their ‘console’ port. This is probably the best place to have logging turned on but you don’t want to have too much logging since a serial port can easily become swamped with logging information.

Buffer logging is a historical dump for logging data. Lets say an event occurred a few minutes ago and you want to see what happened. You can telnet to the device, issue a ‘show logging’ command under privileged EXEC mode and you’ll see a list of historical logging data.

So what can and should we tune for logging data? Here are the headlines:

  • Syslog - send too much traffic to your syslog server and this means more network traffic which could cause a network capacity issue not to mention you are going to fill up your syslog server disk more quickly.
  • Monitor - remember this is logging being sent to a telnet or SSH client. Again, as with syslog, you will be increasing your network utilisation which could be bad, particularly so if you are seeing the logging increase as a result of service issues related with network capacity issues. Logging too much over the monitor session and you will lock out that session causing you to dump the session and restart your connection.
  • Console - unlike the monitor session the console is way slower normally running at 9600 baud not 100Mbps! If you set logging levels which are too high you are almost certainly going to lock yourself out of the console session. If you are already experiencing network issues then the console is your only hope of getting meaningful telemetry out of your failing device. Setting logging levels too high on the console WILL lockout your serial connection period! Avoid if you like your job. The only way to bring a router back from a lost console due to high logging levels is usually to reboot it.
  • Buffers - this is a memory risk. The facts are that you want to go back in time to look at historical logs. Well thats great but logging for too long runs a risk of consuming more RAM which could be used for other things. It’s a fine line between keeping logs for as long as you can and not consuming previous RAM when you could actually store historical logs on an external device like a syslog server.

What about those logging levels? What does ‘logging debugging’ mean? Well we can tell the device to log more or less verbosely to include more or less functions. There are 8 different logging levels available and each one logs more and more data as you pass from a lower to a higher number i.e 0-7 with 7 being the highest or most verbose level.

  • Emergency (severity 0)—The system is unusable
  • Alert (severity 1)—Immediate action is needed
  • Critical (severity 2)—Critical condition
  • Error (severity 3)—Error condition
  • Warning (severity 4)—Warning condition
  • Notification (severity 5)—Normal but significant condition
  • Informational (severity 6)—Informational message
  • Debugging (severity 7)—Debugging message
So, now we know the defaults, we know the types and we know about logging levels. Lets consider the main logging types in more detail.

Buffering



We’ll consider buffering first since it’s the simplest to start with.

Take a look at the following output from a ‘show logging’ on a Cisco wireless AP.

show logging

This output is using something called the logging buffer. Notice the logging buffer is 1048576 bytes? Well we’ve increased the buffer here from the default of 4096 bytes or 4Kbytes. It is not uncommon to find this is one of the more obvious tweaks you would want to do on your IOS device. To explain the point imagine a very busy router being hit hard with a flapping port. The state of the interface goes up and down every few seconds or so and each of those logs are sent to the history buffer. Pretty soon the log is going to fill up and when it gets full we move to FIFO mode (first in first out) and we start to drop out the oldest messages. If you, as an engineer, are being asked to find out when this started happening and you are depending on the log output...you’d better hope your log buffer is big enough.

Now, what you shouldn’t do is change the buffer size without looking at your available RAM. Remember the logging buffer sits in RAM so the more you reserve for logging, the less you have for any other processes. Right, lets take our vanilla configuration and turn on the buffering of log files to RAM.

enable logging to buffer

Whats the default buffer size again?

show logging buffer

To change the buffer size we simply issue the following command, we’ve changed this to 4 times the default or 16384 bytes

changing cisco ios logging buffer size

Thats great, we’ve got a bigger buffer, but what if the buffer still fills up? What if we choose to log more data by increasing out logging levels? The best way to make sure we catch all data and can keep an infinitely more long term history is to use syslog.

Lets configure our 2600 router for SYSLOG. We’ll tell the router to log at the highest level and send it’s logging data to our SYSLOG host running on IP address 192.168.1.34.

First of all lets configure the logging server. We use the command ‘logging host’ followed by the IP address of the SYSLOG server

Screen shot 2011-06-19 at 23.05.54

Now, before we move on here I’m going to bring back my first statement in this article regarding time and logs. Logs need context - SORT YOUR TIME OUT ;-) Seriously, without time-stamping the log data it has very little use or meaning. So how can we fix that?

OK first lets make sure we are using NTP and we are synchronised (if you have not done this then follow our NTP ‘howto guide here’.

Here is a screenshot from our NTP. We are synchronised, all is ready to go.

show ntp status

So now we need to make sure that our logs get time stamped. Lets first look at a log file which has been written to the buffer. To demonstrate the issue we’re just going to perform a ‘shutdown’ then a ‘no shutdown’ on FastEthernet0/1.

log buffer showign interface up and down

Notice that the log in the buffer shows the state change to down and back again...but we have no way of knowing when this happened. Enter time-stamping!

enable cisco ios timestamp

The ‘service timestamps’ command allows us to prepend any logs with the current time and date. We have told the router to use the actual date for the log (rather than the number of seconds since the box was brought into service) and to include information like the timezone (in case we are going to export these logs to another country working with UTC when the logs were sourced in a country working with summer-time which it could be out by an hour. We’ve also told it to include the year which is off by default. Remember of course the more you add the more buffer space is used up....it’s all about compromise.

Lets take a look at the same ‘shut/no shut’ with the timestamp on.

ios logging buffer output with timestamps

Awesome, now we have prepended the time and date which is perfect for troubleshooting. Notice the first two log entries were still in there without the time and date.

Monitoring



When you connect to a cisco device be it a router, switch or firewall you may wish to turn on debugging to more closely watch what is going on. Now normally the debugs are not sent to the telnet or SSH session so we need to tell the device to override the normal behaviour and to send those debugs and other messages to the VTY console and not just the serial port of buffer and sysiog.

This type of redirect to screen is called ‘monitoring’ and is akin to the unix ‘tee’ or shell redirect ‘2>’ command where stderr can be sent to another process.

Lets have a look at a normal session. We’ll telnet onto the 2600 router we already setup with buffering. We’ll telnet on and tell the router to debug HRSP. Then we’ll build an HSRP instance on the interface Fa0/0 and look for the console messages to scroll on the screen.

Firstly lets turn on debugging

hsrp debug

OK great now lets turn HSRP on interface Fa0/0

hsrp interface configuration

I waited for a minute but there were no messages on the screen...thats what we expected right?

OK so now we’ll turn on monitoring. Now remember the level of information we will receive on the screen is related tot he level of debugging stated in the ‘show debug’ statement we saw earlier so currently we are at level ‘debugging’ which is more than enough.

terminal monitor configuration

Ok, we enabled the log redirect to screen with the ‘terminal monitor’ keyword. Then when we disabled the HSRP on the interface we got the debug information sent to the screen. Awesome.

Syslog



OK the last subject to cover off in our brief stop off is syslog. Syslog is used by Unix systems as a method of “System Logging” for services or daemons running on the box. It evolved to include remote syslog where devices could sent information about the services and authentication etc across to one central unix box to manage the lot.

In our world, network engineers depend on syslog heavily to troubleshoot issues we see on the network. Syslog is probably one of the best tool in your box and should be ignored at your peril - you will need it one day.

Right lets setup some basic logging. I’ve got a syslog server running on host 192.168.1.34. I’ve enabled the fantastic syslog server tool from solarwinds.com for the test. We’ll begin by telling the cisco router where exactly to send it’s logging information:

ios syslog host configuration

The ‘logging host’ command simply tells the router where to send it’s syslog traffic. Right now lets bring down that fastethernet interface again

logging monitor output

We see that the interface Down and Up is shown. Notice that the interface goes DOWN before the router has setup the logging to the host - it took that first log message to startup the syslog service. Once it is started though, we’re golden.

Now on the syslog server itself we don’t see the interface going DOWN because the logging wasn’t running at the time.

solarwinds syslog collector

Notice one of the benefits of the remote syslog server. Do you see that the time and date that the event was received is recorded on the far left? Having the syslog servers time correct is clearly one of the more important things since ALL of your logs will be stored on this and having a fixed time reference for all of your logging is invaluable.

Facilities and Levels



I use facilities for all the wrong reasons I’m sure. Back in the days when I was a unix administrator I used to have syslog daemons pointing at one master syslog collector. The syslog collector was configured using facilities where each of the facilities available was used for different hosts. I’d have my SUN boxes pointing at local1 and SGI pointing at local2. Each facility would then have the different logging levels inside it. I used facilities like a pigeon hole for internal mail.

Now I’m not sure if that was right or wrong and I never bothered to find out, it just worked for me. There are more than a dozen facilities available for different uses including local, system wide, UUCP (unix to unix copy), mail, clock and more besides but I’d suggest you don’t move away from the default.

I guess this concludes our brief run into logging today

Thank you for reading, please leave us some feedback.
View Comments
In this scenario what we did was to put a router behind each bridge then configure GLBP on the routers. By using GLBP and setting the load balancing mode to ‘round-robin’ we allowed for a kind of ‘L3 ether-channel’ across the wireless. The dual-band radio’s allowed us to run both the a and g channels at 54Mbps and get a ‘by the book’ 108Mbps per bridge which means the customer gets 216Mbps. We met the requirements, they ratified the design and the investment was made. As it turned out we got about 150Mbps because of loss but you know what, they only ever used about 10Mbps at the most anyway which was a good conversation I assure you.

So what about GLBP, what is it that makes it a better FHRP than say HSRP or VRRP? Well unlike these other two, GLBP (or Gateway Load Balancing Protocol) is capable of distributing load between the other members of the GLBP group. Take for example three routers connected to one network segment. Each router is sitting in the same network of 192.168.1.0/24 with R1 being .11, R2 being .12 and R3 being .13. Now if this were HSRP or indeed VRRP those routers can operate as one HSRP or VRRP group too but only one of that group is active. Only one can forward traffic, the others are just sat there doing nothing except waiting for something bad to happen to the active node.

With GLBP there is still a master of sorts and that is called the AVG or Active Virtual Gateway. The AVG is elected in much the same way as the active node in HSRP and VRRP. Each node has a priority of 100 by default and the highest priority node in the group is elected as the AVG. Again, just like HSRP and VRRP the AVG when elected will not be de-selected for any other member of the group unless it is lost (e.g. the box running the AVG fails). You can however, just as with HSRP and VRRP chose to allow any member to take over control as the AVG if we set a higher priority and configure preemption.

So, how does GLBP work. Well GLBP is a great way of load balancing traffic between multiple gateways while at the same time allowing for automatic failover in case one of the members fails. We can set the load balancing to round robin where the source traffic is balanced equally to each node based on an ‘R1, now R2, now back to R1, then R1’ basis. We can also set a preference known as weight to send say 75% of traffic to R1 and the remaining 25% to R2.

How does it manage the load balancing? Well it uses a cool technique of virtual MAC allocation. Basically the AVG manages the GLBP group members. It knows the MAC addresses of the neighbors and it knows the virtual IP address (VIP) associated with the cluster. When a client sat behind the GLBP group wishes to send network traffic outside of the local network it ARP’s out for the MAC address of its gateway. This request comes into the GLBP AVG the AVG passes back a virtual MAC address (associated with one of the members of the group) to the client. The client then has that MAC address in it’s ARP table associated with the gateway VIP. Now when the client sends its data it sends it to the VIP. The AVG manages this whole process to make sure a distribution of traffic across the nodes in the group based on the load balancing configuration (.e.g. round-robin, none, weighted etc).

Lets take an example, here we are going to have three nodes in the GLBP group. Each node is going to be sharing the virtual IP address 192.168.1.1 and the clients will be using that IP address as their default gateway. Our clients will be R1 and R2. Nodes R3, R4 and R5 are members of the GLBP group which we will configure as group 1.


Screen shot 2011-06-18 at 11.42.50


Each of the nodes have been configured with the following IP addressing:

R1 Fa0/0 = 192.168.1.101
R2 Fa0/0 = 192.168.1.102
R3 Fa0/0 = 192.168.1.3
R3 Fa1/0 = 10.1.1.3
R4 Fa0/0 = 192.168.1.4
R4 Fa1/0 = 10.1.1.4
R5 Fa0/0 = 192.168.1.5
R5 Fa1/0 = 10.1.1.5
R6 Fa0/0 = 10.1.1.106
R7 Fa0/0 = 10.1.1.107

Lets start out by setting up a basic GLBP configuration on R3. Lets make R3 the AVG of the group by default, it will become the AVG because there are no other members. We’re going to turn on GLBP debug with the commands:

R3#debug glbp events
GLBP Events debugging is on

R3#debug glbp packets
GLBP Packets debugging is on


Lets turn on GLBP for the FastEthernet0/0 port. We’ll define the virtual IP address to bind to that interface (remember that there is already an IP address assigned to this interface of 192.16.1.3)

R3(config)#int f0/0
R3(config-if)#glbp 1 ip 192.168.1.1


Lets walk through the process:

*Mar 1 13:25:22.768: GLBP: Fa0/0 API 192.168.1.1 is not a GLBP address in table 0
*Mar 1 13:25:22.772: GLBP: Fa0/0 1 Disabled: a/GLBP IP address configured
*Mar 1 13:25:22.772: GLBP: Fa0/0 1 Disabled -> Init
*Mar 1 13:25:32.780: GLBP: Fa0/0 Interface up
*Mar 1 13:25:32.780: GLBP: Fa0/0 1 Init: d/GLBP enabled
*Mar 1 13:25:32.780: GLBP: Fa0/0 1 Init -> Listen


See that first line - this is GLBP doing a ‘double take’. Before I star this, do I already know anything about GLBP on this interface. Clearly it’s a no and the GLBP process goes form being disabled n the interface to active by moving to the Initial or Init phase. Right, GLBP is now ‘up’ on the interface (NOTE: this is not saying the interface moved from down to up). Right, into Listen phase. Now this is all good stuff, it looks exactly like almost every other protocol we ever saw ever...whats the best part of a conversation? The answer is listening before you speak, that way you won’t put your foot in it.

This is a ‘listen’ packet. See I’m asking specifically for ‘Grp 1’ this was our group. Our priority is 100 - thats the default. We’re going to send one of these every 3 seconds (3000 milliseconds).

*Mar 1 13:25:41.780: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Listen pri 100 vIP 192.168.1.1 hello 3000, hold 10000

Right I’ve done enough listening now, I heard nothing, so I’m going to shout out my intention to be the GBLP ‘man’ for group 1

*Mar 1 13:25:42.780: GLBP: Fa0/0 1 Listen: g/Active timer expired (unknown)
*Mar 1 13:25:42.780: GLBP: Fa0/0 1 Listen -> Speak


We’re going to send these Hellos now again every 3 seconds for a maximum of 10 seconds. See how we’re now in ’Speak’ mode not ‘Listen’

*Mar 1 13:25:42.780: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Speak pri 100 vIP 192.168.1.1 hello 3000, hold 10000

OK I’m not hearing anything coming back at all so I don’t need to assert my awesomeness anymore. I’m going to move into a the ’Standby phase’

*Mar 1 13:25:52.780: GLBP: Fa0/0 1 Standby router is local
*Mar 1 13:25:52.780: GLBP: Fa0/0 1 Speak -> Standby


One more Hello before I hit my 10second timer

*Mar 1 13:25:52.780: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Standby pri 100 vIP 192.168.1.1 hello 3000, hold 10000

Right lets transition into an ‘Active’ state now. I’m the AVG!

*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Standby: g/Active timer expired (unknown)
*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Active router IP is local
*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Standby router is unknown, was local
*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Standby -> Active
*Mar 1 13:25:52.784: %GLBP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active


OK so now thats sorted I’m in control of assigning the virtual MAC addresses. That means I need to think of one. So I’m going to call out, again, to see if anyone else is using the MAC address I want to use.

*Mar 1 13:25:52.788: GLBP: Fa0/0 1.1 Disabled: a/Forwarder MAC address acquired
*Mar 1 13:25:52.788: GLBP: Fa0/0 1.1 Disabled -> Listen


Right - lets whiz out a few ‘Hellos’ to see if anyone responds to my MAC address.

*Mar 1 13:25:52.788: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Active pri 100 vIP 192.168.1.1 hello 3000, hold 10000 VF 1 Listen pri 167 vMAC 0007.b400.0101

I’m asking about virtual MAC 0007.b400.0101. Lets have a look at this MAC. Well we build this up using a common MAC in the first instance of 0007.b400. Now the next 16 bits are up for grabs. The 01 closest to the left is derived from the group number i.e. group 1 is 01, group 2 would be 02 etc. You can have a maximum of 1024 groups so I guess we can use up to 10 bits for group (we can have 4 forwards per group). The right most two numbers of ’01’ relate to the member ID. First member to come up gets 01, next is 02 etc...

OK so, we’ve run out of time and not heard anyone complaining about the vMAC so we’ll assert that on our interface now and go active.

*Mar 1 13:26:02.788: GLBP: Fa0/0 1.1 Listen: g/Active timer expired
*Mar 1 13:26:02.788: GLBP: Fa0/0 1.1 Listen -> Active


Check out the VF keyword here in this debug - VF = Virtual Forwarder.

*Mar 1 13:26:04.788: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Active pri 100 vIP 192.168.1.1 hello 3000, hold 10000 VF 1 Active pri 167 vMAC 0007.b400.0101

OK so we’re up and running. I’m going to ping out between R1 and R6 now then lets have a look at the ARP table on R1.

R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/29/40 ms


Here is the ARP table. We’ve got the MAC address for R3’s Fa0/0 interface and the vMAC address for the GLBP group.

R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 1 0007.b400.0101 ARPA FastEthernet0/0
<-- this is the Virtual MAC
Internet 192.168.1.3 67 cc02.05a1.0000 ARPA FastEthernet0/0
<-- this is the MAC for R3
Internet 192.168.1.2 75 cc02.05a1.0000 ARPA FastEthernet0/0


All good stuff. At the moment then you are looking at a virtual mac and a virtual IP address running on the physical Fa0/0 interface on R3. But this is a First Hop Redundancy Protocol right so we need to add in some redundancy. Lets load up GLBP on R4 and add it to the cluster group running on R3. First we go into the interface then add the GLBP statement. Notice it’s using the same GLBP group number as R3 and the same virtual IP address of 192.168.1.1.

R4(config)#int f0/0
R4(config-if)#glbp 1 ip 192.168.1.1


On R4 with no ‘debug’ running this is the output on the console. We see the GLBP process going through a forwarding state change from Listen to Active for GLBP group 1.

*Mar 1 13:53:13.140: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 2 state Listen -> Active

This is the debug running on R3. Notice it has seen the Hello’s from R4 (192.168.1.4) and the AVG running on R3 has agreed with R4 that R4 is to become the standby router for that group.

*Mar 1 13:53:06.412: GLBP: Fa0/0 1.2 Disabled: a/Forwarder MAC address acquired
*Mar 1 13:53:06.412: GLBP: Fa0/0 1.2 Disabled -> Listen
*Mar 1 13:53:20.412: GLBP: Fa0/0 1 Standby router is 192.168.1.4


Looking back on R3 we can examine the status of the nodes in the current GLBP cluster.

R3#sh glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Fa0/0 1 - 100 Active 192.168.1.1 local 192.168.1.4
Fa0/0 1 1 - Active 0007.b400.0101 local -
Fa0/0 1 2 - Listen 0007.b400.0102 192.168.1.4 -


Now then, we have a resilience to failure. If we lose R3 then R4 should take over as the AVG and therefore ownership of the AVG. The client (R1) should see no difference to it’s MAC table during the failure process. So lets do that now, we’ll knock out R3 by shutting down the Fa0/0 interface.

This is the console debug on R4 after we shutdown R3.

*Mar 1 14:00:32.504: %GLBP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
*Mar 1 14:00:32.504: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 1 state Listen -> Active


R4 is now the active (AVG) for GLBP group 1. Notice that the Active router is now ‘local’ and this comand is being run in R4 not R3. There is now also no standby router.

R4#show glbp
Interface Grp Fwd Pri State Address Active router Standby router
Fa0/0 1 - 100 Active 192.168.1.1 local unknown
Fa0/0 1 1 - Active 0007.b400.0101 local -
Fa0/0 1 2 - Active 0007.b400.0102 local -


Lets run a ping again from R1 to the remote host and look at the MAC addresses.

R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 19 0007.b400.0101 ARPA FastEthernet0/0


Looks the sae right? Thats because the AVG manages the AVF. the AVG knows what it’s doing here. BUT one of the great things whch happens next is aging. When the client’s arp cache is lost it has to re-learn the MAC address for the gateway (192.168.1.1) so it ARP’s out again and guess what? Well this time the AVG fires off the new vMAC associated with R4.

R1#clear arp
R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:!!!!!
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0


So now 192.168.1.1 is associated with R4’s vMAC - remember the last two digits are 02 indicating the second member in the group?

OK lets bring R3 back into service and then we’ll bring R5 into the GLBP group so we have three member in the group ad then we will be ready start tweaking, tuning and generally messing about with the cluster members to show how it all fits together.

Ok so here are some of the things we can mess with:

Priority - this determines who is going to be in charge of the cluster group. The one who manages the AVF’s and dishes out the vMACs. The highest priority is preferred.
Preempt - if we have this set then then the node will become the active AVG if the priority is higher than all o the other nodes in the group.
Weight - changing the weight of a node affects how much ‘load/traffic’ it is given by the AVG.
Load balancing - we can change the way the group operates to include things like source MAC, round-robin and weight.

Of the following the most useful in terms of GLBP and it’s benefit above other FHRP’s with HSRP and VRRP are the weight and load balancing. Changing the way traffic is passed through the cluster can be of great benefit if you are trying to better utilise over/under utilised links. Source MAC load balancing is a pretty neat way of ensuring traffic *always* goes the way you need it to (a bit like affinity or ‘stickiness’ for session based traffic). The source will be sent a MAC address for the AVF at that time and it will always be given that MAC. The others will change the MAC advertised to the source.

Here is the output from R3 for ‘show glbp’. Notice we have the shared virtual IP of 192.168.1.1. The main points here are in bold - you can see we have 3 group members and we list their REAL physical MAC addresses. You can see there are three AVF’s or active virtual forwarders. The active AVF is R3 and all of the other AVF’s listen to R3...he rules. We’ve setup R3 to have a priority of 120, R4 to be 100 and R3 to be 80. The AVG goes to the one with the highest priority (remember the preempt rules).

We’ve also set R3 to have a AVF weight of 75, R4 to have 50 and R5 to have 25. The AVF weight is used when we are distributing load using the ‘weighted’ load balancing algorithm. We can set limits or ‘thresholds’ for weighting and if we set a lower threshold and decrement below that lower threshold we can in effect STOP the AVF forwarding traffic.

R3#sh glbp
FastEthernet0/0 - Group 1
State is Active
6 state changes, last state change 00:19:41
Virtual IP address is 192.168.1.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.324 secs
Redirect time 600 sec, forwarder time-out 14400 sec
Preemption enabled, min delay 0 sec
Active is local
Standby is 192.168.1.4, priority 100 (expires in 7.940 sec)
Priority 120 (configured)
Weighting 75 (configured 75), thresholds: lower 1, upper 75
Track object 1 state Up decrement 51
Load balancing: round-robin
Group members:
cc02.05a1.0000 (192.168.1.3) local
cc03.05a1.0000 (192.168.1.4)
cc04.05a3.0000 (192.168.1.5)

There are 3 forwarders (1 active)
Forwarder 1
State is Active
3 state changes, last state change 00:28:41
MAC address is 0007.b400.0101 (default)
Owner ID is cc02.05a1.0000
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local,
weighting 75
Arp replies sent: 3
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is cc03.05a1.0000
Redirection enabled, 599.596 sec remaining (maximum 600 sec)
Time to live: 14399.596 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.4 (primary),
weighting 50 (expires in 9.596 sec)
Forwarder 3
State is Listen
MAC address is 0007.b400.0103 (learnt)
Owner ID is cc04.05a3.0000
Redirection enabled, 598.580 sec remaining (maximum 600 sec)
Time to live: 14398.580 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.5 (primary),
weighting 25 (expires in 8.580 sec)

We’ll demonstrate the ‘load balancing’ part of GLBP now - this is what we are after isn’t it. So lets have a look at the interface - the default load balancing is to use ‘round robin’. For round robin in our example we’re going to talk to R3 then R4, then R5, then R3 then R4 then R5 in that order based on weight.

Remember the default for GLBP is round robin so there is no configuration change at this time.

Load balancing: round-robin

OK lets ping R6 first from R1

R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 24/35/40 ms
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.4 0 cc03.05a1.0000 ARPA FastEthernet0/0


Notice the MAC address given to R1 for the VIP of 192.168.1.1 ends in ’0101’ - GLBP group 1, first node.

OK lets clear the ARP table so we have to re-learn the MAC address for R6. The AVG should now allocate the vMAC for R5 which ended in 0102

R1#clear arp
R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/30/40 ms
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.4 0 cc03.05a1.0000 ARPA FastEthernet0/0


OK lets clear the ARP table so we have to re-learn the MAC address for R6. The AVG should now allocate the vMAC for R6 which ended in 0103

R1#clear arp
R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/32/40 ms
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0
Internet 192.168.1.4 0 cc03.05a1.0000 ARPA FastEthernet0/0


Right, thats the default of round robin. We’ve also got weighted and MAC based. Lets setup MAC based load balancing and ping from R1 and R2 to R6. We should see R1 get a vMAC and R2 get a different vMAC (hopefully) and after that no matter how many times we clear the ARP table on either R1 or R2 they should get the same vMAC.

First we configure the load balancing based on source MAC (you would do this on all members but this is the AVG right now)

R3(config-if)#glbp 1 load-balancing host-dependent

Right lets ping from R1 and look at the learned vMAC

Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0

Lets clear the ARP table and ping again

Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0

It never changes...sticky.

Right weighted load balancing. Lets setup out topology so that R3 is the best weighting with 100, R4 with get 50 and R5 will get 10 .So, when we ping R6 form R1 we would expect that 5 out of 10 times R5 would be the source vMAC for 192.168.1.1 and R6 would be it 1 in 10 times.

Lets setup the weighting method and weights (change the 100 for 50 and 10 respectively for each router)

R3(config-if)#glbp 1 load-balancing weighted
R3(config-if)#glbp 1 weighting 100


Here is the output from show glbp showing the weights are applied

Forwarder 1
State is Active
7 state changes, last state change 00:13:42
MAC address is 0007.b400.0101 (default)
Owner ID is cc02.05a1.0000
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local,
weighting 100
Arp replies sent: 6
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is cc03.05a1.0000
Redirection enabled, 599.564 sec remaining (maximum 600 sec)
Time to live: 14399.560 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.4 (primary),
weighting 50 (expires in 9.560 sec)
Arp replies sent: 2
Forwarder 3
State is Listen
MAC address is 0007.b400.0103 (learnt)
Owner ID is cc04.05a3.0000
Redirection enabled, 598.536 sec remaining (maximum 600 sec)
Time to live: 14398.532 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.5 (primary),
weighting 10 (expires in 8.528 sec)
Arp replies sent: 21


Right, lets ping R6 from R1...this is 100 pings and clears so I’m not going to show them all...believe me when I tell you it works out ;-) Here are the best bits from 10 pings.

Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0


So for 10 pings we got 6 using R1, 3 using R2 and 1 using R3... I’m not doing this for 100 pings guys ;-) It’s close enough for me to expect it’ll work out by the end. The point here is we would do this sort of weighted approach for different line capacities or if we have poor circuits we don’t want to use as much. As an example maybe we’d weight a 100Mbps and 1Gbps uplink in a 1:10 ratio respectively since the bandwidth ratio is the same.

OK, lets move on a little now. we’ve seen how we failover from R3 to R4 when we shutdown the local GLBP interface but what if we lose connectivity between R3 and R6? There is no point in traffic coming to R3 if there is no way for R3 to send that traffic on to the destination. We’ll setup a basic interface track to manage that. If the interface goes down we’ll decrement by 99 which will take the priority down to 0 which means that is should stop forwarding traffic

Lets setup the object tracking, then we’ll assign a weight decrement value for the AVF, then we’ll shutdown interface F1/0 and watch the results.

Object tracking - we’ve seen this before and it’s in other articles on here so no big depth. We’re going to watch for line protocol changes on interface F1/0.

R3(config)#track 1 interface fa1/0 line-protocol

Right now we’ll assign a weight value to the interface for the GLBP group 1. We’re dropping 51 if we lose the interface F1/0

R3(config-if)#glbp 1 weighting track 1 decrement 99

Right now we’ll setup the weighting in the interface so that if the value falls below 1 (remember this is just a test, you can use multiple trackings to manage the weight value e.g. drop by 20 if this route is out of the table etc) that the AVF stop forwarding traffic.

R3(config-if)#glbp 1 weighting 100 lower 1

This is the output from R3 after we shutdown Fa1/0. Notice the tracked object state change and weight from 100 to 0 (100-100=0)

*Mar 1 14:53:10.728: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Standby -> Init
*Mar 1 14:53:10.732: %TRACKING-5-STATE: 1 interface Fa1/0 line-protocol Up->Down
*Mar 1 14:53:10.732: GLBP: Fa0/0 1 Track 1 object changed, state Up -> Down
*Mar 1 14:53:10.732: GLBP: Fa0/0 1 Weighting 100 -> 0
*Mar 1 14:53:12.728: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down
*Mar 1 14:53:13.728: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down


Then we get a GLBP response from the active router R5

*Mar 1 16:16:09.055: GLBP: Fa0/0 1.1 Active: i/Hello rcvd from higher pri Active router (135/192.168.1.5)
*Mar 1 16:16:09.055: GLBP: Fa0/0 1.1 Active -> Listen
*Mar 1 16:16:09.059: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 1 state Active -> Listen
*Mar 1 16:16:09.059: GLBP: Fa0/0 API MAC address update
*Mar 1 16:16:09.063: GLBP: Fa0/0 1.1 Ignoring Hello (135/192.168.1.4 < 135/192.168.1.5)


OK lets try that weighted ping again. This time we should *never* use R3 since it’s weighting is now below the threshold and should not be forwarding traffic.

Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0

Right, well that took way longer than I expected to put down here but I really hope it helped anyone out

Good luck with your studies

View Comments
One of the more common authentication requests is around gaining access to something. That may be access to the VTY ports on the router, VPN access between sites or just using a lock and key dynamic ACL.

One of the more common WAN protocols is PPP. Whether it's your home router or some bigger WAN links at the office or in some sort of RAS dial-in service for an ISP we're going to do PPP. Knowing this fact it’s easy to see how common authentication using PPP is, indeed one of the huge benefits of PPP is the fact it allows for authentication...sounds like a match made in heaven. Certainly for certification PPP is a seriously major subject when you consider the features...that may be a hint.

PPP is used in exams to show authentication challenges for AAA in terms of PAP/CHAP etc. IT's used to multilink, circuit backup and that old faithful QoS topic of Multilink PPP with fragmentation and interleave. We see PPP a LOT in certification.
Lets start by looking at PPP authentication

The way we deploy the authentication depends on our requirements (or the question you get). If we are asked to support authentication using a plain text (unencrypted) message then PAP is the one for us. If on the other hand we are asked that the password is not sent unencrypted then we're talking about CHAP or EAP.

So what are the PPP authentication mechanisms we are dealing with?

- PAP
- CHAP
- EAP

In terms of security PAP is weakest followed by CHAP and then EAP. If you are asked to use the 'most secure' and EAP is an option, then you go for that one.

PAP (Password Authentication Protocol) send the password unencrypted over the network and is therefore considered insecure. In the real world we would use PAP only as a last resort or when the remote device doesn't support any other mechanism.

CHAP (Challenge-Handshake Authentication Protocol) unlike PAP is a more secure protocol as it uses a three-way handshake and the password is never sent across the link. Instead an MD5 hash checksum is calculated based on the password and then sent to the authenticator.
EAP (Extensible Authentication Protocol) is an authentication framework and there are numerous EAP 'methods' available such as EAP-FAST and EAP-TLS etc.

Right, lets talk about PPP authentication. When we talk about authentication what are we asking for? We're asking for some sort of 'token' or 'all access pass' to basically allow that remote device (which may be a laptop for a roaming user out on the Internet) full access to us. Would you like someone to have full access to you without authentication? You ask your doctor to prove themselves before they poke about right?

So how do we authenticate these remote access requests? Well we've got two options. The first one is basically saying "You prove to me who you are, I don't trust you until you prove you know me", this is one way authentication. The other one is a mutual respect thing where both sides of the link need to agree they know each other, this is two way authentication.

Here is the topology today - nothing mental I’m sure you’ll agree.

Screen shot 2011-06-15 at 22.56.18

PAP type authentication


Right into the scenario. PPP authentication is a bit of a brain issue because you need to get into your head who is wishing to be authenticated and who is the authenticator. Here is how I think about it. When you dialin to your office using a VPN *you* have a username and password and the VPN device is just basically making sure the details it has in its authentication database match before it lets you in...right?

OK, here we go. R2 is going to be *you* authenticating to the 'VPN' device which is R1. Now remember, we're not saying R1 is actually a VPN service it was just an analogy.

So R2 is *you*, the guy on the road, we need to tell R2 a username and password (you would usually have this in your head). R1 is the termination device so here we are going to bang into the 'authentication database' the remote users allowed to connect.

Here is the configuration on each device. First R2:

Screen shot 2011-06-15 at 22.20.06


Now for R2. Now this router is the authenticator end or the NAS - the device we are trying to authenticate toward. Notice the ‘callin’ keyword at the end of the authentication line? What we are doing here is disabling two way (bi-directional) authentication and going for uni-directional only. After all, we are a road warrior, we don’t need to authenticate R1 we want R1 to authenticate us....we are CALLING IN.

Screen shot 2011-06-15 at 22.20.37

Notice that this configuration has the authentication ‘credentials’ in it using ppp pap sent-username? This is like you banging your username and password into normal authentication processes like your windows machine at the office.

OK, thats all in lets bring up the interfaces and watch the debug on R1 to see the PPP connection establish itself. Here is a debug output...it’s not working...lets try to sort the issue out.

ppp authorization required

Authorzation required? Well apart from being spelt wrong (I am English and I’m sure authorisation doesn’t have a ‘z’ in it ;-) ) the problem here is that we (R2 are sending our credentials but as of this point R1 doesn’t have a ‘database’ of usernames and passwords to lookup.

Screen shot 2011-06-15 at 22.39.39

Thats it? Thats it! We enable pap authentication on the 'called' interface with the ppp authentication pap statement. We provide the username and password information to authenticate the request on the same box. On the calling router we simply add in the ppp pap username and password and hey presto!

CHAP authentication type

If you thought PAP was easy, you'd be right. CHAP is just as easy to grasp but the key difference here is the way CHAP authenticates for uni and bi-directional challenges using a 'three-way handshake'.

During the handshake the 'called' box sends an authentication enquiry to the calling box asking for confirmation of it's username and password - this is the 'challenge'. The calling station then uses an MD5 hash to send it's the HASH of the username/password (REMEMBER: it is NOT the actual username and password). The called box then checks the response hash against what it thinks should be the right response and permits/denies based on that.
Lets take a look at a simple example along the lines we just did for PAP. Notice this time that the username and password challenge are set in global configuration mode not under the interface. Each router has a username and password for the opposite router but the password is the same. Both the username and password as CaSe SeNsItIve...be careful.

So what is going on here with our current setup? Well this way we're doing bidirectional or 'two-way' authentication. Each side has been told to use chap authentication. So we'll have the calling station or 'Client' being authenticated by the called (NAS) station. The NAS will send a chap challenge to R1 asking it to confirm the username and password in the MD5 message response. The calling station (R1) will then itself send a challenge to R2 for the same purpose.

Lets do the config, do a debug, and enjoy the moment....ah

Firstly here is the configuration for R1 including the username setup
Screen shot 2011-06-15 at 22.50.01
Screen shot 2011-06-15 at 22.47.57

Here is R2 - looks very similar doesn’t it.

Screen shot 2011-06-15 at 22.49.12
Screen shot 2011-06-15 at 22.50.43

As soon as we enable the interfaces (no shutdown) the CHAP conversation begins - here is the debug output using ‘debug ppp authentication’ and ‘debug ppp negotiation’

*Mar 1 00:40:03.835: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 1 00:40:03.839: Se0/0 PPP: Using default call direction
*Mar 1 00:40:03.839: Se0/0 PPP: Treating connection as a dedicated line
*Mar 1 00:40:03.839: Se0/0 PPP: Session handle[F300006A] Session id[119]
*Mar 1 00:40:03.839: Se0/0 PPP: Phase is ESTABLISHING, Active Open
*Mar 1 00:40:03.839: Se0/0 PPP: Authorization required
*Mar 1 00:40:03.839: Se0/0 LCP: O CONFREQ [Closed] id 189 len 15
*Mar 1 00:40:03.839: Se0/0 LCP: AuthProto CHAP (0x0305C22305)
*Mar 1 00:40:03.839: Se0/0 LCP: MagicNumber 0x0030B4D6 (0x05060030B4D6)
*Mar 1 00:40:03.851: Se0/0 LCP: I CONFREQ [REQsent] id 67 len 10
*Mar 1 00:40:03.851: Se0/0 LCP: MagicNumber 0x0030B1AA (0x05060030B1AA)
*Mar 1 00:40:03.851: Se0/0 LCP: O CONFACK [REQsent] id 67 len 10
*Mar 1 00:40:03.855: Se0/0 LCP: MagicNumber 0x0030B1AA (0x05060030B1AA)
*Mar 1 00:40:03.855: Se0/0 LCP: I CONFACK [ACKsent] id 189 len 15
*Mar 1 00:40:03.855: Se0/0 LCP: AuthProto CHAP (0x0305C22305)
*Mar 1 00:40:03.855: Se0/0 LCP: MagicNumber 0x0030B4D6 (0x05060030B4D6)
*Mar 1 00:40:03.855: Se0/0 LCP: State is Open
*Mar 1 00:40:03.855: Se0/0 PPP: Phase is AUTHENTICATING, by this end
*Mar 1 00:40:03.855: Se0/0 CHAP: O CHALLENGE id 20 len 23 from "R1"
*Mar 1 00:40:03.871: Se0/0 CHAP: I RESPONSE id 20 len 23 from "R2"
*Mar 1 00:40:03.871: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar 1 00:40:03.875: Se0/0 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar 1 00:40:03.875: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:40:03.879: Se0/0 PPP: Received LOGIN Response PASS
*Mar 1 00:40:03.879: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar 1 00:40:03.879: Se0/0 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar 1 00:40:03.879: Se0/0 PPP: Sent LCP AUTHOR Request
*Mar 1 00:40:03.879: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:40:03.879: Se0/0 LCP: Received AAA AUTHOR Response PASS
*Mar 1 00:40:03.879: Se0/0 IPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:40:03.879: Se0/0 CHAP: O SUCCESS id 20 len 4
*Mar 1 00:40:03.879: Se0/0 PPP: Phase is UP
*Mar 1 00:40:03.879: Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 1 00:40:03.883: Se0/0 IPCP: Address 150.1.12.1 (0x030696010C01)
*Mar 1 00:40:03.883: Se0/0 PPP: Sent CDPCP AUTHOR Request
*Mar 1 00:40:03.883: Se0/0 PPP: Process pending ncp packets
*Mar 1 00:40:03.883: Se0/0 CDPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:40:03.883: Se0/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Mar 1 00:40:03.891: Se0/0 do IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 1 00:40:03.891: Se0/0 IPCP: Address 150.1.12.2 (0x030696010C02)
*Mar 1 00:40:03.891: Se0/0 AAA/AUTHOR/IPCP: Start. Her address 150.1.12.2, we want 0.0.0.0
*Mar 1 00:40:03.895: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:40:03.895: Se0/0 CDPCP: I CONFREQ [REQsent] id 1 len 4
*Mar 1 00:40:03.895: Se0/0 CDPCP: O CONFACK [REQsent] id 1 len 4
*Mar 1 00:40:03.895: Se0/0 AAA/AUTHOR/IPCP: Reject 150.1.12.2, using 0.0.0.0
*Mar 1 00:40:03.895: Se0/0 AAA/AUTHOR/IPCP: Done. Her address 150.1.12.2, we want 0.0.0.0
*Mar 1 00:40:03.895: Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar 1 00:40:03.895: Se0/0 IPCP: Address 150.1.12.2 (0x030696010C02)
*Mar 1 00:40:03.899: Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar 1 00:40:03.903: Se0/0 IPCP: Address 150.1.12.1 (0x030696010C01)
*Mar 1 00:40:03.903: Se0/0 IPCP: State is Open
*Mar 1 00:40:03.903: Se0/0 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar 1 00:40:03.903: Se0/0 CDPCP: State is Open
*Mar 1 00:40:03.907: Se0/0 IPCP: Install route to 150.1.12.2
*Mar 1 00:40:04.879: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

The default CHAP direction is bi-directional or two-way. What if we only wanted to authenticate one way? No problem. On the calling router (R1) we change the authentication command slightly to include the 'callin' keyword. This time when R2 receives the inbound it challenges R1 but R2 doesn't challenge R2 in response.

ppp authentication chap callin

What if we want to use a different hostname? No problem, like PAP we can set this under the interface using the 'ppp chap hostname' command. Lets change the hostname being offered to R1, we’ll run a debug and see it fail, then we’ll add the username into R1 and watch it setup again...

First the changed...oooh bad news

R2(config-if)# ppp chap hostname CHANGED

Here is the debug on R1...we’ve broken it for sure...

*Mar 1 00:53:50.763: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 1 00:53:50.767: Se0/0 PPP: Using default call direction
*Mar 1 00:53:50.767: Se0/0 PPP: Treating connection as a dedicated line
*Mar 1 00:53:50.767: Se0/0 PPP: Session handle[4600006C] Session id[122]
*Mar 1 00:53:50.771: Se0/0 PPP: Authorization required
*Mar 1 00:53:50.795: Se0/0 CHAP: O CHALLENGE id 23 len 23 from "R1"
*Mar 1 00:53:50.811: Se0/0 CHAP: I CHALLENGE id 16 len 28 from "CHANGED"
*Mar 1 00:53:50.815: Se0/0 CHAP: I RESPONSE id 23 len 28 from "CHANGED"
*Mar 1 00:53:50.819: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:53:50.819: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:53:52.819: Se0/0 PPP: Authorization required
*Mar 1 00:53:54.863: Se0/0 CHAP: O CHALLENGE id 24 len 23 from "R1"
*Mar 1 00:53:54.875: Se0/0 CHAP: I CHALLENGE id 17 len 28 from "CHANGED"
*Mar 1 00:53:54.879: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:53:56.883: Se0/0 PPP: Authorization required
*Mar 1 00:53:56.919: Se0/0 CHAP: O CHALLENGE id 25 len 23 from "R1"
*Mar 1 00:53:56.935: Se0/0 CHAP: I CHALLENGE id 18 len 28 from "CHANGED"
*Mar 1 00:53:56.939: Se0/0 CHAP: I RESPONSE id 25 len 28 from "CHANGED"
*Mar 1 00:53:56.943: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:53:56.947: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:53:58.963: Se0/0 PPP: Authorization required
*Mar 1 00:53:58.983: Se0/0 CHAP: O CHALLENGE id 26 len 23 from "R1"
*Mar 1 00:53:59.003: Se0/0 CHAP: I CHALLENGE id 19 len 28 from "CHANGED"
*Mar 1 00:53:59.007: Se0/0 CHAP: I RESPONSE id 26 len 28 from "CHANGED"
*Mar 1 00:53:59.007: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:53:59.007: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:54:01.011: Se0/0 PPP: Authorization required

Right lets fix it now by putting the username CHANGED and password into R1.

R1(config)#username CHANGED password cisco

This debug is still running on R1...

*Mar 1 00:55:27.039: Se0/0 CHAP: O CHALLENGE id 58 len 23 from "R1"
*Mar 1 00:55:27.059: Se0/0 CHAP: I CHALLENGE id 51 len 28 from "CHANGED"
*Mar 1 00:55:27.063: Se0/0 CHAP: I RESPONSE id 58 len 28 from "CHANGED"
*Mar 1 00:55:27.063: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:55:27.063: Se0/0 CHAP: Using hostname from unknown source
*Mar 1 00:55:27.063: Se0/0 CHAP: Using password from AAA
*Mar 1 00:55:27.063: Se0/0 CHAP: O RESPONSE id 51 len 23 from "R1"
*Mar 1 00:55:27.063: Se0/0 PPP: Received LOGIN Response PASS
*Mar 1 00:55:27.067: Se0/0 PPP: Sent LCP AUTHOR Request
*Mar 1 00:55:27.067: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:55:27.067: Se0/0 LCP: Received AAA AUTHOR Response PASS
*Mar 1 00:55:27.067: Se0/0 IPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:55:27.067: Se0/0 CHAP: O SUCCESS id 58 len 4
*Mar 1 00:55:27.079: Se0/0 CHAP: I SUCCESS id 51 len 4
*Mar 1 00:55:27.083: Se0/0 PPP: Sent CDPCP AUTHOR Request
*Mar 1 00:55:27.083: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:55:27.083: Se0/0 CDPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:55:28.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

All good now ... right lets rip it out and put EAP in now.

EAP authentication type

EAP is the most secure remote authentication method for PPP and is, as you would hope, relatively simple to implement. Like CHAP we also have to define the local username and password and reflect those credentials into the interface with identity (hostname) and password. The 'ppp eap local' statement informs the authentication process to lookup the username and password from the 'local' database - this is simply the username X password Y global configuration statement. The following configurations will enable the bi-directional setup in the same way as PAP and CHAP have shown. To enable one way either add the ‘callin’ keyword to the end of the ‘ppp authentication’ or else you can use the all powerful ‘ppp direction’ keyword to influence all of these protocols.

R1
username R2 password cisco
int s0/0
encapsulation ppp
ppp authentication eap
ppp eap identity R1
ppp eap password cisco
ppp eap local

R2
username R1 password cisco
int s0/0
encapsulation ppp
ppp authentication eap
ppp eap identity R2
ppp eap password cisco
ppp eap local

Thats the end of this tech article - thanks for reading and good luck in your studies.

View Comments
So lets just cover off one of the great things about distance vector routing protocols like RIP and EIGRP. To prevent loops in routing tables they use something called ‘split horizon’. The basic rule is this, “never pass on a route learned from one interface back through that same interface”. Scott Morris states this in this way “never tell a joke back to the person you just heard it from, it never has the same effect”. Split horizon works great for broadcast networks, but the behavior is not quite so useful in non-broadcast networks like frame relay, lets have a look at a few examples.

Broadcast network



Here is our broadcast network with three routers we’ll have say R1, R2 and R3 (see diagram below). Each router is connected to a switch using interface Fa0/0 sharing subnet 150.1.1.0/24. Each router is also configured with a loopback interface (Lo0) with an IP address significant to their hostname e.g. R1 is 1.1.1.1/24, R2 is 2.2.2.2/24 and R3 is 3.3.3.3/24.

Screen shot 2011-06-15 at 00.06.37


Now, each of the routers advertise their connected networks using RIP.

Here is the configuration for R1’s RIP process. You can see we’ve enabled version 2 and disabled auto-summary but it doesn’t matter for the purpose of this demonstration. TIP: the sh run | s rip’ command is us asking the IOS parser to look for the RIP section (s rip) in the configuration.

Screen shot 2011-06-15 at 00.06.07

R1, R2 and R3 each have a copy of the RIP database containing all of the routers. Crucially however none of the routers advertise learnt networks back out of their networks connected to the switch , they only send their directly connected networks. This is because, as the split horizon rule dictates, we are learning the other networks via a broadcast interface so it is un-necessary to send that same learned route back out. If we did that then we would be advertising routers to neighbors which we didn’t have connectivity to.

For example, what if we disabled split horizon on R2. It would advertise connectivity to R3 and R1’s loopback interfaces. Of course those RIP adverts would have a metric (hop count) of one more than the best route but what if the best route was lost? In this case the route advertised from R2 would be the new ‘best route’ and since R2 doesn’t actually have any connectivity to the R1 or R3 loopback interfaces the traffic would get to R2 and be dropped. All of this is possible because of the painfully slow convergence timers in distance vector protocols like RIP. Indeed the dead interval is 3 minutes and the flush timer 4 minutes! Now then, it’s not all bad news. RIP does also have another very clever way of telling all connected RIP hosts on the same broadcast network that something bad has happened and you must flush your RIP tabels immediately (usually because an interface has gone down). This type of ‘triggered update’ is called ‘Poison Reverse’. This ‘poisoning’ of a lost route basically advertises an immediate route update for the lost network with a metric (hop count) of 16 which means ‘inaccessible’ - job done.

Lets see the poison reverse in action here We’ll shut down the loopback0 interface on R1. Our debugs are running on R2. Watch as R1 sends out the update for the lost route to 1.1.1.0/24.

First;y here is a normal update from R1 - notice it learned it from 150.1.1.1 which is R1’s interface closest to R2.

Screen shot 2011-06-15 at 00.28.56

Now we’ve just shutdown the lo0 interface on R1. It immediately sends out an update telling us that route is dead (hop count 16).

Screen shot 2011-06-15 at 00.29.38

Now we (R2) send an update ourselves, basically passing on the bad news to all other RIPv2 (we send it to 224.0.0.9 which is the multicast address used by RIPv2)

Screen shot 2011-06-15 at 00.29.54

We also ‘hear’ the bad news from R3 who also, like us, passed it on...hey bad news does travel fast even in RIP.

Screen shot 2011-06-15 at 00.30.13

Right, this is all good fun, but what about split-horizon? Well, you know, the best place to see split horizon NOT working well for us is on a frame relay network...so lets do that instead.

Split Horizon on Frame Relay multipoint networks.


Here is the topology. In this example, R1 is the frame relay hub with R2 and R3 as spokes.

frame

The network has been configured using 150.1.123.0/24 between the two spokes and the hub. We’ve configured RIP on each of the routers and split horizon is enabled on each interface. Lets take a look at the routing table on R1.


Screen shot 2011-06-15 at 00.42.40

OK, this is perfect. We see learned routes for the loopback interfaces of both R2 and R3. Right so now we’ve enabled a routing protocol and we’re injecting the loopback interfaces into RIP then R2 should have routes to R1’s lo0 and R3’s lo0 and R3 should have routes to R1’s lo0 and R2’s lo0 right?

Well lets see. First on R2.

Screen shot 2011-06-15 at 00.46.17

Hmm - well I see R1’s lo0 network but I don’t see R3’s lo0.

What about R3?

Screen shot 2011-06-15 at 00.46.51

OK, so just like R2 I only see R1’s lo0 interface.

Well unless I fix this I won’t be able to ping all of the loopback interfaces. The answer to the problem is easy though. In our example R1 is the hub of a frame relay network. The RIP routes are being learned from R2 and R3 via one interface on R1 (S2/0.123). So, go back to what we know about split horizon. The fact that is that routes are being learned from R2 and R3 and then those routes are not sent back out of that same interface!

This behaviour is not ideal right, luckily however we can override split horizon. We need to disable split-horizon on that serial interface for the hub on R1. Lets do that now.

Screen shot 2011-06-15 at 00.50.10

Now lets take a look at the RIP database on R2 (show ip rip database)

Screen shot 2011-06-15 at 00.50.42

Cool, now I see the lo0 network from R3. Notice that it was learned from R1 though. R1 has passed it on? Of course we’re on a non-broadcast network and R3 and R2 and not directly connected with their own DLCI so R1 is the man in the middle here.

Lets take a look at R3’s routing table

Screen shot 2011-06-15 at 00.52.36

Nice one, we have a network for R2’s lo0 interface.

Thats it for this article on split horizon

Thanks for reading

View Comments
RIP is a classful routing protocol, it doesn’t do CIDR (Classless Inter-Domain Routing). So is a defaultroute a classless or classful entity? In this article we’ll get one RIP router to advertise the default route to another RIP neighbor using static routes, an IGP, redistribution and then the ‘default-information originate’ approach. Lets move on, here is the network topology. It’s a little overkill but we used this same design for a video which we’ll be posting up soon.

rip_topology_scale


We’ll begin by configuring a basic RIP setup on R1 and R5. The RIP default will be sourced from R1 and sent to R5.

Here is the basic configuration to enable the RIP process and enable it on the network segment between R1 and R5. Notice the new (ish) pipe command ’s’ this is short for section. We’ve put the loopback0 interfaces for R1 and R5 into RIP - notice the network masks both both of these? The loopback interfaces are 1.1.1.1/24 and 5.5.5.5/24 for R1 and R5 respectively and yet in the RIP process the network statements are 1.0.0.0 and 150.1.0.0. There is no netmask statement to support the 24 bits of network so how does RIP know what to advertise? Well in fact version 1 of RIP would not be able to help here but version 2 (which we have enabled) does support VLSM and can send the netmask of associated with the ‘network’ of the interface configuration along with the advertisement of the route...phew. RIP is CLASSFUL, it’s not something you want to run in a modern network necessarily. We’ve also disabled summarisation to stop RIP sending the classful route...it will do it automatically so we need to do this if we have shared networks advertised (for this example it is unnecessary)

Screen shot 2011-06-09 at 02.04.31

Screen shot 2011-06-09 at 01.57.34

Right, lets have a look at the routing table on R1 and then on R5

Screen shot 2011-06-09 at 02.05.35

Screen shot 2011-06-09 at 02.05.45

See how RIP, because of the CLASSFUL network issue has advertised the networks between R1 and R2, R1 and R4 and R5 and R4? On a production network you can see how it might get out of control sending more routes than you actually wanted to? To stop this happening we’d normally apply the ‘passive-interface’ command to stop the router sending router updates to it’s neighbors on that shared interface. If you wanted to stop the router receiving the routes you would use a distribute-list or access-list denying UDP port 520 inbound.

Right do we want a defaultroute sending from R1 to R5 (and other neighbors). First we need R1 to have a defaultroute in it’s routing table, without it RIP will not send a defaut route it HAS to already be in the routing table.

Firstly lets send the default using static routing. We’re going to put a static defaultroute into R1’s routing table and point it at the null0 interface - you wouldn’t want to do this unless you wished to blackhole traffic to networks which were not in your routing table. Remember packets trying to get to unknown networks are dropped...this may be desirable...up to you.

Screen shot 2011-06-09 at 02.14.19

Lets take a look at R1’s routing table

Screen shot 2011-06-09 at 02.14.29

Lets take a look at R5’s RIP routes in the routing table to show you that static routes don’t just jump into the RIP process - we have to redistribute between routing protocols don’t we ;-)


Screen shot 2011-06-09 at 02.15.26

Right so lets do that redistribute step now. We want to take that static route to null and pop it into RIP. Remember RIP routes are sent as full updates every 30 seconds so we’ll just wait...OK here is the ‘debug ip rip’ output.

Screen shot 2011-06-09 at 02.24.18

Great news - lets take a look at the routing table and see if the default route is in there now.

Screen shot 2011-06-09 at 02.25.04

Nice BA.

OK so I just thought of something we can do here. The redistribution line allows us to do things like add hop count (metric) into the updates...lets take a quick look at that. Remember the metric right now is 1 (we’re one hop away).

Screen shot 2011-06-09 at 02.26.37

Here is the debug on R5

Screen shot 2011-06-09 at 02.27.29

Excellent - you know what though...I told you RIP full updates are sent every 30 secs but this arrived a second after I told R1 that the redistribution should have a metric of 5. Well this is a great feature of later versions of RIP called ‘triggered updates’. This type of update is sent immediately when there is a change rather than waiting.

NOTE: there is a cisco proprietary version of triggered updates which can be used between peers across point-to-point interfaces. This type of update differs in that no updates are ever sent unless their has been a change at which point only the routes which have changed are sent. It reduces update traffic across what could be a slow circuit.

Right so the metric is reflected in the routing table? Yes indeed [120/5] shows administrative distance 120 (default) and a metric of 5.

Screen shot 2011-06-09 at 02.32.26

So that was redistribution but there is another way to get the default sent and thats using ‘default-information originate’. Using this method we get a little more control using route-maps and conditional advertising. Lets move on with this.

First we’ll tear down the static redistribution and check the route is gone from R5:

Screen shot 2011-06-09 at 02.34.28

Trust me - the route is gone from R5 - screenshot overload ;-)

Right lets configure the default originate - make a note - we still need the default route to be alive on the router, no default in table = no advertising default

Screen shot 2011-06-09 at 02.36.02

Here is the debug on R5...see the 0.0.0.0/0 coming in

Screen shot 2011-06-09 at 02.37.27

Lets do a show ip rip database on R1 to see it is redistributing the default route (default originate is still a redistribution)

Screen shot 2011-06-09 at 02.38.35

So we have the route in the table but before we close down here lets have a think back to what I was saying earlier about blackholing the traffic. Remember, if we don’t have a route with a shorter prefix than the default then we’re going to drop those packets right here. Now that may be what you want but it’s more likely that you’re advertising a default route because you want traffic to come to R1 because R1 is a gateway for your network e.g. a router before the internet. So lets think about it, if R1 is connected to the internet and we are advertising a default route to our internal routers so they send their packets to us...thats great. What if R1 loses connectivity to the internet though? All of that internal traffic is still going to be racing to R1 which is wasting bandwidth and ultimately unnecessary.

RIP default-information originate can help us out here with a technique called conditional advertising. To do this we use a route-map.

The route-map will ‘look’ for the existence of a route and if that route drops out then we’ll stop advertising the default...sound right to you? Well in our example we are going to say that the interface connected between R1 and R2 is the uplink to the internet. I’ve configured a basic OSPF neighbour relationship between R1 and R2 and R2 is sending it’s loopback0 network (2.2.2.1/32) to R1. Sp, if we see the OSPF router for 2.2.2.2/32 go away then we will suggest that our link to the internet has gone away and we will want to stop advertising the default route. OK lets get on with it then. Here is the OSPF route in R1’s routing table

Screen shot 2011-06-09 at 02.59.18

First we setup the route-map. We want to match the route for the OSPF route learned from R2 - 2.2.2.2/32. A standard access-list will match the IP address for the network. The route-map matches existence of that route.

Screen shot 2011-06-09 at 02.59.12

Lets add that route-map to the conditional default-route advertisement.

Screen shot 2011-06-09 at 03.01.53

Right - lets check...is the default route in R5’s routing table?

Screen shot 2011-06-09 at 03.03.01

Ok, lets shutdown the interface to R2. We see the OSPF go down, the route is gone.

Screen shot 2011-06-09 at 03.03.44

The route has gone from R5...job done

Screen shot 2011-06-09 at 03.04.07

Ok, that wraps it up for this tech article. We’re doing these all the time, be sure to keep checking back.

Thanks for reading

View Comments
Before we go into First Hop Redundancy Protocols (FHRPs) lets just for a moment consider the challenge. In any internetwork you’ll have domains (AS) and segments (IP networks). Each domain and segment will be connected to the others ‘hopefully’ with multiple paths of such extreme cunning and wit that the loss of one, two or even three paths is necessary to bring your internetwork topology to it’s knees. Internetworking is a good thing and we’ve got loads and loads of protocols to help us get it right in terms of redundancy. IGP’s like RIP, EIGRP, OSPF and IS-IS all do a great job of providing our routers with preferential paths and load balancing etc.

For the local segment however your hosts (pc's etc) will usually only have one predefined (static) way in and out, most often just the default gateway. So what happens when your LAN gateway goes down? Well frankly you and all the hosts in your network are trapped. Unlike your routed network (running with multiple point-to-point links) your LAN segment will be supporting hundreds if not thousands of devices, losing the gateway on a LAN segment is bad news if you are a user but the administrator's day is apocalyptic.

So what can we do about providing some resilience to our local LAN users?

One of the more forgotten FHRP options is IRDP or the ICMP Router Discovery Protocol. The RFC1256 describes how ICMP 'Hello' packets are sent out by the routers into the local networks. End hosts 'listen' to these ICMP packets to dynamically learn the gateway address and install it into their routing tables. Clients can poll out using multicast to find new routers to get out should their ICMP acquired host go away. It’s pretty neat to be honest but it very rare to see in the wild these days. Thats not to say you should forget it however, it’s on the Cisco CCIE blueprint for sure.

So more realistic options? Well what about maybe loading up a dynamic routing protocol on the workstation itself? Most common open protocols such as RIP and OSPF are widely supported in PC operating systems with Windows, Linux etc. If we fire up RIP on PC and get it to talk to the routers in our network then of course if one of those goes then we should be able to build up a new route. This feels pretty good right? Well maybe, but it's going to be tough setting this up on a large scale. Also, with my security hat on, I can't say I'm over the moon allowing my hosts to affect my routing tables...what if someone redistributed one of my core networks so it looked like we should send traffic to their workstation instead of the finance database network...bad! We’ve got options around filters and authentication to add some security but again, complexity...feels OK but maybe not...lets move on.

Lets get dirty again now (or desperate) and bring in dynamic host configuration protocols like BOOTP/DHCP. If we were smart maybe we’d bring down the lease period for this sort of thing. If we get a gateway failure we can reconfigure the scope handing out IP addresses, netmask and the local gateway device. Change the gateway IP address to another unit capable taking the traffic which was going to the now broken gateway, we’re golden. If waiting for a lease to expire is too long (most default to 3 days) then some members of the team could always ask all staff to reboot their machines or do a quick DHCP refresh. If this was an organisation with 1000's of customers off the air I'm pretty sure this would be your last choice..or last task in employment. Either way I hope you’re getting the point here. This sort of ‘fix’ is unworkable.

One of the better redundancy choices for the local LAN is actually one of the simplest and oldest. Let's digress a little here. Remember ARP? We use the Address Resolution Protocol in our local LAN to get the remote hosts MAC address when we only know the IP address. Now enter Proxy-ARP. Proxy ARP is enabled by default on Cisco routers and, as the name implies, proxies ARP requests for hosts beyond the physical local network made by the host. Imagine a network 10.0.0.0/8 and hosts within our network have the IP address 10.1.100.1 to 10.1.100.254. Our local segment router has the IP address 10.1.100.1. When the host 10.1.100.10 wishes to talk to host 10.1.1.10 then it simply ARPs out for it (it is on the same network after all as far as it is concerned). So the router10.1.100.1 takes the ARP request and 'pretends' to be the remote host by sending the host 10.1.100.10 it's own MAC address as the destination MAC for 10.1.1.10. Pretty neat. The issue with proxy arp though is that if router 10.1.100.1 goes down and we have another router (in the same broadcast domain) then we have to wait for the ARP table of the host to go stale before it will ARP out again for that remote host. The ARP table will refresh in a few minutes if we are trying to talk to it. This time period again, is probably too long to be considered a solution even though it will eventually work and it’s way faster than DHCP).  To speed it up we can of manually clear the ARP table on the host (again we’re using man power here which isn’t exactly reliable or efficient) or send a gratuitous ARP out on the local LAN for those remote addresses (unworkable really).

Right, we’ve been through the pain, here is the treatment.



Enter Cisco with HSRP. Defined in RFC 2281, HSRP allows two or more (up to three) devices in the same network segment to share an IP address and MAC address. One of the 'HSRP group' will be the active router and will be advertising ownership of the virtual addresses and receiving traffic. When that active router fails it can have other routers with connectivity to the same sources to take over the traffic. HSRP is automatic, it’s pain-free, it’s wonderful. Cisco have gone on to develop HSRP further to watch availability not only to the local interfaces but also remote connectivity such as lost routes int the table, high packet loss and much more. By making sure that the healthy gateway device has genuine reliable connectivity to its upstream we’re making intelligent decisions right at the source.

Now, as we’ve seen before, the Cisco proprietary protocol developed and engineered by Cisco is often picked up by the industry, reworked and brought out as a standard. In this case HSRP was reworked into VRRP. Network devices other than Cisco run VRRP to provide this same service. The two protocols are almost identical and indeed on a Cisco host which supports both HSRP and VRRP is exceptional in its ambiguity. Configuration of VRRP uses the ‘vrrp’ keyword whereas HSRP uses the ‘standby’ keyword. Apart from a few other tweaks there is little to differentiate the two. VRRP is HSRP for the masses. It works.

The final FHRP on our agenda today is GLBP. This protocol operates to provide a virtual IP address in the same way as HSRP and VRRP however where GLBP differs is in the way it works the plan. GLBP is, like HSRP, a collection of 2 or more devices which offer a redundancy to failure of each other. Unlike HSRP and VRRP however GLBP also offers load balancing between these members. HSPR and VRRP each work on the master/slave or active/backup approach where only one member of the group can be actively passing traffic at any one time. GLBP works differently by electing an AVG (Active Virtual Gateway) member which in turn decides from its pool members how to distribute the load. The other members int eh GLBP ‘cluster’ are called the AVF or Active Virtual Forwarders. In exactly the same way as HSRP and VRRP elect the ‘master’ of their respective membership the highest priority GLBP member becomes the AVG. If the AVG fails then that is passed to the next highest member and so on (if all members have the same priority then the one with the highest IP is elected).

This ends our brief look into the dark but essential world of the FHRP.

Thank you for reading.
View Comments
OSPF uses Link State Advertisement packets (LSA’s) to ‘inform’ local link connected neighbouring devices of OSPF messages. The messages include information like who is the DR (Designated router), routing information and area type.

Types


There are six main types you will see in the OSPF database which are essential for the routing and switching lab:




















Type-1




This LSA type is called the ‘Router LSA’ and basically is the IP address (OSPF router-id) or the OSPF speaker. It is local link only, is generated by all OSPF devices and could be any type of OSPF speaker like a Windows box, Zebra, Vyatta, Cisco or Juniper.




Type-2




This LSA type is called the ‘Network LSA’ and are only advertised by the DR or Designated router for that segment (local link).




Type-3




This LSA type is also called the ‘Summary LSA’ and is generated by ABR’s or Area Border Routers. These routers sit in between two or more areas e.g. Imagine a router with two interfaces fa0/0 and fa0/1. The administrator may have placed network interface fa0/0 into OSPF area 0 and fa0/1 into area 1. This router is now an ABR. The ABR can choose (it is not the default) to summarise routes which may have been learnt from routers in area 1 back into area 0.

These ‘summary’ routes are given the LSA designation of Type 3. This type of summary is for internal routes or in other words routes for networks in the OSPF database which have originated using the network keyword not redistributed.




Type-4




This type of LSA is the ‘ASBR Summary LSA’. When we have an OSPF aware router also connected to another autonomous system running on another routing process (e.g. EIGRP) and we redistribute routes from the EIGRP process into OSPF this router becomes an ASBR. The Type 4 LSA is special and is injected into a normal area from an ABR (this is NOT a typo!) as a reference or reference for the ASBR. The ABR generates the Type 4 to provide area’s beyond the ‘next-hop’ reachability information for the external route.




Type-5




This type of LSA is the ‘External Route LSA’. This type of LSA is generated by redistributing routes into OSPF. The redistribution can be from another routing protocol, a static route or a connected route and the route within the OSPF database gets a type 5. There are two flavours of Type 5 however. The E1 route can perform like a normal route within OSPF whereby it can gain metric as it goes around the network. By default however redistributes routes are given the type E2. The E2 external route is given the default metric of 20 and that metric never changes no matter how many hops it takes around a network.




Type-7




This type of LSA is the ’NSSA LSA’. This type of LSA is generated by the ABR for a Not-so-stubby-area. The Type 5 route is not permitted inside an NSSA so when inside an NSSA the ASBR converts the Type 5 (which would normally be generated for an external route in a normal area) into a Type 7.













Areas



OSPF has a number of area ‘types’. Each of the LSA’s we have seen so far are only allowed to exist in certain areas so lets have a look at who can go where.




















Standard Area




This is the default OSPF area type. For a single OSPF area network where you have one area for your entire site you should use area number 0. This is a type of ‘standard area’ designated as the ‘backbone area’ e.g. network x.x.x.x y.y.y.y area 0’ will put network interfaces in network ‘x.x.x.x’ with netmask ‘y.y.y.y’ into area 0.

Area 0 or the 'Backbone Area', like all OSPF areas uses a 32bit field. Normally the area ID is represented as a decimal number like 0 or 100 or 1020. It should be remembered however that the area ID is actually a 32 bit number. Other vendors, unlike Cisco, can represent the area ID in a standard IP address format like 0.0.0.0 which is the same as just 0. It doesn't matter how which you use but be aware that the software will convert an IP address formatted are back into a 32bit decimal number between 0 and 4.2 billion. For example 123.1.123.1 is not area 12311231.

LSA Allowed 1, 2, 3, 4, 5




Stub Area




This type of area has usually only one way in and out which makes it the ‘stub’ of the network. Inside a stub because you only have one exit you can ask why you would need to know about all the routes the rest of the network uses because really, you just need to know how to get out and thats usually done using just a default route. The stub ABR converts type 4 and 5 LSA’s into a default route summary and injects that into the Stub. Type 3 summaries of routes are allowed into and out of a stub area.

LSA Allowed 1, 2, 3 + Default




Not-So-Stubby Area (NSSA)




The NSSA is a stub network which also has connectivity to another autonomous system via another routing protocol e.g. a router with an OSPF and EIGRP process. Like the Stub, external routes are not allowed into the NSSA. External routes learnt by the ASBR (autonomous System Border Router) within the NSSA are converted from Type-7 to Type-5 at the ABR to move out of the NSSA. Unlike the Stub area however the NSSA will NOT inject a default route by default. To send in the default route you need to add the ‘default-information originate’ command at the end of the area statement.

LSA Allowed 1, 2, 3, 7




Totally NSSA




This are type was a Cisco only invention which has now been picked up by other vendors. the Totally NSSA area is configured exactly like the normal NSSA except we add the ‘no-summary’ keyword to the area statement. This essentially disallows the Type-3 LSA from entering the area and simply sends in a default route.

LSA Allowed 1, 2, 7, Default












View Comments
  • Using the OSPF default-information originate command in its raw form allows us to send a 0.0.0.0/0 route into the OSPF database for our neighbors to put into their
  • active routing tables. One problem with default routes however is they can soon become traffic black holes.

Imagine a router connected to the internet (R1). To ‘help out’ all the other internal routers it advertises a default route in saying “Hey you guys, I know how to get to the internet so don’t worry about all the routes I know about, here is one route to rule them all, send all your traffic to me” The command that router might use would look like this:

Screen shot 2011-06-01 at 00.13.32

The statement ‘default-information originate’ is truncated with the ‘always’ keyword to signify that OSPF should ‘always’ advertise the default route no matter whether the router has an active default route in it;s routing table.

Lets have a look at the active routing table for the neighbor connected to R1 for the new default route advertisement:

Screen shot 2011-06-01 at 00.15.20

We see the default route has an OSPF type of E2 as it is a ‘redistributed’ route brought into OSPF from an external process.

Screen shot 2011-06-01 at 00.15.53

So thats great, but what if we wanted the default route to be conditionally advertised based on the advertising router already having a default route in it’s active routing table? Well thats easy enough we can remove the ‘always’ keyword. Lets go back to R1 and take that out:

Screen shot 2011-06-01 at 00.18.16

Now lets put the originate statement back in - notice no ‘always’

Screen shot 2011-06-01 at 00.18.28

Now on the neighbor we have no route to 0.0.0.0

Screen shot 2011-06-01 at 00.19.20

As we explained before, this is because R1 (the originator) didn’t have a default route in it’s routing table...as shown here:

Screen shot 2011-06-01 at 00.20.16

Right. so without the ‘always’ keyword we need a default route to be present therefore making the presence of the default route a condition of the further advertisement of that route. Lets pop in a static route on R1 to meet this condition and hopefully then advertise the route to R2:

First R1, the first command adds a static route to 0.0.0.0 via interface null0 (effectively blackholing data destined for any route not known by R1. the second statement is simple showing the routing table entry.

Screen shot 2011-06-01 at 00.21.54

Now R2, we see the route is now in the table due to R1 meeting the pre-condition of having a default route in it’s active routing table.

So thats great of course. But what if our internet router has a full internet routing table BUT crucially has no default route? Well we could add a static route as we’ve seen but if those internet routes go down (neighbor failure etc) then the static default will never fail and traffic will keep routing toward R1. Wouldn’t it be better if we matched for a BGP route int he table and based on the presence or ‘non-presence’ of that route stop advertising the default route.

To do this we need a route-map. A route map can be configured in this case to match either an access-list or a prefix list for the route in the table. Lets advertise based on access list entry first of all. We’re going to look for an active route for network 160.1.3.0/24. If it exists then we advertise the route, if not don’t advertise it.

First lets make sure the route is in our routing table on R1:

Screen shot 2011-06-01 at 00.26.44

Great now lets setup the default-originate statement and route map to match the existence of this route.

Screen shot 2011-06-01 at 00.27.51

We need to create the route-map called BGPEXIST now to match the route entry.

Screen shot 2011-06-01 at 00.29.14

Now we need to create the access-list ‘1’ as we have described it. Notice we use a wildcard mask to match exactly the first three octets so as to catch the /24 mask in the routing entry.

Screen shot 2011-06-01 at 00.29.56

Now lets check R2 to make sure we are getting the route:

Screen shot 2011-06-01 at 00.31.11

All good. Now lets prove out the conditional configuration works by taking out the network 160.1.3.0 from the R1 routing table - we’re going to do this by denying the route on the internet peer. Lets check that route is no longer in the R1 active routing table:

Screen shot 2011-06-01 at 00.32.28

OK so without the route we should no longer be advertising the default to R2 - lets check R2’s routing table:

Screen shot 2011-06-01 at 00.33.01

Perfect - conditional advertising works.

To cover the full story we’ll do the same thing using a prefix list now. We’ll chose a different network this time, 160.1.1.0 will be fine. Lets make sure this network is in the R1 routing table:

Screen shot 2011-06-01 at 00.37.12

So we only need to change the route-map since the default-information command still stands. First we access the route-map sub-command then we take out the access-list and add in the new prefix list line. NOTE that you cannot have both access-list and prefix-list matches at the same time.

Screen shot 2011-06-01 at 00.34.30

So now we need to setup the prefix list ‘1’ (the sequence number is personal preference and can be ignored)

Screen shot 2011-06-01 at 00.35.49

Now lets have a look at R2’s routing table to make sure that now we are matching a prefix list looking for the active route 160.1.1.0/24 we are now advertising the default route again...

Screen shot 2011-06-01 at 00.37.59

Excellent.

This topic is covered in more detail on our technical video at youtube

Thanks for reading.
View Comments
GRE (Generic Routing Encapsulation) is an industry standard for encapsulating data within an IP packet. Unlike IP protocol 7 (IPv4) GRE runs over IP protocol 47. It is often used to manipulate routing over non-broadcast networks or for sending multicast over IPSEC tunnels. This tech note was setup between a Juniper EX 4200 switch cluster and a Cisco 2621XM router. One of the issues with GRE traffic is its extra header which means payloads are reduced when you use it by an extra 4bytes (minimum).

So here is our basic topology. Remember we’re just using this to prove out the connectivity NOT to delve deeply into GRE itself or how we could use this to fix a ‘situation’. We’ll be bringing more of these technical guides as soon as we can write them using another 24 bit subnet 12.1.12.0. From here we’ll have two loopback interfaces (one on each device) and we’ll setup the routing to divert traffic between each of these loopback interfaces across the tunnel.

.Screen shot 2011-05-28 at 22.19.00

First lets configure the EX switch ge-0/0/0 interface which is connected directly to the Cisco 2600. Notice the bit-wise mask at the end. Cisco’s recent NEXUS platform running the NX-OS also now uses the bitwise pattern for netmask...interesting ;-)

Screen shot 2011-05-28 at 22.31.29

Lets configure the loopback interface

Screen shot 2011-05-28 at 22.31.37

Right now we’ll configure the GRE interface itself. It doesn’t matter in the order of the next three configuration lines but you DO need them all ;-)

The source is the beginning of the tunnel from ‘this routers’ point of view’. As an analogy think of you in your car. You are driving toward a tunnel going under a river from Coolville to Duddberg. As far as you are concerned the start (source) the tunnel is in Coolville. When you return however the start of the tunnel is in Duddsberg. Same thing for traffic going into and out of your tunnel here.

Screen shot 2011-05-28 at 22.31.44

Now the destination. Remeber this is all relative and the other side will look the opposite.

Screen shot 2011-05-28 at 22.32.04

OK, now thats the tunnel built we need to ‘load it up’ with loely IPv4 traffic. So, just like a normal interface we’ll give it an IP address and a mask.

Screen shot 2011-05-28 at 22.42.19

Right JunOS side done now, lets nip over to the Cisco box and do the same.

Lets configure the Fast Ethernet 0/0 interface which is connected to the Juniper switch.

Screen shot 2011-05-28 at 22.47.14

Now we’ll configure the tunnel interface. For brevity I’ve taken a pumped all of the configuration in here but it follows EXACTLY the same sort of configuration as JunOS. Source IP of tunnel, desitination IP, IP address of the tunnel...done.

Screen shot 2011-05-28 at 23.03.44

Right so now thats up lets see if we can ping either side of the tunnel.

Cisco side first...

Screen shot 2011-05-28 at 22.38.30

Cool, now the Juniper side

Screen shot 2011-05-28 at 22.49.52

Awesome. Right but we’re pinging the sides of a point to point interface here which isn’t exactly right is it. So if we’re going to be ‘routing’ traffic through this tunnel and not just having a secondary route (whats the point in our topology anyway) we’ll need to give each side routes to one another. We’re going to route traffic for each sides Loopback interface through the tunnel.

Juniper side first

Screen shot 2011-05-28 at 22.53.06

...don’t forget the commit in JunOS. You know it never fails to impress me how Juniper got JunOS so right for administrators. If we screwed this up and the router happened to be 1000 miles away we’ve got options. Auto rollback is the best thing ever.

Now the Cisco side

Screen shot 2011-05-28 at 22.53.41

...if we screwed up IOS we’d be gone ;-) Of course we could always issue that great ‘reload in 10’ shortcut to save our ass.

Ok lets ping out over the tunnel interface.

Screen shot 2011-05-28 at 23.04.19

Now form Cisco side...just because we can

Screen shot 2011-05-28 at 23.05.23

What about some statistics to back that up man?! OK, here we go.

Right Juniper side first again. We got 6 in and out here...

Screen shot 2011-05-28 at 23.07.03

Cisco side...

Screen shot 2011-05-28 at 23.05.59

Job Done.

Thanks for Reading
View Comments
BGP has a number of metric affecting values, one of the most often ignored is origin although it can have a serious effect on your routing table. Imagine getting two routes from two eBGP neighbors. ISPA is connected to CUSTOMER_Z using OSPF and redistributes those learned networks into BGP then advertises those to it's other upstream peers. ISP_B on the other hand is also connected to the same CUSTOMER_Z however ISPB decides to bring those OSPF networks into the BGP RIB using the 'network' statement. The upstream BGP peers will receive two routes into their RIB one with an origin of i (the one from the ISP_B) and one with origin ? (the one from ISP_A).

BGP uses a number of 'tiebreakers' to decision the best route to a destination and here are the first 5; Weight (Cisco proprietary), Local Preference, AS-PATH length, Origin, MED. So origin comes right after AS-PATH length and actually is the second highest decision maker for your outbound traffic...it really matters.

So in this tech guide we're going to build a small 3 mode network. The diagram below shows two BGP autonomous systems. 65001 contains R1 and R2 and they are connected with the network 12.1.1.0/24. R3 is in another AS with number 65002. The network between R2 and R3 is 13.1.1.0/24


Screen+shot+2011-05-19+at+13.59.24


Here is the output from R1 showing first the ip routing table and then a 'show run' for the interface connected to R2

Screen+shot+2011-05-19+at+14.03.20


Here is the same output for R2. Note that R2 is connected to R1 via Fa0/0 and R3 via Fa0/1

Screen+shot+2011-05-19+at+14.03.05


Finally the same output for R3

Screen+shot+2011-05-19+at+14.01.46


OK so we have IP comms between R1, R2 and R3. Now we're going to configure the BGP relationships.

First we'll add the neighbor statement on R1 for R2 (remember we already enabled the BGP process by issuing the 'router bgp 65001' global configuration command.

Screen+shot+2011-05-19+at+14.03.53


Now we do the same for the other side of this neighborship on R2 pointing to R1

Screen+shot+2011-05-19+at+14.04.21


Note that both have the same AS# because they are iBGP neighbors. We see now that the neighbor relationship is 'Established'

Screen+shot+2011-05-19+at+14.04.31


OK so now lets setup the eBGP relationship between R2 and R3. Firstly on R2

Screen+shot+2011-05-19+at+14.05.24


Now on R3

Screen+shot+2011-05-19+at+14.05.46


Note the difference in AS# between that configured in the 'router bgp' and the 'remote-as' this is an eBGP relationship. We get this console message on R2 - the neighborship is Established.

Screen+shot+2011-05-19+at+14.06.12

So lets create our first 'network' to advertise via BGP from R3. We'll just use a loopback interface, here it is loopback0.

Screen+shot+2011-05-19+at+14.07.07

We bring this into BGP using the 'network' statement. 

Screen+shot+2011-05-19+at+14.07.24

Now on R2 we can see that R3 has indeed sent us a route for 150.1.1.0/24. Notice the origin for the route is 'i' or internal. Thats because we brought the route into the BGP RIB (Routing Information Base) using the 'network' keyword.

Screen+shot+2011-05-19+at+14.07.40



So what happens if we bring the network in via a redistribution? We'll create another loopback interface on R3 called loopback1 and redistribute that connected interface into the BGP RIB.

Firstly the interface configuration

Screen+shot+2011-05-19+at+14.08.22

Now we add the necessary configuration to the bgp routing process. Firstly we need to be careful here. simply redistributing all connected interfaces will also bring our loopback 0 interface in...so lets use a route-map. We'll match the network for loopback 1 using an access-list

Here is the access list (we could use the 'host' keyword instead of 0.0.0.0)

Screen+shot+2011-05-19+at+14.10.11

Now the route-map. We're matching access-list 1 which is 200.1.1.0/24 which is the network we configured for interface loopback 1. Any other match is denied and dropped i.e. it won't be redistributed.



Screen+shot+2011-05-19+at+14.33.59

So lets have a look at the routing table on R2 to see if we now how two routes, the first from 150.1.1.0 and now a second for 200.1.1.0.

Screen+shot+2011-05-19+at+14.34.48

We do! Thats great. Now look at the origin. The first was an 'i' for internal which you remember was brought in using the 'network' keyword. Now the new network 200.1.1.0 has an origin of '?' which means incomplete. The reason for this is we don't know the source of the route so our knowledge of it's origin is...well incomplete. All we know is that someone brought it in from somewhere.

So there is one more origin type and that is 'e' or EGP. Now EGP is a legacy protocol and I've never come across it. To create the 'e' origin type therefore we'll have to 'fudge' it. We're going to use a route-map again to set this.

First lets create another loopback interface on R3 for this EGP candidate route.

Screen+shot+2011-05-19+at+14.37.34


OK, so now lets edit the existing route-map to add in our EGP configuration. What we'll do is again using an access-list match the interface lo2. If it matches then change the origin to e and set the source AS# for the EGP to 65003.

Screen+shot+2011-05-19+at+14.40.30

OK, now thats done we'll wait for a while till the BGP routes settle (or we can force it with a 'clear ip bgp *' at either side of the peering).

Screen+shot+2011-05-19+at+14.42.13


There we go...all three origin types. If these were duplicated routes learned from different sources with the same AS_PATH length we'd choose i first, then e then ?.

So what about R1? You're right we didn't even use this yet...lets take a look at it's routing table...

Screen+shot+2011-05-19+at+16.52.09

Nothing? Of course - is the next hop in my routing table? No of course not so the route goes into the BGP RIB but is inaccessible. So we need to set the 'next-hop-self' on R2 to change the next hop to R2's fa0/0 interface.

Screen+shot+2011-05-19+at+16.50.34


OK lets see the routing table now.

Screen+shot+2011-05-19+at+16.52.16

Looks good - of course R3 has no way of knowing how to get to 12.1.1.0/24 yet but you know how to do that now right? Of course you do...

Thanks for reading.

View Comments
Well, being as we all know lab time is precious we're all looking for CCIE shortcuts. Certainly in my labs (passed third time) I found the last hour was usually spent pinging everything to make sure I had that special full routing table. So, you've seen those practice labs right? You've probably gotten hold of a training package from one of the big Cisco training vendors like InternetworkExpert or IPExpert right? Well those full labs they throw at you are pretty extensive and contain a lot of IP addresses. If we were to assume that the real lab has just as many IP addresses then how could you possibly remember all of those. Not only that but could you really be up to the task of pinging each and everyone from each and every layer 3 device on the network to test for full reachability?

Well of course not, that would be nuts. So here is what I did for my lab (frankly I only had enough time to exploit this in my third attempt) and I hope it can help you out. Of course you could always use this on your production network as part of some alarm script or reachability script but I digress.

So, tclsh, what is it and how do we use it? Well it's a very powerful application in it's own right, read about it here. On IOS it runs under it's own binary and is called from privileged EXEC mode. The power of tclsh is not in the scope of this document and honestly I've not even scratched the surface myself. We're going to concentrate on running the application, writing a basic script, executing the script and using it to debug issues in your lab before the time runs out.

So first off how do we call tclsh? From privileged EXEC mode type 'tclsh' then press return

ccielabshortcutstclsh-screen-shot-2011-05-15-at-18.51.43

You see you get dropped into a sub-prompt or actually the TCLSH command shell. It is inside here that you can create your script. For our example here I've built up a small three node network. R1, R2 and R3 are connected together using subnets 10.1.12.0/24 (R1<->R2) and 10.1.23.0/24 (R2<->R3) and we are running EIGRP across all three. Each has a local loopback0 interface. Lo0 on R1 is 1.1.1.1, Lo0 on R2 is 2.2.2.2 and Lo0 on R3 is 3.3.3.3.

Here is a diagram so we can see the topology:

ccielabshortcutstclsh-screen-shot-2011-05-15-at-18.56.02

eigrp process ID 100 is running on each router. Here is the routing table on R1:

ccielabshortcutstclsh-screen-shot-2011-05-15-at-18.58.02

Ok, so in the lab you're going to be busy, too busy to remember IP addresses and *way* to busy to type these all in. Here is a tip. As you go through the lab have notepad open and type in the IP addresses for all of your nodes. I'd use notepad a lot if I were you. There was a study done (can't recall the publisher sorry) which stated that more than 60% of exam (not just CCIE) error was down to mistyping or human errors (the technical term for this of course is "fat fingers"). So why would you set yourself up for this sort of thing - put it in notepad and minimise your risk.

Here is Fred who could press QWASEDZXC with one finger easily.

ccielabshortcutstclsh-fredfatfinger

So anyway you've got a list of IP addresses - this is perfect. At the end of your lab you're going to be ahead of the game when it comes to troubleshooting with tclsh!

The basic setup here for our tclsh script is we are going to run an iterated 'for' loop. For any programmers out there you'll be aware of 'for' loops. The idea behind a loop is to reduce the number of lines of code for repetitious process. e.g. "check A looks like B" or "doesn't look like B", or maybe "is smaller than B", or "bigger than B" etc. the point is that whatever the differentiator is between A and B do it, and do it again until the end...whatever the end is. In our ping script we're not doing any comparison we're just being iterative through a list of address. Hmm this is getting hard to put down in words I guess so here is our example:

We've got a number of IP addresses in our topology and these are in our notepad list:

1.1.1.1
2.2.2.2
3.3.3.3
10.1.12.1
10.1.12.2
10.1.23.2
10.1.23.3

Cool. Right now the syntax for our for loop starts with a 'foreach VARIABLE_NAME'. Now the 'VARIABLE_NAME' can be anything but it's usual to pick something small like a letter e.g. a or b, most guides I've seen us 'i', but it could easily be 'ipaddress' or even 'ccie'...you choose. The VARIABLE_NAME is just something you are associating with your IP addresses i.e. the first IP address in your list, for the first run through the loop will associate with the letter 'a' or in other words a=1.1.1.1.

The tclsh script ends by telling IOS what command it is supposed to run against the variable in the script. Our script is written to 'ping' so clearly we'll need to have ping in there somewhere ;-)

Here is the command based on us choosing a VARIABLE_NAME of 'a'. If you chose something else here then you should substitute it.

"ping $a repeat 1"

Lets walk through this. The tclsh parser will send the string "ping $a repeat 1" into the privileged EXEC mode just as if you were typing it. Now remember $a takes on the IP address for each iteration through the loop so first round $a=1.1.1.1 so now the line makes more sense "ping 1.1.1.1 repeat 1". We are saying repeat 1 because we don't need IOS to do the usual 5 pings...we're running low on time right?! So we rung one ping and we look for a "!" which means all good. Now some people tell me "Hey, sometimes the first ping is lost because the router needs to lookup the MAC address and it times out". Well I say use whatever works best for you. In the lab it's likely your routers will already have the MAC addresses they needs due to routing protocols and other troubleshooting you already did so one ping should be enough.

Right, we've been through the logic behind the script. Here is is being used.

ccielabshortcutstclsh-screen-shot-2011-05-15-at-19.20.45

Thats it - all pinged - I guess I passed ;-)

The tclsh application is way more powerful than this but for an exam tool to save you some time this is probably as hard as you need to go into it. For a more in depth study of tclsh in IOS and how powerful it can be for operation use then I can recommend this Cisco Press book.


qir

View Comments
Cisco IOS access-lists are well understood, well documented and well, just plain necessary. We use access-lists to secure devices and services as well as to manage routing protocols and much more in routers and switches.

Access-lists come in a number of flavours so lets mentioned some of them here:

Standard access-lists
Extended access-lists
VLAN access-lists
Context-Based access-lists
NBAR enhanced access-lists (not really an access-list but can be used within ACL's to augment the matching process)
Zone Based access-lists

In this techguide we're just concentrating on the standard ACL.

So how do we say it? Ay'see'el? or ACKLE? It doesn't matter how you pronounce the name but the majority of the discussions I attend use the phonetic Ay'See'El (like you were reciting the letters individually A, C, L) way. Hey, what do I know, I'm a Brit and we pronounce route like Route as in Route66 (see Chuck Berry) So lets move onto something more interesting.

In this first encounter we'll go through standard ACL's. Access-lists are lists of lines which are read by the parser one by one from top to bottom. The lines are 'sorted' using line numbers which are incremented by default in 10's (e.g. the first permit/deny access-list statement will be prefaced with a line number of 10, the next line by 20, the next by 30 and so on) although this can be overridden. By function a standard ACL can only describe the source and it has no idea about protocol.

This is the format as written out:

access-list {1-99 | 1300-1999} {permit | deny} source-address [wildcard mask]

Here is a screenshot using the Cisco IOS context sensitive help to show the format of the access-list. We see here that the keyword to begin defining the access-list is simply 'access-list' in configuration mode. The '?' after 'access-list' simply engages the help output to be displayed.

Screen shot 2011-05-15 at 20.46.42

So we see looking down the list that standard ACL's can be defined using values between 1-99 and 1300-1999. We'll choose 1, it doesn't matter so long as it fits within those ranges described earlier. Using the help again we see the next choice is the action to take. Here we see we can 'deny', 'permit' or actually simply remark or comment on the access-list. Lets remark on the access-list as a first step to describe it's function "Test ACL for demo" It should perhaps be stated that the default action for any traffic which is NOT matched int eh access-list receives a 'deny' by default. You will not see this default action in any of your configuration but it is there.

Screen shot 2011-05-15 at 20.48.53

Screen shot 2011-05-15 at 20.50.52

Now we'll add to this ACL by permitting access from remote hosts on network 1.2.3.0/24.

Firstly lets see the options available to us to do this. OK so we use the permit keyword, thats required since we want to permit access. The ? reveals a few options now, hostname, any and host. What are we saying here? The easiest one to take on first is 'any'. By stating any we're saying basically permit (allow) any source.

Screen shot 2011-05-15 at 20.49.02

Using the keyword 'host' is very powerful and allows us to permit or deny access from a single IP address. The IOS parser simply reads the 'host' keyword and replaces it with a /32 mask in runtime. Remember an all 1's subnet mask (255.255.255.255) denotes a host.

So what if we want to permit all hosts on network 1.2.3.0/24? Well of course a /24 netmask is written as 255.255.255.0 (first 24 bits are 1's). IOS however expects the netmask to be written as a wildcard mask. A wildcard mask is the inverse of a network mask where a '1' is written as a '0'. The 255.255.255.0 therefore becomes 0.0.0.255. So lets add this new line in:

Screen shot 2011-05-15 at 21.00.42

Again we see we can add to this statement by using the 'log' keyword. Using 'log' allows us to see the number of matches this access-list receives.

So we now have an access-list in the configuration, we can see this here:

Screen shot 2011-05-15 at 21.03.28

The access-list is useless however without applying it to something. The access-list is powerful because it can be added it interfaces, protocols, services and probably more. We'll test out access list by applying it to our VTY service which is used to access the router across the network using protocols like telnet and SSH.

Using this topology we have created a loopback interface Lo2 on R2 with IP address 1.2.3.4/24.

1234

Lets assign the access-list 1 to the running configuration for the VTY interfaces on R1.

Screen shot 2011-05-15 at 21.09.48

Note that the access-list command changes to the 'access-group' command when it is being applied to the interface. Notice also that we are now adding a 'direction' of 'in' for the access-list. This means we are asking the router to look at packet arriving 'into' the router. The other option would be 'out' or 'outbound'. OK so we'll drop out of configuration mode back into privileged EXEC mode and run a show command to describe the status of the access-list. Notice it is given the default line of '10'. When access-lists are created each new line is incremented by a value of '10'. If we were to add a new permit or deny statement to out access-list it would start with a '20'. Remember once more that there is a default 'deny' at the end of any access-list which will be matched if no other lines within the access-list are matched.

Screen shot 2011-05-15 at 21.11.51

So lets telnet to the VTY interface running on IP address 10.1.12.1 (refer to diagram) and see what happens.

First we'll try to connect from the directly connected interface on R2 (from 10.1.12.2)

Screen shot 2011-05-15 at 21.19.15

Ah, we're denied access. If you recall we permitted access from nodes in network 1.2.3.0/24 and remember too that anything not specifically matched in the ACL will hit the implicit 'deny' statement at the end...well we're denied because our source IP address is 10.1.12.2. So lets override the default IP address used for the telnet on R2 and make it use the loopback Lo2 interface...

Screen shot 2011-05-15 at 21.22.36

OK, well that worked! So we should now see a hit in our access-list...

Screen shot 2011-05-15 at 21.23.17

We can see the matches at the end of the access-list there - 2 ;-)

Thanks for reading, see you next time with Extended Access-lists
View Comments
We're going to continue our last post on EIGRP discovery with an EGP protocol discovery (eBGP).

Screen+shot+2011-05-12+at+11.48.53

To present this in a demonstration we've done as before and created a two node network and will setup an eBGP adjacency between the two nodes. The link between the nodes will be using the 10.1.12.0/24 network.So we'll start up by setting the addressing on the interfaces as per the diagram. First R1:

Screen+shot+2011-05-12+at+11.18.41






Now R2:

Screen+shot+2011-05-12+at+11.19.05

OK, so maybe we do a ping to confirm connectivity:

Screen+shot+2011-05-12+at+11.19.25






So we're going to need a network to advertise into BGP so lets have a loopback on R2 with IP address 2.2.2.2/24:
Screen+shot+2011-05-12+at+11.20.38
Great all done for interfaces and networks, lets crack on and configure the BGP on router R2. We're going to configure the BGP session with AS#123. We'll set the BGP router-id as the loopback address (this is shown for completeness but is not an essential configuration step). We're going to add the loopback interface in as a network to advertise. Remember the BGP 'network' statement doesn't work int he same way as most IGPs. The 'network' statement in BGP is saying "Here is a network I want to advertise to my neighbors".
Screen+shot+2011-05-12+at+11.32.49


So the 'neighbor' statement is saying here is my BGP neighbor IP address (in our case R1 with 10.1.12.1 and it's remote-as number is 100.

Right, lets move on to R1 now and configure the BGP session there. We'll want to use AS#100 (remember R2 pointed to remote-as 100) and then add in the neighbor statement. In this example we're not really interested in sending any networks from R1 to R2 so there are no network statements of redistributions etc.
Screen+shot+2011-05-12+at+11.33.49
OK! we'll we've put the configuration in and almost immediately we'd commited the neighbor statement to the running config the router went away and tried to establish the BGP session. The router has dumped a log to the console which includes a lot of HEX formatted 'guff' (thats a technical term).

To troubleshoot the issue lets dissect the debug/log. We see that we have a BGP notification saying that the 'peer in wrong AS'. So R1 ha been told here by R2 that the AS number it is using doesn't match it's configured AS#. The router tells you that the AS# is 2 bytes long and...it is ;-) AS#'s are valid between the range of 0 and 64511 (64512 to 65535 are reserved for private use.

Anyway back to the story, the remote side AS# is contained in the log dump as the first 2 bytes after the word '2 bytes' ;-)

as_num

The HEX following the message is 007B and the BGP AS# is DECIMAL so we'll need to convert it...where is that scientific calculator?
Screen+shot+2011-05-12+at+11.35.04
So we'll use the MAC calculator. Click the '16' button because HEX is base 16...why can't they just say HEX? So lets pop in the HEX we got in the log message 007B. So now click the 10 button because DECIMAL is base 10...of course ;-) and we get...drum roll please
Screen+shot+2011-05-12+at+11.34.53
Right so the remote AS# is 123...of course...why didn't I just click on R2 and do a show running-config ;-) We'll this is a scenario of course and it's all about the 'win'.

So lets go onto R1 and change that neighbor line to reflect the correct AS# of 123 not 1 as we had originally set it.
Screen+shot+2011-05-12+at+11.34.24
Great, and the BGP session has come up. Tell you what lets just have a look in the routing table to see if that loopback0 interface from R2 is in there?
Screen+shot+2011-05-12+at+11.34.34

So thats it, BGP is up and routing updates are being received. 
Job well done.



View Comments
Sometimes you find yourself in a bad place, you've forgotten the AS number you configured on your router in LA, you locked out VTY access to the directly connected interface and you've lost your documentation. So you're in Massapequa, NJ and you've got your MPLS VLAN up to the LA office but you can't get onto the loopback interface. You need to bring the EIGRP neighborship up and get that good stuff flowing ;-)

This techguide will show you how to discover the remote side AS number for EIGRP. Lets talk a little about EIGRP so we get some background. We'll it's got it's own protocol (88) number and uses RTP (reliable transport protocol) for delivery. The EIGRP traffic is distributed using IP multicast on address 224.0.0.10 for discovery with updates as unicast and queries as multicast. The initial setup 'are you there' messages are sent as multicast.

So knowing this information we can see that by capturing the traffic between two EIGRP neighbors we should be able to discover the AS number since the AS number will be sent in the discovery as part of the setup process (subsequent updates and replies will also contain the AS#).

To prove it out we've got a basic topology:

Screen+shot+2011-05-11+at+11.38.11


R1 is directly connected to R2 using a fast ethernet connection.

We've configured the interfaces already using the network 10.1.12.0/24 with 10.1.12.1/24 for R1 (see below)

Screen+shot+2011-05-11+at+11.00.17

and 10.1.12.2/24 for R2

Screen+shot+2011-05-11+at+11.00.34


Right - lets put the EIGRP configuration in:

First R1

Screen+shot+2011-05-11+at+10.58.13


Then R2


Screen+shot+2011-05-11+at+10.59.31


So, we've basically built the basic configuration, nothing fancy. We've added the interface Fa0/0 in for both routers so EIGRP will be enabled onto those. We've also added in the Loopback0 interface of each (just because we did - it has no part to play for this post and can be ignored). You should however give some attention to the chosen EIGRP AS #. Notice that the router R2 has AS# 12345 where R1 is as AS #1. We've done this o illustrate the point that we don't know the remote AS. We need to use an AS number to make EIGRP work int he first place...you can choose any AS number here so long as it isn't 12345 ;-) Think back to the original example where we discussed LA and NJ...you are not supposed to know the AS# otherwise what is the point of debugging the problem?

Right, how do we catch the traffic? Well the router clearly sees all the traffic we need so it makes sense to use the router to collect and show the packets right? OK we all probably know and use 'debug ip packet' but hopefully not on production systems unless you know what you are doing. Here is a screenshot for the command.


Screen+shot+2011-05-11+at+11.11.29

Notice the access-list on the end? We could use this to tune down the traffic which the router will be examining. Indeed using 'debug ip packet' on a production system would be suicidal without some sort of filtering. For our demo here however we're not going to need this filtering because we don't have any traffic. You *should* definately note however that there is a missing or 'hidden' command here called 'dump'. IOS has a few of these little easter eggs hiding in the code. Normally it's because they are either really dangerous in the wrong hands or else they are not very well tested and therefore shouldn't be used by mortals. In this case I feel the dump keyword is missed off because if you thought debug ip packet created too much console information to be healthy then adding dumps of data to the console is never going to be the best plan.

So we turn on debugging and ask it to also crack open and dump the data inside the packet like a typical pcap...HEX and all that good stuff.

Screen+shot+2011-05-11+at+11.11.58


OK so here is a dump of data. We see the sources are our local Fa0/0 (s=10.1.12.1) and Loopback0 (s=1.1.1.1) interfaces. OK so where is the R2 traffic?

Screen+shot+2011-05-11+at+11.13.36

Here's one s=10.1.12.2 great. So where is the AS number man...I bet the big red circle gives it away for you. The first few bytes are header so things like destination MAC for EIGRP mulicast group 224.0.0.10 (0100.5e00.000a) followed by source MAC of R2 (c201.0cab.0000)...etc.

So we have the HEX value of 3039 remember EIGRP uses values from 0 to 65535 which is a 32 bit number (same number of bits as an IP address). So lets pop 3039 into a HEX to DEC calculator and we get 12345...thats IT!

Job done - all we need to do now is change the AS number we used in R1 (AS#1) with the one we just 'discovered' (AS#12345). Now because we can't simply rename the AS number we need to tear down the original and rebuild it. If you had a lot of config below the 'router eigrp' function you are best to do a 'show run | b router eigrp' and copy the config then all you need to do is paste it in.

Screen+shot+2011-05-11+at+12.15.27

Job done - enjoy

View Comments
Hi all,

I know you're all desperate to find out how we configure Q-in-Q between IOS and JunOS and here we have it. You know, when we did this the effort required to get the Juniper EX part done was worrying. The Juniper documentation was pretty good and the Cisco Q-in-Q part is very well documented of course. This techguide will hopefully help some of you out there desperate to join these two great platforms as one.

First I guess we should provide a little background to Q-in-Q services. The idea is pretty simple, Q-in-Q is a process whereby a normal 802.1q frame is attached to another 802.1q header, hence the name. You will most likely use this is you have a requirement to say connect two layer 3 networks together which are separated by a layer 2 network. The layer 3 networks at each end may be in the same subnet and each of these geographically disparate networks can act as one.

Here is our challenge:

qinq

The laptop at the top of the diagram is connected to a Cisco 6509E and is in VLAN 186 with layer 3 network 10.1.186.0/24. We have another laptop at the bottom of the diagram connected to a Juniper EX cluster again in VLAN 186 with network 10.1.186.0/24. We need to get both of these laptops to operate within the same network despite being separated by a number of switches and hops. That is to say when I ping from one side to the other I want one hop to the destination.

Lets begin.

First we're hopefully all up to speed on VLANs and what they mean. If you need to read up on VLANs then take at look at our other techguides for a reminder. Lets create VLAN 186 on the first 6500 connected to the laptop and then place the port connected to the laptop into that vlan:

6500_FRONT(config#) vlan 186
6500_FRONT(config-vlan)# name X_SITE_INTERNET
6500_FRONT(config-vlan)# exit
6500_FRONT(config)# int g0/0
6500_FRONT(config-if)# switchport mode access
6500_FRONT(config-if)# switchport access vlan 186
6500_FRONT(config-if)# no shutdown
6500_FRONT(config-if)# end
6500_FRONT#

So now lets take a look at the port connected between the FRONT and BACK 6500's. We need to configure this as an 802.1q port. Remember the Q-in-Q takes our 802.1q frames first.

show_run_int_a_end


So we take the VLAN 186 and only allow it on this port. Untagged traffic is also placed into VLAN 186 but this is necessary. We've forced the port to not use DTP (switchport nonegotiate) and we're manually configuring it as a trunk port. Forcing the port as a trunk is not required but is good practice.

Lets have a look at the 6500_BACK configuration for the port connected to the 6500_FRONT G4/11.

show_run_int_a_end_bk


OK, looks like a lot of configuration here so lets go through the main lines. Now on a trunk port if you have a configuration for an access vlan (switchport access vlan) but configure 'switchport mode trunk' then the port os a trunk port and the acces vlan configuration is ignored. In our case we're configuring a dot1q tunnel port and therefore the access vlan IS IMPORTANT. So what are we saying here? Basically the 802.1q tagged traffic ingress into the port is left tagged (as if it were an access port with no tagging). The next line switchport mode dot1q-tunnel no performs the double tagging - we're going to be ramming tagged VLAN 186 traffic into VLAN 3043. The MTU is set to 9216 to accommodate for the double 802.1Q tag and should not be missed. 

We're disabling CDP so that we can tunnel CDP. What?! Well to help to explain this here is an example. When you have two directly connected cisco devices and CDP is running and enabled on these ports then you can 'see' the other device by issuing a 'show cdp neighbors'. This process is true also for Q-in-Q neighbors but we must turn off CDP between the two endpoints for the tunnel or else it would stomp all over the tunnel start points (in our example CDP would be tunnelled from 6500_FRONT but since the other startpoint is a Juniper device which doesn't undertsand CDP this step is unnecessary).

The l2ptotocol-tunnel allows us to send spanning-tree BPDU's down the Q-in-Q tunnel and CDP...we don't need them in our example but maybe you are creating a spanning-tree loop in your deployment so I think these lines are useful...just in case.

So now we are going to configure a normal run of the mill ordinary 802.1Q trunk link between the 6500_BACK and 3560 switches.

6500_BACK# configure terminal
6500_BACK(config)# interface g4/12
6500_BACK(config-if) switchport trunk encapsulation dot1q
6500_BACK(config-if) switchport mode trunk
6500_BACK(config-if) switchport trunk allowed vlan 1559,2127,3043,3738
6500_BACK(config-if) mtu 9216

So here we're just creating a normal trunk as we said. We're going to be trunking the Q-in-Q vlan 3043 we already created. Don't forget the jumbo frame MTU requirement. The other VLANs allowed on the trunk are for other things.

Right, at the other end of the link between the 6500 and 3560 we're going to again configure a normal bog standard trunk. 

show_run_int_b_end_it

On the 3560 there is one requirement to enable jumbo frames before this will work. In global configuration mode we issue:

3560(config)# system mtu jumbo

Then we need a reboot. Without this line the switch will not be able to support the minimum 1504 bytes required to transport the Q-in-Q frames. So when we're back we can move on - all should be fine so far...it's just trunking.

Here is the configuration for the port connected to the Juniper EX stack.

show_run_int_b_end_toex


So we're still trunking 3043...and some others but ignore those.

Now onto the Juniper EX stack dot1q-tunnel configuration.

First enable the protocol frame support.

junos_ex_dot1q


Now lets create the VLAN - this took some time to get right int he Juniper documentation.

junos_ex_dot1q_part2

So we have created two vlans here. The first called X_SITE_INTERNET0 is carrying the Q-in-Q trunk traffic. Vlan XSITE_BACKBONE is carrying the untagged vlan 186 traffic.

Lets configure the port connected to the Cisco 3560. Again we need a dot1q trunk port and we'll restrict it to carrying only VLAN 3043.

show_run_int_ex_to_ciscotrunk

So the last port configuration part if for the laptop port...

junos_ex_dot1q_part3


A quick 'show vlans XSITE_INTERNET_0 extensive'?


junos_ex_dot1q_part4


We see here that the 'Customer VLANs' are 186-186...or just 186 ;-) the ports ge-1/1/0.0 and ge-2/1/1.0 are the trunk ports connected to upstream Cisco switches (we've only looked at one of them...why do you think I had the STP stuff listed earlier ;-) ). The access ports are connected to host devices and are each in VLAN 186.

So there we go, IOS to JunOS using dot1q tunnelling. IT works, it's great tech, have fu.

View Comments
We all know the pain of static IP address assignment on large networks. The majority of us would probably configure DHCP services onto a server or host like Windows or a *nix platform. This guide is going to show you how to configure DHCP in IOS. You have to be clear on this however, Cisco devices whether a switch or router are NOT really meant to be a DHCP server. The function of your network device is pushing traffic around ;-) If you really really really must do this then take it in the context it is meant. DHCP on a Cisco device is only ever going to be a best effort service. It'll work and it'll work well but don't expect too much in terms of lease visibility.

So lets begin with a little overview of the DHCP protocol. Way way back in the early to mid 90's we had BOOTP (RFC 951). This protocol was often used for disk-less hosts using a BOOTPROM. The BPROM would broadcast out it's MAC address onto the LAN and the BOOTP server would send back an IP address plus the BOOT server and BOOT image required by the disk-less server to boot its operating system. BOOTP worked well for single networks but didn't include a things like IP gateways so the host didn't know how to get out.

Along comes DHCP. With this reworking of BOOTP we now have included options like default gateway, DNS servers, WINS servers and all manner of extra IP host configuration parameters to aid the modern client.

The DHCP 'lease' process whereby the client is provided with a unique IP address follows a 4 way process:

i) Client comes online and will broadcast a DISCOVER message onto the network
ii) DHCP server hears the DISCOVER and sends OFFER message in response
iii) The client sends a REQUEST message back to the server saying 'sounds good to me man, I'll take it'
iv) The SERVER sends an ACKNOWLEDGE message to the client saying 'You're welcome'

So thats the process, how do we setup the cisco router or layer 3 switch to do DHCP leasing. WE'll configure our router to lease IP addresses from the 172.16.1.0 255.255.255.0 subnet. Set the netmask, default gateway, dns-servers and domain name. The only REQUIRED part is the 'network' statement, all of the others are optional.

R1# configure term
R1(config)# ip dhcp pool TEST
R1(dhcp-config)# network 172.16.0.0 /16
R1(dhcp-config)# default-router 172.16.1.1
R1(dhcp-config)# dns-server 172.16.1.5 172.16.1.6
R1(dhcp-config)# domain-name mynetwork.com


So what if we've got some static addresses in the network which have been set statically? For example, above we have two DNS servers 172.16.1.5 and 172.16.1.6. What about the default gateway which was 172.16.1.1? We don't want the DHCP server leasing those addresses. You should note that most modern DHCP servers including the Windows DHCP server perform an initial ping on the LEASE address before the OFFER is sent. This way any already live addresses will be noticed and made invalid for lease to avoid duplicate addresses.

Anyway - lets ask the router to NOT lease addresses between 172.16.1.1 and 172.16.1.10 so we can use those addresses statically and be assured it won't OFFER them.

R1#(config) ip dhcp excluded-adresses 172.16.1.1 172.16.1.10
R1#(config) end


So thats it! Pop a client onto the LAN to check it out.

Don't forget to enable the dhcp service or to check leasing using:

R1(config)# service dhcp


R1# show ip dhcp server statistics
BOOTREQUEST          0
DHCPDISCOVER         63
DHCPREQUEST          203
DHCPDECLINE          1
DHCPRELEASE          27
DHCPINFORM           19
View Comments
We’re going to be talking about 802.1D, this is the classic spanning-tree protocol and NOT as my good colleague suggested the model number for the Enterprise in Star Trek 'Next Generation' which we all know was the NCC 1701D.

ncc1701d

We all like failover, fallback and redundancy in our networks. Resilience to failure of any one (or more) components in the network is always a good thing. In the switching world we use spanning tree to offer us the ability to create a dynamic loop free layer 2 bridge topology. How does it do this? Well by using specific frames on the network called BPDU's (Bridge Protocol Data Units) the spanning-tree protocol dynamically 'blocks' one of the links in the redundant loop.

Here is the basic topology

bridging_loop


Here we have a physical loop for traffic moving from Switch A to Switch B to Switch C or Switch A to Switch C to Switch B...you get the idea. The point is that traffic flow like that can easily and very quickly get out of hand and cause what is common miss-quoted as a spanning-tree loop but which is in fact a bridging or switching loop.

In a bridging loop example, Switch C receives a request from a node connected to one of it's ports (Client PC). The destination for the request is to an unknown host (Web Server) connected to Switch A. Now Switch A (who doesn't know Web Server is connected to Switch A) broadcasts the frame out of all ports (remember, this is the default behaviour of a switch for an unknown destination mac address). The layer 2 mac request is picked up by the host connected to Switch A who politely passes that information back to Switch C ("Hey I'm Web Server and here is my MAC address so populate your mac table!"). Now crucially Switch_B forwards the initial lookup sent from Client PC out of all of it's ports (remember it also doesn't have a layer 2 mapping for the frame). The MAC request gets to Switch_A from Switch_B and Switch A forwards the frame to Client PC and that's all fine. Now also recall that Switch A is going to flood the frame out of all ports except the one it received from. This means that the frame from Switch B is sent out toward Switch C! So you can see how a switch could get confused about which way to send traffic and this is for a unicast lookup. Now if we think about broadcast traffic where the frame is always sent to all ports this loop design is going to cause some headaches. Indeed I've seen this sort of thing bring down pretty big switches very very easily and they are difficult to find  except for asking who just did something ;-)

So spanning-tree is pretty essential for workable layer 2 resilience. In the diagram you can see an etherchannel there though...and thats a loop isn't it? Two links between switches...feels a bit 'loopy' to me. Well you know etherchannel in IOS and LAG in JunOS are a great way of adding resilience between switches as well as capacity and the good news is that to spanning tree they look like one link.

Thanks for reading and the colleague who suggested 802.1D was the model number for the Enterprise wishes you all a good night.

Khan

View Comments

A basic starter showing a few of the more simple ways to manipulate your traffic



The topology has been set as shown here. The customers preferred path between R1 and R5 is via R2 and R3 NOT R4. The customer has no control over R5 or the links connected to it and you are asked to influence the traffic coming from R1’s loopback interface (1.1.1.1) to R5’s loopback interface 5.5.5.5. The customer is clear that you are to use no static route to meet the requirement.

Screen shot 2011-05-08 at 23.45.30

R1 f0/0 <-> f0/0 R2 (10.12.1.0/24)
R2 f1/0 <-> f1/0 R3 (10.23.1.0/24)
R1 f1/0 <-> f1/0 R4 (10.14.1.0/24)
R4 f0/0 <-> f0/0 R5 (10.45.1.0/24)
R5 f1/0 <-> f0/0 R3 (10.35.1.0/24)

Starting with a clean sheet, this is the routing table for R1. You can see that OSPF has been configured throughout the topology and that each router has advertises it’s loopback 0 interface.

Screen shot 2011-05-08 at 23.51.09

The routing table here shows that the route to R5’s loopback is via the next hop of 10.14.1.4 or R4’s FastEthernet1/0 interface. So what are the options (this list is not exhaustive and is to show some of the more obvious ones).

  • Influence the OSPF calculation by manipulating bandwidth
  • Influence the OSPF calculation by adding a ‘cost’
  • Change the next-hop using a route-map
  • Use default route and filter out the network route
  • Introduce a lower metric routing protocol to override the OSPF metric
  • Create a tunnel to bypass the normal routing table

Influence the OSPF calculation by manipulating bandwidth

Now normally OSPF uses the SPF Djikstra algorithm to calculate the best path through a network. To include some sort of capacity indicator into this OSPF uses
a ’reference bandwidth’. The default reference bandwidth is 100Mbps and so for a Fast Ethernet interface running at the default speed of 100Mbps would create an
OSPF cost of 1 (100/100=1). Our screenshot above clearly has a metric of 3 for 5.5.5.0 via 10.14.1.4. This is because the traffic has hopped from R1-R4 then R4 to R5 then R5 to R5’s loopback interface (yes thats a hop too). So if we want the traffic to go via R2 instead then we need to make R4’s interface bandwidth lower. Lets choose a bandwidth of 10000 or 10Mbps. By the way, you can change the denominator and accumulator in this equation! The relative OSPF bandwidth is changed under the
OSPF process using the ‘auto reference-bandwidth’ command (remember the default is 100)

First take a look at the default bandwidth figure - denoted here as BW

Screen shot 2011-05-09 at 00.01.52

Now we’ll change the interface closest to R5, remember the cost is additive for the path.

Screen shot 2011-05-09 at 00.03.30

Now lets take a look back at R1’s routing table for the R5 loopback interface.

Screen shot 2011-05-09 at 00.03.41

Now the path is via R2’s Fa0/0 interface. Why? Because we made OSPF add a cost of 10 for the route between R4 and R5 so now the route via R2 and R3 has a lower metric of just 4.

Influence the OSPF calculation by adding a ‘cost’


We’ve reset the bandwidth on the R4 interface and R1 now has a preference back to R4 with a cost of 3. One of the quicker and neater ways to influence OSPF is to use the interface level ‘ip ospf cost’ command. This command overrides the reference bandwidth and interface bandwidth calculation. In this case, whichever is the lowest cost wins.

Lets change the cost via R4 on R1. First lets just check we’ve got the right metric via R4...

Screen shot 2011-05-09 at 00.08.44

Now lets apply the interface cost command to make R4 a really bad choice...

Screen shot 2011-05-09 at 00.10.14

Confirm the routing table once more to be sure we’re preferring R2 again...

Screen shot 2011-05-09 at 00.10.49

Great...all going well so far.

Change the next-hop using a route-map


Route-maps are really really powerful tools and you are going to use more and more of them especially if you are keen on the CCIE lab exam. For our little lab we’re going to use a route-map to match some traffic and force it to bypass the normal routing table. Now normally when packets are routed they lookup the next hop int eh table etc etc. With a route-map we can force the next-hop to be different from the norm. So long as the next-hop is in the routing table we can send that traffic anywhere.

Lets do it. First of all we blow away the config from the previous lab.

Lets create teh access-list we are going to use to catch the traffic we need for the next hop. We just want traffic from our loopback0 interface going to R5’s loopback, everything else should take the normal route.

Screen shot 2011-05-09 at 00.15.24

Next we create the route-map statement which uses our access-list to match the traffic then the ‘next-hop’ statement to force the next hop for that traffic.

Screen shot 2011-05-09 at 00.17.30

One final thing. Because we are trying to influence traffic sourced on our router we need one other command. For traffic passing through our router this is not necessary and instead we use the interface level ip policy route-map’ command.

Screen shot 2011-05-09 at 00.19.13

So lets have a look at the routing table, it should be normal with the route to R5’s loopback still going via R4...

Screen shot 2011-05-09 at 00.20.00

Yep looks good....so what if we do a traceroute to R5?

Screen shot 2011-05-09 at 00.21.19

Yeah thats right...is it what YOU expected? Hopefully you’ve been following along. Recall that we setup the route-map ONLY to match traffci from our loopback going to R5’s loopback? Well that traceroute just picked up the closest route to R5’s loopback. We’ll run the command again but this time source it from R1’s loopback...

Screen shot 2011-05-09 at 00.20.39

Awesome, you see it went via R2! Lets check the access-list to make sure we are hitting that...

Screen shot 2011-05-09 at 00.23.14

9 matches? How come? Well traceroute will send 3 ICMP per hop you can see that in the output where 10.12.1.2 got 4 millisec, 12 millisec and 4 millisenc responses. Anyway...it worked for us ;-) Lets move on.

  • Use default route and filter out the network route

I’m really proud f myself for thinking up this crazy ‘fix’. So lets have a quick time out to think this through. In the routing table, the route with the best match will be active. That is to say, if you have a more specific route to somewhere then that route will take precedence. So what am I talking about here? Well we want to go via R2 right? ut the specific route for 5.5.5.0/24 is being advertised from R4. So here is what I propose. Lets filter out the network 5.5.5.0/24 from coming into the routing table of R1 (remember we can’t filter the route from the OSPF table but we can stop it being placed into the active routing table). At the same time lets inject a default route from R2 so that R1 gets a defaultroute for all networks it doens’t know about pointing at R2. All being well because R1 won’t have a route to 5.5.5.0/24 anymore it should use the default? Clear? Lets go!

First off lets create the default route on R2. Now remember, we don’t already have a default route int he table so we use the ‘always’ keyword here to advertise teh default route even though we don’t already have one.

Screen shot 2011-05-09 at 00.31.51

Lets just check we have that route in R1’s table.

Screen shot 2011-05-09 at 00.33.07

Yeah you can see we have it right at the bottom, we also still have the 5.5.5.0 route via R4 so lets remove that now with a ‘distribute-list’. The distribute list works on matching values from an access-list. We create a standard access-list 2 and tell it to DENY 5.5.5.0/24 but permit everything else. The second line is important because without it the distribute list would block all routes coming in (remember the default action of an access-list is DENY)
Screen shot 2011-05-09 at 00.34.33

So we’re denying 5.5.5.0/24 and permitting everything else...did it work?


Screen shot 2011-05-09 at 00.36.25

Well we’ve got rid of the route to 5.5.5.0/24 and we only have the default now...so lets see what path we take to get to R5’s loopback now.

Screen shot 2011-05-09 at 00.37.14

Perfect, lets move on.

Introduce a lower metric routing protocol to override the OSPF metric


OK so OSPF has a distance of 110 by default on the router. That means it has a precedence over any routing protocols with a higher distance. So who is lower? Well in the IGP world the most obvious choice here is EIGRP with an AD of 90. So lets crack on and put EIGRP between R2 and R1 and try to influence the traffic.

First lets enable EIGRP on R1


Screen shot 2011-05-09 at 00.38.50

Now R2

Screen shot 2011-05-09 at 00.39.35

Great, we see the adjacency come up. There won’t be any routes in the table yet however because we didn’t add any network statements yet except their shared subnet. So lets now redistribute the OSPF route for 5.5.5.0/24 into EIGRP. Remember, the plan here is to advertise a route using EIGRP between R2 and R1 which will override the OSPF route being advertised from R4 to R1 (and R2 to R1).

So lets create an access-list to match the route we want to redistribute from OSPF into EIGRP. Then we’ll create a route-map then we’ll go into the EIGRP process and redistribute. The numbers after the redistribution are the all important EIGRP K values. We need to seed them with numbers or else the route will NOT go into EIGRP.

Screen shot 2011-05-09 at 00.44.12

So lets make sure we’re redistributing now with a ‘show ip route 5.5.5.0 on R2

Screen shot 2011-05-09 at 00.44.42

Perfect! Now R1 should have an EIGRP route in it;’s table for 5.5.5.0 with a distance of 90.


Screen shot 2011-05-09 at 00.45.47

Hmm, no routes from EIGRP?! Whats gone wrong here?! Well, actually nothing went wrong here. The thing about EIGRP is it has two distances, one for internal routes and one for external. Anything redistributed into EIGRP gets the external distance and guess what, that distance is 170...man thats 60 more than OSPF so it’s not int he table. What can we do? OK so distance is only relevant to the local router so lets be kind to ourselves and just change the distance for EIGRP external routes on R1. The first number is the distance for internal routes and the second for external routes. What we are saying here therefore is every EIGRP route has a distance of 90 on this router.

Screen shot 2011-05-09 at 00.48.19

So lets check those EIGRP routes once more.

Screen shot 2011-05-09 at 00.49.32

Perfect...and a traceroute just to be sure...

Screen shot 2011-05-09 at 00.50.14

Excellent, lets move on.

Create a tunnel to bypass the normal routing table


We love tunnels, tunnels are good, tunnels save time and are cool (unless you get cyclical routing but lets not worry too much about that yet). Lets recap on what we are trying to do here. Get traffic to bypass R4 from R1’s loopback to R5’s loopback. So how about we create a tunnel from R1 to R5? Well that would be good because it’s a tunnel but unless we do something about the next-hop like we did earlier then the tunnel will go across R4. We could do some great service provider stuff using VFR’s and MPLS but again, maybe it’s overkill. We don’t even have control over R5 so we can’t even create a tunnel if we wanted to.

So the best we could do here is create a tunnel from R1 to R3 then we could set the cost of the link to the same as R4 and then maybe get some awesome equal cost load balancing going on...hey 50% is better than none. Lets give it a shot.

First on R1 lets create the tunnel interface. You could choose the loopback interfaces as the source and destination - I’ve chosen the interface for brevity and OSPF cost reasons.

Screen shot 2011-05-09 at 00.59.43

Now R3

Screen shot 2011-05-09 at 01.00.07

So a ping from R3 to the ip address of R1’s tunnel0 interface?

Screen shot 2011-05-09 at 01.01.16

Great, now we’ll put the network into OSPF - ouch recursive! We get this because I’m learning about 10.23.1.0/24 from the tunnel interface but also I need to learn how to build the tunnel interface by finding the route to 10.23.1.0/24...I can’t do both. It’s the whole chicken and egg thing! So we setup an access list like before denying 10.23.1.0/24 from being learnt via the tunnel interface.

Screen shot 2011-05-09 at 01.03.54

OK all stable now and tunnel is up so lets set the OSPF cost to match the route via R4.

Screen shot 2011-05-09 at 01.12.11

Now lets have a look at the routing table.

Screen shot 2011-05-09 at 01.11.22

Great two equal cost routes as expected, one via R4 and one via Tu0...what about a ping then?

Screen shot 2011-05-09 at 01.11.58

Lovely, and on that note it’s goodbye from me.
View Comments
First you need to find an IPv6 broker. There are a few out there and we've chosen Hurricane Electric as our transit host of choice (they also offer a nifty certification at the end of a small test to make sure you are learning as you go).

So, go ahead and register for an account with your IPv6 broker of choice. They will probably offer you one /64 network which forms the 'link' between them and you and a /48 network which is for your LAN. Now in the IPv4 world we hate waste and normally you would subnet your point-to-point links with say a /30 subnet to give you a network, broadcast plus 2 host addresses. The IPv6 world is at this point not encouraging the use of /126 or /127 subnet masks for point-to-point links but instead is suggesting a /64. Of course this means that the point-to-point link now has 1.810 addresses available...ah no worries.

So you have your allocations so lets crack on configuring your router.

First things first you know that you are running IPv4 and your ISP probably doesn't support your desire to run IPv6 over their network. So we pick up that old Cisco trick of encapsulating the unsupported IPv6 traffic into IPv4 packets. A tunnel is perfect for this and luckily we can perform this 6-to-4 transformation using IPv6 inside both GRE or IP packets.

In the example below we have configured our tunnel interface and Tu0. We are setting the encapsulation type as IPv6IP (IPv6 inside an IP packet). Maybe (optional) we set a description on the interface. We set the local and remote IPv4 addresses for the tunnel. Now we enable IPv6 and then finally we give it the IPv6 address.

router> enable
router# configure terminal
router(config)# interface tunnel0
router(config)# ipv6 unicast-routing
router(config-if)# description My First IPv6 Tunnel
router(config-if)# tunnel source
router(config-if)# tunnel destination
router(config-if)# tunnel mode ipv6ip
router(config-if)# ipv6 enable
router(config-if)# ipv6 address

Here is a working example.

tunnel_interface

Thats it. So now lets have a look at the tunnel and make sure it's up and running.

show_interface_tu0

Well that looks good but we still need to setup the routing table just like IPv4. We'll create a single static default route pointing all IPv6 traffic into the new tunnel interface. You could also use the IPv6 address of the broker side of the tunnel to save the recursion but the interface works fine.

router> enable
router# configure terminal
router(config)# ipv6 route ::0/0 tunnel0

Maybe we can do a ping to an ipv6 address to make sure all is well (please understand that our router has been configured to perform dns lookups against the google DNS servers using the 'ip domain-lookup' and 'ip name-server 8.8.8.8' commands in global configuration mode).

ping_ipv6_google_com

So that worked a treat and we're able to get out to the internet. There are two steps left. Firstly we need to enable your local LAN addressing now using the new /48 your broker allocated to you so lets do that now.

Now there is a question around what address do you use on the LAN from your /48 allocation. Well lets consider the IPv6 address for a moment. The first 64 bits are considered as the network. As an example our IPv6 /48 allocation looks like this:

2001:470:93FE::/48

The first 48 bits are 2001:0470:93FE and so we can subnet this into 65535 subnetworks working from 2001:470:93FE:1::/64 through to 2001:470:93FE:FFFF::/64. Do you see we are just changing the bits after the 93FE and the double colon ::? If you need to understand the IPv6 addressing then thats for another time, so for now lets move on. Choose a /64 network to work with...lets take 2001:470:93FE:1::/64.

router> enable
router# configure terminal
router(config)# interface G0/0
router(config-if)# description My Inside Interface
router(config-if)# ipv6 enable
router(config-if)# ipv6 address 2001:470:93FE:1::/64 eui-64

Whats the eui-64 all about? Well basically it creates a unique IPv6 address by taking the 48-bit MAC address of the interface, reversing the 7bit around, jamming another 16 bits of FFFE into the middle and putting the rest it to the end of your existing /64 address. Scared? Don't be, it's really nice. You can of course choose to fix your own IP address by doing this instead:

router(config-if)# ipv6 address 2001:470:93FE:1::1/64

We've chosen .1 as the router address and why not. So now thats done pick a host on behind this interface on your router, enable IPv6 on the stack and away you go. There are some other things in IPv6 like neighbor discovery (ICMPv6) which lists neighbor capability like DHCP servers and routing etc but thats for another time. This should be all you need to get routing IPv6.

So what about security? I'm guessing you're already using access lists on your router right? Maybe it's a standard or extended ACL, maybe it's reflexive or CBAC or even maybe ZBF? The point is that you have some sort of access control. IPv6 is no different so lets take a look at a quick and dirty access list for IPv6 using a reflexive ACL. We'll create two ACL's called TU0-INBOUND (Tunnel inbound) and TU0-OUTBOUND (tunnel Outbound). We'll basically just allow ping and then any outbound TCP and UDP traffic will be permitted and relexive. Anything inbound which was not initiated from inside the router OR a ping will be denied and logged.

ipv6 access-list TU0-INBOUND
permit icmp any any echo-request
permit icmp any any echo-reply
evaluate REFLECTOUT
deny ipv6 any any log-input

ipv6 access-list TU0-OUTBOUND
permit icmp any any echo-reply
permit icmp any any echo-request
permit tcp any any reflect REFLECTOUT
permit udp any any reflect REFLECTOUT
deny ipv6 any any log-input

Then we should apply these to the tunnel0 interface.

router(config)# int tu0
router(config-if)# ipv6 traffic-filter TU0-INBOUND in
router(config-if)# ipv6 traffic-filter TU0-INBOUND out

So lets fire up a web browser and see if we can get to an IPv6 enabled website...this is ipv6-test.com

ipv6-test_com

Now we'll escape back to priv exec mode and do a quick 'show access-lists' to see if we are matching rules.

show_access_lists

Hey we have traffic matches.

Thats it. Enjoy



View Comments
Whats the big deal about a defaultroute? The defaultroute is the last resort path your IP traffic takes to get out of your local network if it doesn’t have a more specific route in it’s routing table.

Well you know, the current internet routing table is hitting around 370,000 entries or so today. Having all of those routes sat on your PC is not going to be a good thing for your RAM or CPU when you have to store and lookup those routes. So what do we do, we have a default route pointing at a gateway device on our network. So, that gateway might be a layer 3 switch where the gateway address is a virtual switch interface (VSI). Do you think your switch was built to hold 370k+ routes? No sir you are correct. Most likely therefore your first hop gateway device will also have a default gateway configured pointing to an upstream device like your firewall. So, that firewall, is that likely to be fantastic enough to hold these routes to the internet? You guessed right, no way. So your firewall has a default route to another upstream gateway like you CPE (Customer/Provider Edge) router. Now finally this is the most likely place you’ll not find a default route. If you are taking a full BGP feed from your ISP then you don’t need a default route because your router learns all of the networks out there. So do you need a full routing table here? If you are connected to one ISP with one link...nope you do NOT need the full routing table and a default route from the next hop (the ISP neighbor router) is enough.

Now we see the defaultroute and it’s importance it’s important to understand why it’s a bad thing for network security. If you give your devices access to a network which contains a default route then it’s something which an attacker can use to ‘get around’. Without a route to a destination packets are dropped - just think about that - network security without a firewall - awesome.

So if we want a default route how can we have one?

We’re going to start our ramble into default routes using the humble and powerful but ultimately high maintenance static route.

  • Static route - easiest to configure but least scalable. In this example we’ll walk through a defaultroute to get traffic via from the source interface of Loopback0 on R1 to the destination interface of Loopback0 on R4.

  • Here is the topology:

  • Screen shot 2011-05-03 at 22.48.25


  • Some topology information:
  • R1 Fa1/0 10.1.13.1/24 <-> R3 Fa1/0 10.1.13.3/24
  • R1 Fa0/0 10.1.12.1/24 <-> R2 Fa0/0 10.1.12.2/24
  • R3 Fa0/0 10.1.34.3/24 <-> R4 Fa0/0 10.1.34.4/24
  • R2 Fa1/0 10.1.24.2/24 <-> R4 Fa1/0 10.1.24.4/24
  • R1 Loopback0 1.1.1.1/32
  • R2 Loopback0 2.2.2.2/32
  • R3 Loopback0 3.3.3.3/32
  • R4 Loopback0 4.4.4.4/32
Screen shot 2011-05-03 at 23.02.10

Screen shot 2011-05-03 at 23.02.22

Screen shot 2011-05-03 at 23.02.34

Screen shot 2011-05-03 at 23.02.45

I’ve configured R2, R3 and R4 to ‘know’ how to reach the loopback interface of R1. This is key to the topology and you should try to think of R2 and R3 as intermediate systems rather like those of the internet. On the internet there are man hops in the network between you and your destination...just look at this traceroute for an example. I’ve removed the IP information from the first 4 hops to anonymise the result but you can see that my packets hop across 9 nodes before they get to the www.google.com server. In our example we’re going to hop twice to get to R4.

Screen shot 2011-05-03 at 23.11.21

So lets start with showing the routing table on R1

Screen shot 2011-05-03 at 23.03.55

So we see that there are 3 networks listed 1.0.0.0/32 is the loopback0 interface and the other two are the Fast Ethernet ports. Each interface is listed as code ‘C’ which means connected (Juniper call this ‘direct’). If we try to ping the remote loopback interface on R4 we get a fail because R4 doesn’t know how to get to the R4 network of 4.4.4.4/32.

Screen shot 2011-05-03 at 23.18.29

Simple enough so far and hopefully no worries.

So we want to get to google.com and in our wisdom we’ve put into two links to the internet. We’re going to use the link between R1 and R2 as ‘way out’ and we’re going to trust that R2 knows how to get to google.com. Lets put in our default route now, point it at R2.

Screen shot 2011-05-03 at 23.20.49

The first command we put in adds the default route. The IP address of 0.0.0.0 and netmask of all zeros means any IP address basically. It can sometimes be shown as 0.0.0.0/0. The last IP address is the address of the next hop from us. R1 has a connected network link between it’s Fa0/0 interface and R2 using network 10.1.12.0/24. R2’s IP address on this link is 10.1.12.2 so we point our defaultroute at that.

The result of the ‘show ip route’ now has a new route at the bottom prefaced with the code of ’S*’ which means a static route. So now we have a defaultroute pointing at the next hop on R2. R2 knows how to get to the Lo0 interface of R4...lets try a ping now.

Screen shot 2011-05-03 at 23.28.35
  • Great stuff we did it - we can now ping - lets see the path we took.
Screen shot 2011-05-03 at 23.30.13

So, as we know our packets went via R2. But hey you’ve bought two uplinks to the internet, one via R2 and one via R3...can we have two default routes? Well if your have one ISP and two uplinks to that ISP then the answer is yes. If you have two uplinks but are using different ISP’s on each link then the answer is a vague maybe and we’re not getting into the reasons why here.

So lets add another default route into R1 via R3.
Screen shot 2011-05-03 at 23.32.23

This time the ‘show ip route’ has two lines under 0.0.0.0/0. This is IOS telling you there are two equal cost routes to the destination. This means your packets can take either way to get there. We do a traceroute...

Screen shot 2011-05-03 at 23.34.17

Check out how the ICMP packets are telling us that sometime the first hop is 10.1.13.3 then 10.1.12.2? This is your packets being ‘load balanced’ in a round robin way. The second hop is either the network between R3 and R4 10.1.34.4 or the network between R2 and R4 10.1.24.4. Perfect. Just what we wanted...right? So what happens no if the link between R1 and R3 fails...we’ll administratively shutdown the interface for the demo.

Screen shot 2011-05-03 at 23.37.12
Screen shot 2011-05-03 at 23.37.34

Now lets ping the R4 loopback0 interface. What has happened now is that every other packet is failing to get to the 4.4.4.4 address. Thats because we effectively load balanced the traffic and now one of those links is down...hence the loss.

Screen shot 2011-05-03 at 23.42.56

So what can we do? Well in most cases you wouldn’t use static routes you’d be using dynamic routing protocols, some sort of first hop redundancy protocol and certainly be tracking upstream connectivity to failover and load balance properly but we’ll leave that for another time. For our brief demo we’ll concentrate on weighted static routes sometimes called ‘floating static routes’.

Floating static routes allow you to put a ‘primary route’ into the table but in situations where that route is no longer available a second route with a higher metric can be brought into service. Here we’re testing everything is good...and we’ve brought the link between R1 and R3 back up for this.

Screen shot 2011-05-03 at 23.47.38

The second configuration command basically takes out with a ‘no’ the second load balanced default route to R4 via R3. So now lets see the routing table...

Screen shot 2011-05-03 at 23.48.57

Ok you can see we’ve got one route now via 10.1.12.2. Lets add in our floating static route. Now by default a static route to a next hop gets a metric of 1. You can see the metric in the above ‘show ip route’ as the [1/0] after the route 0.0.0.0/0. We’ll add a ‘floating’ route with a metric of 200 but it can be anything between 2 and 255.

Screen shot 2011-05-03 at 23.50.42

So the route is in but crucially you WON’T see this in the routing table. It will still look like it did before we added the floating route...see...

Screen shot 2011-05-03 at 23.51.12

The floating route is only used when the lower metric route is lost from the table. To demonstrate it we’ll shutdown the interface on R1 connected to the link between R1 and R2.

Screen shot 2011-05-03 at 23.52.47

Check out the ‘show ip route’ now. You see that the defaultroute now points to 10.1.13.3 which before was not shown. R1 has realised that the next hop of the previous route is no longer valid so it drops that route from the table. The new defaultroute has a metric of 200 which is what we configured earlier. job done.

Thanks for reading.
View Comments
Here is the basic topology.

R1 and R3 are connected using port FastEthernet0/0
R1 and R2 are connected using port FastEthernet0/6
R2 and R3 are connected using port FastEthernet0/12

Screen shot 2011-04-20 at 22.14.15

Lets create a new VLAN 100 on each ‘switch’

Screen shot 2011-04-20 at 22.19.53

So now lets run through all the switches setting up each connected port as a trunk. We don’t need to set the encapsulation since these only support 802.1q but we’ll do it anyway...

Screen shot 2011-04-20 at 22.22.33

When all the ports are up lets wait for spanning-tree to converge.

Screen shot 2011-04-20 at 22.25.37

On R3 the port FastEthernet0/12 is ‘blocking’.

Screen shot 2011-04-20 at 22.26.03

So let’s move the blocked port to R2’s FastEthernet0/12 interface. To do that we need to make the cost of ‘getting’ to R3 easier than getting to R2. So lets lower the port cost on the interface closest to the root switch.

Screen shot 2011-04-20 at 22.59.02


The default port cost for FastEthernet is 19 so a cost of 1 is preferred. Now looking at R2 we’ve got the result we wanted.

Screen shot 2011-04-20 at 22.59.30
View Comments
A simple yet effective way to manage remote service dependancies is with IP SLA.

Imagine you have two routers connected to one ISP, behind those routers you have a shared ethernet LAN in which you have a firewall. The ISP offers you eBGP services and you receive a full routing table from them into each of your CPE routers. Your CPE facing LAN is configured over ethernet and you are running VRRP between your two routers and the firewall in this LAN (212.1.30.0/24). Devices in the CPE LAN all point to the VRRP virtual IP address for service to the Internet.

Screen shot 2011-04-13 at 20.59.09

So, everything is great, VRRP is up and running as master on RouterA. Now you’ve been extra sensible and setup VRRP to ‘track’ an object on each router to preference the VRRP master device. In our case we are tracking object 1, the object is looking for route 1.2.3.4/32 in the routing table.

Screen shot 2011-04-13 at 21.08.53

If the route exists then our priority s the default VRRP priority of 100 however if the route is lost we decrement by 10 and RouterB (configured with a priority of 95 and to preempt) takes over.

Screen shot 2011-04-13 at 21.08.22

You figure if the eBGP neighbor goes down you’ll lose the routing table so you be able to get out into the internet so you should maybe fail over the VRRP address to the other node (hopefully he’s got a full routing table).

Now, what happens if there is a problem on the ISP network so you are receiving a full routing table into both of the routers and yet behind one of the PE routers there is no upstream service and your data is being blackholed there. This is bad. Your VRRP service does NOT fail over because it was tracking a local route and the provider eBGP neighbor is still sending you a full table. Without manual intervention you are out of service.

So this is where ‘ip sla’ takes over. Cisco ip sla stands for IP Service Level Agreements and is used to provide telemetry information about service availability and capability for a number of network streams such as FTP, HTTP, Voice Jitter.

First lets setup a simple SLA object. For this example we’ll do an HTTP GET request against the http://www.defaultroute.co.uk website but htere are a number of different types of SLA (Jitter, ping,FTP etc). The response time from the site will be a deterministic value for GOOD or BAD status. Clearly a DOWN website might be for reasons other than a lost route but it’s just an example.

Screen shot 2011-04-13 at 21.13.44

Lets check to see if it’s running

Screen shot 2011-04-13 at 21.16.35

Looks good. We’re getting a round trip time (RTT) of 5060ms, the DNS lookup is around 52ms. The return code is OK which is what we are looking for. So now we’ll bind this sla monitor to a track object so we can add it to the VRRP tracking.

Screen shot 2011-04-13 at 21.13.35

Lets confirm thats in

Screen shot 2011-04-13 at 21.13.13

So now we’ll add the new track object to theVRRP configuration and we’ll add another 10 to the increment. So now the outcome of losing the route AND connectivity to the web server will reduce the value to 80. However the key here is that losing connectivity to the monitored web server OR the existence of the route to 1.2.3.4/32 will cause the VRRP service to failover.

Screen shot 2011-04-13 at 21.13.24

Job done - experiment and have fun
View Comments
When there is a technical error with the device or you need to troubleshoot a failure the most important thing is time. Recently we were onsite troubleshooting a denial of service attack (DoS) on a web server for a client. They informed us that it had taken place sometime between 22:00 and 22:10 on a certain date. We asked for the web logs and then for the router/firewall logs for the period concerned. We spent time looking though the logs and noticed no commonality with the customers experience and the logs we were looking at. Indeed there appeared to be some difference even with the log files we had been given. For example a very clear HTTP GET request on the web server had no matching event on the firewall...

You guessed it, not only was the time wrong on the web server but it was also wrong on the firewall. Worse still the timezone was wrong so even if the time setting was correct we were at best an hour out as we were operating in BST.

Setting the time on the web server to point to the cisco switch (Catalyst 4500) to obtain it’s time was the first stage. The timezone was setup correctly and we were to use the windows time service using NTP. Here are the steps we took to setup the Cisco switch to set it’s timezone, to setup the correct British Summer Time skew plus the NTP daemon function so that the Cisco device to collect the correct time information from the internet and also allow the windows server to collect the time information.

First we setup the timezone so that the switch knew where in the world it was:

Screen shot 2011-04-10 at 21.24.37

Now we need to setup the NTP daemon itself. We need to find an NTP source out there to deal with us. There are different tiers of NTP service called ‘strata’. We don’t really need to be hugely accurate so we chose a stratum 2 NTP source. Here are a list of the UK NTP servers we used.

Screen shot 2011-04-10 at 21.28.18

The prefer keyword is just to say to IOS “if this one is available then we’d like you to trust this one most”. We also want to make sure our log data on the switch is given a timestamp.

Screen shot 2011-04-10 at 21.24.47

So lets just make sure it’s all working. Type “show ntp associations”

Screen shot 2011-04-10 at 21.25.16
View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.