The answer to the last question of the day “By default, what versions of updates does RIP send and receive?” is that RIP sends v1 and receives v1 and v2 by default. RIP v1 is able to process RIP v2 updates by simply ignoring the v2 specific fields.
Here is the output of a “show ip protocol” command with a default RIP setup. Notice the bold part where it shows what versions are being sent and received.
Router#show ip prot
Routing Protocol is “rip”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 8 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain
FastEthernet0/0 1 1 2
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
2.0.0.0
Routing Information Sources:
Gateway Distance Last Update
2.0.0.1 120 00:00:23
Distance: (default is 120)
If you want to prevent RIP v1 from processing v2 updates, issue the “version 1″ command under the routing process. That will limit RIP to only sending and receiving v1 updates.
I ran across an article quite a while back talking about being to move from the current running config to another configurations without a switch/router reload. This can definitely be a big time/bacon saver at work and in your lab. The command used is…
Router#configure replace (config location)
So if you wanted to revert back to the start config, you would enter “configure replace nvram:startup-config”. But you could also replace the running config with a config file on the bootflash or from a TFTP server. There are plenty of options.
If you are thinking that you could just do a “copy start run” command, that doesn’t quite do it. What that will do is add all of the start config commands to your running config. But it won’t remove any commands from the running config. So it’s like it melds the two together.
Personally, I like using this in my home lab. If any of you have 2600 series routers, you know how long they take to reboot. I saw one blogger joke that they take 2600 seconds to reload. It’s not quite that bad, but it feels that way some times. Using this command, you can forgo the reboot and get back to a clean config in not much time at all. Of course this won’t do the trick in every situation. Some things require a reboot in order to reset. But it can be a nice option in the toolbox.
Here is a link to the article if you’d like to take a look for yourself.
I went and scheduled my written exam today for next Thursday. I wanted to get it in before the new changes go into effect. On Feb 17 the written test changes so that the scoring uses the same method as all of the other Cisco exams, and you lose the ability to go back to previous questions. I don’t think the scoring change will be a big deal, but being able to go back to previous questions is a big help. Sometimes later questions may help you answer earlier questions.
It’s not that I want to wuss out and take the easy path. But when compared to the lab, the written test seems like more of a formality. I think most would agree that the lab is the true measure of your skills. Plus there’s $350 on the line, which is nothing to sneeze at. So I’ll take whatever advantages that I can get (within the rules of course).
The answer to yesterday’s question “When configuring a RIP enabled interface as a passive interface, what is the end result?” is RIP will not send updates. This is something unique to RIP. You can stop RIP from sending updates on an interface with the passive-interface command. But there aren’t any commands designed to prevent RIP from receiving and processing updates on a RIP enabled interface.
There are a few methods that you can use on a router to stop RIP from processing the updates. You could use different methods for filtering the routes. You could block RIP traffic with an access list. You could enable authentication on the interface. One other option would be to use an offset list to poison the routes (push the metric to 16+). Depending on the requirements of your lab, some options will work better than others.
Sorry for the delay in these. I was out of town last week and trying to catch up from that over the past few days. The answer to the last question, “Which of the RIP timers in IOS is Cisco proprietary?” is the Holddown timer. That is not in the RFC for RIP.
In retrospect, I don’t know that the timer is Cisco proprietary. But it is not industry standard. If you get a request in the lab to configure RIP timers to match industry standards or the RFC, then use the following command under the “router rip” process.
I’m sitting in my hotel in Austin TX right now with the air conditioner going. I went from -25 temperatures just a few days ago in Minnesota to 75 degree weather in Texas. That’s a nice 100 degree swing over the course of a few days. My next question of the day should be, why in the world do I live in MN?
I’ll be in training all week. Unfortunately it’s not networking related. So I’m not quite sure how much blogging I’ll get to. Unfortunately, I probably won’t get much labbing in. But I do plan on trying to get some good reading in. I got through 3 chapters of Routing TCP/IP vol 1 on the plane ride. Hopefully I can fire up GNS3 and get some practice in sometime as well.
For now, I’m going to enjoy the fact that my hotel has free booze 2 hours a day in the evening and a nice omelet bar in the morning.
The answer to yesterday’s question (When using policy based routing on an interface, in what direction is the policy applied?) is on inbound traffic. When using policy routing on interfaces, IOS will only act on inbound traffic. Think about it this way… in order to send traffic out an interface, a routing decision needs to be made. So once the traffic is sent to the outgoing interface, routing is already done. So policy routing couldn’t really do anything at that point.
I know I’m late to the party here, but I thought that I would share my take on the recent announcements.
On the written test, I can understand why they are making the changes. Now it’ll match up with the rest of the Cisco certification exams out there. It doesn’t sound like they are changing the questions. But the grading will become nebulous with the large score range. I would also assume the questions will be weighted when it comes to scoring. Also, you can no longer skip questions and come back to them. Overall, this will raise the difficulty a little bit. So I’ll definitely be trying to get my written test in before the change happens in February.
The interview on the Lab exam is an interesting change. I think Cisco could have done a better job of explaining it though. Obviously, this sends a bit of anxiety to the CCIE candidates out there (myself included). From the sound of things, it won’t do anything to increase your chances of passing the lab. So it becomes just one more thing that could cause to you spend $1400 on a mediocre lunch. Plus there is the issue of subjectivity along with language problems where English is not the candidates primary language.
I think Cisco could do a lot to ease our worries by just giving a few examples of the questions along with acceptable answers. Not knowing is really what the problem is right now. It’s hard to prepare or be confident when going into the unknown. In the end, I’m guessing that this won’t be a big deal for the candidates who aren’t trying to pass the lab though brain dumps or brute force.
I guess as long as the changes accomplish their goals, it’s a good thing. I definitely want to keep the riff raff out of the CCIE club. It’ll be interesting to hear reports from candidates once they start encountering the new changes.
Sorry for missing a few days. I was out of town for a little while.
The answer to yesterday’s question (How are DLCIs assigned to point-to-point frame relay interfaces?) is With a “frame-relay interface-dlci” command. The point-to-point sub interfaces will not accept a “frame-relay map” command. If you try using it, you’ll get this message.
Only frame-relay interface-dlci command should beused on point-to-point interfaces not frame-relay map
Also, when DLCIs are learned on an interface, they are applied to the physical interface by default. Sub-interfaces cannot dynamically have DLCIs applied to them. They need to be manually assigned.
I guess the polls only allow a certain number of characters. The answer to yesterday’s question, which was supposed to be “In frame relay, can inverse ARP be used on a physical or multipoint interface to learn layer 3 to layer 2 mappings if the other end of the PVC is a point-to-point subinterface?” is Yes.
In frame relay, point-to-point interfaces to not initiate LMI communications. But they will respond to them. So the physical or multipoint interface will send an LMI request that will be responded to by the point-to-point interface, allowing the layer 3 to layer 2 mapping to be learned.
