Every now and then I feel the need to write a very basic article, explaining the foundations and getting the terminology straight. Today I’m trying to explain the control and data planes in a router (or a layer-3 switch, depending on your marketing bias). Your opinions, fixes, corrections and all other comments are most welcome.
Update: This challenge is closed, see the final results (November 4th 2008).
Assuming you have the following configurations on R1 and R2:
hostname R1 ! interface Loopback 0 ip address 10.0.0.1 255.255.255.255 ! interface Serial 0 encapsulation ppp ip unnumbered Loopback0 ip ospf 1 area 1 ! router ospf 1
hostname R2 ! interface Serial 0 encapsulation ppp ip address 10.1.2.3 255.255.255.248 ip ospf 1 area 1 ! router ospf 1
What IP address can you use on the loopback interface of R1 to establish adjacency between R1 and R2? Can you use more than one IP address?
This challenge was triggered by a comment uri wrote on the “OSPF ignores subnet mask mismatch on point-to-point links” post, claiming that you cannot mix numbered and unnumbered interfaces in OSPF.
I’ve received several e-mails responding to the mismatched OSPF subnet challenge. Some of the readers claimed that the configuration would work as-is; if you were one of them, I would advise you do some lab test the next time. A few of the respondents also noted that it was more a review question than a challenge (since I’ve been writing about this topic a few days back) and everyone who decided the configuration has to be fixed has provided the correct solution: you have to configure the Fast Ethernet as a point-to-point OSPF interface and the routers stop complaining about the OSPF subnet mask mismatch.
Unfortunately, someone decided to prevent everyone else from having real fun figuring out the solution and posted the solution as a comment to my post almost immediately after I wrote it (but I’m positive that those readers that sent me e-mails did not read that comment first). Lesson learned: the next time I’ll disable comments in the challenges.
One of the comments I’ve received after writing the “Knowledge or recipes” post was an interesting observation: “maybe the associate-level students need more recipes than knowledge”. I somewhat agreed with that thought, but still wanted to sort out the definition of an “associate” (English is not my native language, so I have no “natural” presumptions about certain concepts). My research turned out some interesting associate-level details.
Read more in Fragments, the official NIL blog
Jeremy Stretch has been extremely active in the CT3 wiki in last few days, writing about OSPF inter-area routing and various aspects of PIM. His articles cover the basics of PIM, principles of PIM dense mode, more detailed overview of PIM sparse mode and a hint what Bidirectional PIM is.
We've been discussing basic OSPF operations in the NIL forum. If you're aware of any good online resource explaining OSPF basics, SPF algorithm, the resulting SPF tree and the OSPF cost calculation, I would appreciate if you could post the link(s); preferably in the forum or as a comment to this post. If it turns out there's nothing really useful (which I doubt) I could write something, but I would rather spend time on more advanced (but probably less popular :) topics.
I've enabled the new "embedded comment form" in Blogger. This should make writing the comments a bit easier ... but Blogger is known to report weird errors every now and then when you're using the embedded form. If that happens to you, just press the "Publish" button yet again (after entering another CAPTCHA if needed). I hope you'll find that the ease-of-use of the new form outweighs the occasional hiccups (and I won't even try to open a case with Google about this).
A while ago I've got an interesting question from one of the readers:
I'd like to be able to configure a set of routers to only be manageable from each other. Something like an access-class matching minimum packet TTL would probably be good enough, better if some connected routes could be tagged and access granted based on that. The idea is to keep router-by-router logins in case of routing problems, without opening up access too widely.
I did a few tests with IOS release 12.4(15)T and neither access-class nor control-plane policing recognizes the TTL field in ACL (various bits and pieces of IOS use the same data structures in different procedures, thus resulting in inconsistent behavior). Alternatively, you could deploy inbound access lists on all interfaces, but this is probably way too cumbersome to manage.
The best you can do without going into weird solutions is to allocate router loopback interfaces and inter-router links from a tightly controlled address space and only allow telnet from that address space (while at the same time filtering IP packets pretending to come from that same address space on the perimeter of your network). As the IOS supports extended access lists in the access-class line configuration command, you could allow SSH from a wider set of IP addresses and limit Telnet to the address range allocated to inter-router links.
In the “Trend is your Friend” post, Andraz Piletic describes how you can use long-term monitoring offered by NIL Monitor Service Management to discover the otherwise well-hidden trends. The graph in the post comes from an actual router; you can clearly see a very slow memory leak, which would be very hard to spot using the show commands.
Read more in Fragments, the official NIL blog
Tags: network management
Someone recently asked me how to get the physical location of an IP address. One of the better (free) services available on the Internet is the IP2Location (demo) service.
This feature might come handy if you're trying to figure out who's attacking your application servers (when the TCP session has already been established). Denial-of-service attacks commonly use fake source IP addresses.
Tags: network management
The assignment of router’s interfaces into OSPF areas should be a non-issue these days, but for whatever reason some of the students I’m mentoring still use the ridiculous practice that was promoted in older learning materials: a separate network statement using IP subnet and inverse subnet mask for every single interface. I’ve documented what I consider to be best practices in the “OSPF area configuration best practices” article in the CT3 wiki. If you disagree with my opinion, please feel free to edit my article or share your thoughts in a comment to this post.
The “Certifications/Experience/Knowledge” posts by Greg Ferro reminded me of the ages-old question: “What's the best way to gain knowledge?” Once I read an excellent opinion arguing that the classroom training is nothing else than (fancier) learning-by-the-campfire method ingrained in our genes, but since ancient civilizations invented writing, some of us prefer reading over listening ... but your preferences might be completely different. I've summarized my personal view on this subject in the “Gaining Knowledge - what’s the best way to do it?” article I wrote in NIL's blog.
Read more in Fragments, the official NIL blog.
Update: This challenge is closed, see the final results (October 29th 2008).
You could get something like this only in a CCIE lab (I would hope): R1 and R2 should establish OSPF adjacency, but you cannot change or remove any of the existing configuration commands (you can add new commands).
hostname R1 ! interface FastEthernet 0/0 ip address 192.168.1.17 → 255.255.255.0 ip ospf 1 area 1 ! router ospf 1
hostname R1 ! interface FastEthernet 0/0 ip address 192.168.1.18 → 255.255.255.252 ip ospf 1 area 1 ! router ospf 1
Our remote lab team was very pleased with the readers who tested the IINS remote lab exercises two weeks ago. This week they're offering free access to IIUC remote lab exercises (IIUC is the recommended course for the CCNA Voice exam).
A while ago cciepursuit described his problems with PPP-over-Frame Relay. Very probably his problems were caused by a static IP address assigned to the virtual template interface (this address gets cloned to all virtual access interfaces and IOS allows you to have the same IP address on multiple WAN point-to-point links). I recreated very similar (obviously seriously broken) scenario in my lab using point-to-point subinterfaces over Frame Relay to simplify the setup.
This is not something you’d want to do in your production network.
The relevant parts of router configurations are included below:
S1#show run | section interface Serial interface Serial1/0 no ip address encapsulation frame-relay ! interface Serial1/0.100 point-to-point description Link to C1 ip address 10.0.8.2 255.255.255.240 frame-relay interface-dlci 100 S2#show run | section interface Serial interface Serial1/0 no ip address encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial1/0.100 point-to-point description Link to C1 ip address 10.0.8.3 255.255.255.240 frame-relay interface-dlci 100 C1#show run | section interface Serial interface Serial1/0 no ip address encapsulation frame-relay ! interface Serial1/0.100 point-to-point description Link to S1 ip address 10.0.8.1 255.255.255.240 frame-relay interface-dlci 100 ! interface Serial1/0.101 point-to-point description Link to S2 ip address 10.0.8.1 255.255.255.240 frame-relay interface-dlci 101
I expected the distance vector protocols to work flawlessly, as they track the next-hop as well as inbound interface over which the routing update was received. With the following RIP configuration on all three routers …
router rip version 2 network 10.0.0.0 no auto-summary
… the routing table on C1 looked almost OK, apart from the weird entry for the 10.0.8.0/28 subnet:
C1#show ip route | begin Gateway Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks C 10.0.8.0/28 is directly connected, Serial1/0.100 is directly connected, Serial1/0.101 R 10.0.0.2/32 [120/1] via 10.0.8.3, 00:00:01, Serial1/0.101 C 10.0.0.3/32 is directly connected, Loopback0 R 10.0.0.1/32 [120/1] via 10.0.8.2, 00:00:02, Serial1/0.100
The next routing protocol was EIGRP; configuration was very similar to the RIP case:
router eigrp 1 network 10.0.0.0 no auto-summary
Yet again, the IP routing table looks as expected:
C1#show ip route | begin Gateway Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.0.8.0/28 is directly connected, Serial1/0.100 is directly connected, Serial1/0.101 D 10.0.0.2/32 [90/2297856] via 10.0.8.3, 00:02:33, Serial1/0.101 C 10.0.0.3/32 is directly connected, Loopback0 D 10.0.0.1/32 [90/2297856] via 10.0.8.2, 00:02:33, Serial1/0.100
OSPF also behaved as expected, producing weird results. I never got both remote routes in the IP routing table on C1; one of them (or even both of them) was missing. This is not surprising; OSPF builds the SPF tree from the topology database and gets totally confused when two interfaces have the same IP address.
The information in the topology database is correct; in my lab, C1 advertised that it can reach S1 and S2 (both of them appeared as router-to-router links in the router LSA) …
C1#show ip ospf database router self-originate OSPF Router with ID (10.0.0.3) (Process ID 2) Router Link States (Area 1) LS age: 283 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 10.0.0.3 Advertising Router: 10.0.0.3 Number of Links: 5 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.0.3 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.2 (Link Data) Router Interface address: 10.0.8.1 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.8.0 (Link Data) Network Mask: 255.255.255.240 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.1 (Link Data) Router Interface address: 10.0.8.1 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.8.0 (Link Data) Network Mask: 255.255.255.240 Number of TOS metrics: 0 TOS 0 Metrics: 64
… but OSPF got totally confused when trying to build the SPF tree, deciding that one (or both) of remote routers was unreachable:
C1#show ip ospf database router adv-router 10.0.0.1 OSPF Router with ID (10.0.0.3) (Process ID 2) Router Link States (Area 1) Adv Router is not-reachable LS age: 356 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 10.0.0.1 Advertising Router: 10.0.0.1 Number of Links: 3 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.3 (Link Data) Router Interface address: 10.0.8.2 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.8.0 (Link Data) Network Mask: 255.255.255.240 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.0.1 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1
In my humble opinion, IOS could do better (the topology table has enough information to build the correct SPF tree), but this is a nonetheless a broken design that a router should never be exposed to.
Summary: Virtual template interfaces should be unnumbered to prevent address overlap on virtual access interfaces. If you insist on using a fixed IP address on virtual template interfaces, don’t expect OSPF to work.
The common wisdom says that the subnet mask mismatch will stop the OSPF adjacency from forming (I’ve included a sample debugging printout in yesterday’s post). In reality, the subnet mask is checked only on the multi-access interfaces and is ignored on point-to-point links. The source of this seemingly weird behavior is Section 10.5 of RFC 2328 which says:
The generic input processing of OSPF packets will have checked the validity of the IP header and the OSPF packet header. Next, the values of the Network Mask, HelloInterval, and RouterDeadInterval fields in the received Hello packet must be checked against the values configured for the receiving interface. Any mismatch causes processing to stop and the packet to be dropped. In other words, the above fields are really describing the attached network's configuration. However, there is one exception to the above rule: on point-to-point networks and on virtual links, the Network Mask in the received Hello Packet should be ignored.
Cisco conforms strictly to the RFC and allows OSPF neighbors to form adjacency over a point-to-point link (Frame Relay subinterface in my test lab) even when the subnet masks don't match. The routers in the lab happily formed the OSPF adjacency even though I've used a /24 mask on one end of the link and a /30 mask on the other end:
S1#show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Se1/0.100 1 1 10.0.8.1/24 64 P2P 1/1 Lo0 1 1 10.0.0.1/32 1 LOOP 0/0 S1#show ip ospf neighbor Serial1/0.100 Neighbor ID Pri State Dead Time Address Interface 10.0.0.11 0 FULL/ - 00:00:38 10.0.8.2 Serial1/0.100 C1#show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Fa0/0 1 0 10.0.1.1/24 10 BDR 1/1 Lo0 1 0 10.0.0.11/32 1 LOOP 0/0 Se1/0.100 1 1 10.0.8.2/30 64 P2P 1/1 Se1/0.101 1 1 0.0.0.0/0 64 P2P 1/1 C1#show ip ospf neighbor Serial1/0.100 Neighbor ID Pri State Dead Time Address Interface 10.0.2.2 0 FULL/ - 00:00:37 10.0.8.1 Serial1/0.100
This behavior was brought to my attention by Shahid Rox. Thanks.
Troubleshooting OSPF adjacencies can be a nightmare: if you’ve misconfigured the OSPF interface parameters (the timers or the subnet mask), the adjacency will not form, but the router will not tell you why. The only mechanism you can use to detect the mismatch is the debug ip ospf hello command … just don’t try to use it on a console session of a router running OSPF across hundreds of interfaces.
The OSPF hello event debugging does not display OSPF packets received from a different subnet. If you configure mismatched IP subnets (not the subnet mask) on adjacent routers, you will not see any received hello packets.
To limit the debugging outputs to a single interface, use the debug interface command.
For example, in my test network, the routers did not want to establish adjacency on the Fast Ethernet interface:
C1#show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Fa0/0 1 0 10.0.1.1/25 10 DR 0/0 Lo0 1 0 10.0.0.11/32 1 LOOP 0/0 Se1/0.101 1 1 0.0.0.0/0 64 P2P 1/1 Se1/0.100 1 1 0.0.0.0/0 64 P2P 1/1 C1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 0 FULL/ - 00:00:38 10.0.0.2 Serial1/0.101 10.0.2.2 0 FULL/ - 00:00:36 10.0.0.1 Serial1/0.100
Using the OSPF hello debugging limited to Fast Ethernet interface I quickly discovered the source of the problem: the subnet mask mismatch between the adjacent routers.
C1#debug interface FastEthernet 0/0 Condition 1 set C1#debug ip ospf hello OSPF hello events debugging is on C1# OSPF: Rcv hello from 10.0.0.12 area 0 from FastEthernet0/0 10.0.1.2 OSPF: Mismatched hello parameters from 10.0.1.2 OSPF: Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.0 C 255.255.255.128
We had parliamentary elections in Slovenia recently; no wonder my post about quality in training (and what you can do about it) is slightly biased. But the point remains the same: in the world of Web 2.0, there’s no reason we should let vendors get away with mediocre delivery.
Read more in Fragments, the official NIL blog.
I’m constantly receiving interesting OSPF-related queries. Obviously the many hidden details of the OSPF specs result in slightly unexpected behavior and constant amazement of engineers studying OSPF. During this week, I’ll focus on a few interesting OSPF intricacies.
Let’s start with an easy one: I’ve already described how you can use the show ip ospf interface brief command if you want to display the OSPF interface status (including the interface area, OSPF cost, link type and router status on broadcast links). Unfortunately, this command does not allow you to specify the OSPF process ID and displays interfaces belonging to all OSPF processes (if you run multiple OSPF processes on the router).
Here is a sample printout taken from a router running OSPF processes #2 and #13:
C1#show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Lo102 2 22 10.2.2.2/32 1 LOOP 0/0 Fa0/0 13 0 10.0.1.1/24 10 BDR 1/1 Lo0 13 0 10.0.0.11/32 1 LOOP 0/0 Se1/0.101 13 1 0.0.0.0/0 64 P2P 1/1 Se1/0.100 13 1 0.0.0.0/0 64 P2P 1/1
You can use an output filter to display the interfaces belonging to a single OSPF process. The filter is quite convoluted …
C1#show ip ospf interface brief | include ^[^ ]+ +13 Fa0/0 13 0 10.0.1.1/24 10 BDR 1/1 Lo0 13 0 10.0.0.11/32 1 LOOP 0/0 Se1/0.101 13 1 0.0.0.0/0 64 P2P 1/1 Se1/0.100 13 1 0.0.0.0/0 64 P2P 1/1
… and works like this:
- The initial caret (^) matches the beginning of the line, ensuring that our filter will match exactly what it needs to match. Without the initial caret, the filter could generate a match anywhere in the line, potentially resulting in false positives.
- The [^ ]+ pattern matches any non-empty (the + sign) string of non-space characters (the [^ ] expression matches anything but the whitespace). This part of the pattern matches the interface name.
- The + pattern matches the string of spaces between the interface name and the process ID.
- The final part of the pattern (13) matches the OSPF process ID.
You can transform this complex output filter into an easy Tcl script. See the “Simple extensions to exec-mode CLI” and “Simple CLI extensions: handling special characters” posts.
- Greg Ferro published some great thoughts on certifications versus experience. While a lot of people tend to disagree with him (at least a bit ... myself included), he has some very good points.
- Joe Harris posted the "IOS order of operation" list. Unfortunately it looks incorrect; I'm positive that in some cases NAT looks at the packet (and creates the translation) even if the inbound ACL drops it.
- Anyone who has ever been involved in security must read Security Maxims from Roger Johnston (hat tip to Bruce Schneier).
- I got promoted to holy cows. At least I have good company. BTW, if you're concerned about the security of your switch configuration, check what NSA has to say about it.
- Thinking problem management has a great post explaining why you need service documentation.
- Ethan Banks is back and writes about RGEs (Resume Generating Events).
- Anthony Sequeira writes about transparent firewall on ASA/PIX.
I've got a simple question recently: “Can I run MPLS on a VLAN interface on 7600?” My initial response was “Sure, why not.”, as I knew we've deployed MPLS in 7600-based networks and there should be no significant difference between a routed port and a VLAN interface on a 7600 (this box treats everything as a VLAN internally).
It turned out the problem was "a small detail" that's not advertised in any 7600-related MPLS marketing material on Cisco web site: you need Advanced IP Services software to run MPLS. To make matters worse, the only mention of 7600-series devices in the Cisco IOS Packaging Product Bulletin I've finally found within the 7600 routers product literature is in the first marketing slide.
My "IP QoS: Two generations of class-of-service tools" article published by SearchTelecom gives you a very high-level overview of IntServ and DiffServ approaches to IP QoS as well as brief description of various DiffServ tools.
Once upon a time, AAA command authorization in Cisco IOS queried the TACACS+ server for every single command a user entered. Rules have changed drastically in the meantime (at least for IOS release 12.4):
- Non-privileged show commands are executed without TACACS+ authorization. Privileged show commands (show running or show archive log config) are still authorized.
- Some commands that can be executed in non-privileged (aka disable) mode (enable, disable, help, logout) are authorized only if you configure aaa authorization commands 0 methods regardless of the current privilege level.
- Other commands (for example, ping) are authorized based on the current privilege level.
For example, if you’ve configured AAA command authorization only for privilege level 15, the ping command will be authorized if you’re working in enable mode, but not otherwise.
- Command authorization is not performed on console unless you’ve configured aaa authorization console.
This is the sample configuration I’ve used to run the tests with IOS release 12.4(19):
aaa new-model ! ! aaa authentication login default local aaa authorization exec default group tacacs+ if-authenticated aaa authorization commands 0 default group tacacs+ none aaa authorization commands 15 default group tacacs+ none ! username x password y ! tacacs-server host 192.168.200.201
When configuring MPLS Traffic Engineering in your network, you have to specify the amount of bandwidth that the MPLS TE tunnels can request on each MPLS TE-enabled interface with the ip rsvp bandwidth command.
Until recently, this command accepted only fixed bandwidth (in kilobits), which could be pretty inconvenient if you wanted to use common interface templates or deployed MPLS TE on links with varying bandwidth (for example, Multilink PPP bundles). IOS release 12.2SRC introduced a variant of the same command (ip rsvp bandwidth percentage) that allows you to specify reservable bandwidth as percentage of the current interface bandwidth. Unfortunately this feature didn’t make it into 12.4(20)T.
Today I read your article about scaling EIGRP using stub routers. I was wondering whether you can use the leak map only for routes learned from other EIGRP neighbors? Is it also usable to filter connected routes?Leak-map controls what its name implies: the leakage of routes received from EIGRP neighbors to other EIGRP neighbors. To filter connected prefixes redistributed into EIGRP, use the route-map on redistribute connected command. The only way I've figured out to filter announcements of directly connected networks that are part of the EIGRP process is the distribute-list out command.
In October IP Corner article, Boštjan Šuštar describes one of the most commonly used IPSec design options: GRE tunnels protected with IPSec encryption.
I was stunned when I've figured out my ISP uses PPP-over-Ethernet in FTTH environment. After the initial shock, the solution started to look more promising.
In NIL Forum:
- You'll find a few reasons why you'd want to use BGP in an enterprise network.
- The ip default-network command has risen its ugly head again ... do you agree that this command should be outlawed years ago?
Jeremy Stretch has contributed a number of articles covering BGP aggregation to the CT3 wiki, where you'll also find simple rules for those that want to combine MPLS VPN with MPLS Traffic Engineering.
Our remote lab team has made the Implementing Cisco IOS Network Security remote lab exercises available free-of-charge to ten students. To get access to them, fill in the registration form (and be quick). You'll get access to all 12 IINS remote lab exercises that you can launch until October 12th. The only thing we expect in return is that you actually use them and report your opinion using the "customer satisfaction" surveys that will be mailed to you after each exercise.
The IINS course is the recommended training for the CCNA Security certification.
Let’s conclude the RIP week with an interesting observation made by Yuri Selivanov: when using MD5 authentication with RIP, Cisco routers send 532-byte UDP datagrams while Juniper routers send 512-byte UDP datagrams. The maximum number of route entries (RTE) in a RIP datagram and its size thus varies based on authentication mechanism and router software:
|Authentication type||Cisco IOS||JunOS|
Somehow people expect RIP datagrams to be at most 512 bytes long, which (as you can see from the table) is not always the case.
Obviously I've tried to figure out whether that’s another bug in Cisco IOS (as I’ve reported in the past, the developers sometimes tend to ignore the standards), but it turns out (in my opinion) that the problem lies in ambiguous RFC (RFC 2082 and RFC 4822).
RIP v2 standard (RFC 2453) states that a RIP packet contains at most 25 RTEs and that the authentication uses the first RTE, allowing up to 24 RTEs in the RIP update. RIPv2 cryptographic authentication standard (RFC 4822) uses the information in the first RTE (matching the specs of RFC 2453) and appends variable-length authentication data after the RIP packet.
For MD5 authentication the digest size happens to be 16 bytes; together with the 4-byte header the authentication trailer happens to be 20 bytes, which is equal to RTE size. Juniper developers thus decided to reduce the number of useful RTEs to 23, whereas Cisco developers read the standard more literally. Anyhow, if anyone would care to implement HMAC-SHA1 digest instead of MD5, the authentication data would be 20 byte long, resulting in an 24-byte authentication trailer.
To break this week's RIP monotony (for those that are persuaded RIP should have died long ago :), I've added another Readers' poll (and let's hope Our friends @ Google don't mess it up again), this time focusing on the social networking sites used by networking professionals.
I've joined LinkedIn a while ago and it was a great tool to get back in touch with my friends and business partners, but it has limited features (for example, I would like to get something similar to my About page). I'm also wondering whether to start experimenting with MySpace or Facebook and I want to take in account what you're using, so it will be easier to get in touch (I always hate registering at yet-another-site). So, any experience you are willing to share will be really appreciated.
The moment I wrote “RIP summary routes are not present in the IP routing table” in the RIP Route Database article in the CT3 wiki, I knew it was a recipe for disaster. It’s OK not to advertise what you use (we call this route filters); advertising something you don’t use yourself is slightly stupid.
It didn’t take me long (after I found a few minutes of spare time) to come up with a scenario where RIP interface summary creates a nice routing loop.
Yesterday I’ve introduced a scenario where RIP would (in my opinion) work much better than OSPF. If you were not persuaded by the “management-level” arguments, let’s focus on the technical details (but make sure you read the scenario first).
All you ever want to advertise to the remote sites in this design is the default route (or a network-wide summary). Alternatively, you might want to advertise only a route to a central LAN or server. Both requirements are easily met with RIP per-interface output filters. Doing something similar with OSPF is close to impossible. Either you place every remote site into a separate OSPF area (don’t even think about doing it; there could be hundreds of sites) or the routes within an area will leak between the remote sites.
RIP is also more stable than OSPF in this setup. Whenever a remote site disappears, the change in the OSPF area is unnecessarily propagated to all other remote sites in the same area. RIP doesn’t react at all; the output route filter at the central site stops all unnecessary updates.
As you know, OSPF requires hello packets and adjacencies to work properly. The central hub router must therefore track the adjacency states of hundreds of neighbors. When using RIP, the central router couldn’t care less … it sends out its routes every so often, collects whatever comes back and reports when a new remote route is received or an old one disappears.