This discussion pretty much comes up in every account, be it the new customer of a greenfield network deployment or a long account that you have been looking after for years. Company XYZ, the greenfield network deployment, at the time of writing, is having a heated debate on whether OSPF or ISIS should be deployed in its core network (the decision is more inclined to OSPF; more details will be provided later). A famous ISP's network, on the other hand, has its IPv6 networks completely on ISIS (it is still on OSPF for IPv4).
One of the most highly-pitched argument to choose ISIS over OSPF is the claimed ability of ISIS in hiding the core infrastructure. However, before we proceed further, let's summarize a few well-known as well as the less well-known "pros and cons" of both IGPs.
Some history and revision on some important facts of both OSPF and ISIS
ISIS is exactly the same as OSPF only completely different. This famous phrase pretty much sums up the relationship between the two IGPs. As revising the two IGPs in depth is not the purpose of this newsletter, we will just go through some development history and also revise some of the easy-to-forget facts of both IGPs.
Development History
* [history #1] Development work started for OSPF and Integrated/dual-ISIS (TCP/IP implementation) at almost the same time (1988-1989)
* [history #2] Both protocols are recognizably similar in mechanism and function (given common heritage)
* [history #3] OSPF was designed from the start as an IP routing protocol whereas ISIS was focused on OSI
Revision Points
* [revision #1] ISIS only supports Broadcast and P2P links (OSPF has 3 more options, P2MP, NBMA, Demand Circuit)
* [revision #2] ISIS area boundaries fall on links (a router can be only in one area) while OSPF area boundaries fall within a router
* [revision #3] Backbone must be contiguous in both OSPF and ISIS
* [revision #4] There is no BDR in ISIS
* [revision #5] DR can be preempted in ISIS (hence causing temporary instability) but not OSPF
* [revision #6] Non-IP nature makes ISIS inherently more secure; OSPF is more subject to spoofing and other attacks
* [revision #7] The original design of ISIS was optimized for large LANs (periodic synchronization, simple LAN flooding) and SPF computation performance (small metrics)
* [revision #8] OSPF was optimized for efficient bandwidth utilization and reliability
* [revision #9] All PDUs in ISIS are extensible but only LSAs are extensible in OSPF
Note: #7, #8 are now rendered obsolete due to the high-speed routing technology
Revision #9 brings up an interesting point: since S-IS is neutral regarding the type of network addresses for which it can route, it was easily adapted to support IPv6. On the other hand, OSPF was designed specifically for IPv4 and hence it needed a major overhaul to support IPv6(OSPFv3). Precisely speaking, OSPFv2 could have been extended for IPv6 but it was not because a major overhaul seemed more practical. Bear in mind that the development of OSPF began at the time when router performance was low, latency was high, memory was expensive and several characteristics of OSPFv2 that were intended to accommodate/compensate for those early networking realities are now irrelevant. Furthermore, extensive operational experience with OSPFv2 also revealed several areas of inefficiency.The result, when extension of OSPF to support IPv6 (using opaque LSAs) was first considered, it was recognized that there was an opportunity to improve the protocol itself and hence creating a new and improved version of OSPFv3, makes more sense.
Core-hiding techniques
This is probably what most people would tell you is the absolute reason why you must choose ISIS over OSPF. Yes, undoubtedly ISIS does have a very decent core-hiding technique (note: not exactly designed to hide the core though) but this is not the only way you can hide your core network, to be precise. Also, core-hiding techniques in ISIS (as well as others) come with a few compromises on the ease of network management and operations. It is not as omnipotent as you might expect (ok you can say I am not 100% pro ISIS). The followings are a few frequently used techniques to hide the core network.
[core-hiding technique #1] Deploy private address space in the core: this is a well-known technique as all traffic from the internet would not be able to reach your infrastructure interface addresses. But wait, how about the attack from your customers or attack launched from the PE (not necessary in MPLS/VPN context)? Unless the ISP has a dedicated OOB, you also need to access your network from the internet via some sort of connection, right?
[core-hiding technique #2] Infrastructure ACL: This is probably the most efficient way to protect your core network. Basically, it consists of infrastructure, transit, or anti-spoofing ACLs applied at ingress to your network on all externally facing peering connections and customer connections to explicitly filter traffic destined for infrastructure address space, or that spoof your internal address space. In short, what you need to do is configuring this on the PE: deny ip any , with some exceptions of course. If there is no traffic to the core then there is no way an attack can happen and hence it prevents intrusion 100% and DoS is made extremely hard (only way to launch it is by the way of transit traffic). However, the implementation can be complicated if your core address space is not contiguous or not easily expressed in an ACL. It also shares the common operation/management made difficult issues as all other core-hiding techniques have. Just a side note, do we not see iACL listed ias one of the most effective workarounds in almost all of the PSIRTs published recently?
[core-hiding technique #3] MPLS Core hiding: Again, PE is the only attack point here.
[core-hiding technique #4] Non-IP Control Plane: If CLNS/ISIS is deployed and only loopback interface gets the IP address, then we do not even need to do any filtering to block traffic to the core interface. However, you still need to block traffic to edge interfaces doing peering, upstream or with your customers. Hence, you still need to filter at the edge. Another compromise you have to make is, troubleshooting (e.g ping/traceroute) is made almost impossible directly from/to core devices.
[core-hiding technique #5] Integrated ISIS (or Dual-ISIS):
A lot of people are saying there is this core-hiding command in ISIS which is not available in OSPF. To be precise, the command is never really meant for hiding the core. This command is actually used to speed up ISIS convergence by excluding CONNECTED IP prefixes from LSP advertisements. Note that it does not affect any redistributed prefixes but only connected interface ip prefixes. In the process of speeding up ISIS convergence time by excluding the connected ip prefixes, we achieve the indirect goal of hiding infrastructure addresses.
You might then ask, how are we going to maintain the IGP if all these IP addresses are excluded from LSP advertisements? Well, to make it short, [1] IP prefixes are not sued to build the SPT in ISIS since they are leaves [2] routers are identified through their CLNS System IDs. Don't quite get it? Well let's break it down in more details...
1. ISIS separates the neighbors and the IP addresses information by using IS Neighbors TLVs (or Extended IS Reachability TLVs with wide metrics) and IP Internal/External Reachability Information TLVs (or Extended IP Reachability TLVs with wide metrics)
2. This well engineered data-structure of ISIS has leveraged it huge benefits when it came to Partial SPF calculation, since it was easy for a router to understand whether there is a topology change that needs full SPF calculation, or is it just IP addresses reachability that would just require a partial SPF calculation
3. In most SPs’ backbones the IGP is required to make the loopback IP addresses of the providers’ routers reachable to each other in order to be able to have all the MPLS stuff operational
4. Then why do we need to advertise "useless IP addresses reachability information” by advertising their IP reachability TLVs in the LSPs?
5. By not advertising these infrastructure link addresses (usually /30), virtually overpopulation of routing tables can be avoided and hence the reduction in ISIS convergence time
6. As a result, there is no way you can route to ip addresses that are not in the routing table, right?
7. By doing so, you are hardening your core protection but yet at the same time you compromise on the ease of management and operations (wow I cannot telnet from a P1 router to another remote P3 using P1's link address as src ip..)
So what are the commands that can achieve this fast convergence in ISIS? To remove specific ip address from ISIS database, use the interface-level command “no isis advertise prefix”. This command is more suitable for a small network.
interface Ethernet 0
ip address 192.168.20.1 255.255.255.0
ip router isis
no isis advertise-prefix
:
router isis
passive-interface Loopback0
net 47.0004.004d.0001.0001.0c11.1111.00
ip address 192.168.20.1 255.255.255.0
ip router isis
no isis advertise-prefix
:
router isis
passive-interface Loopback0
net 47.0004.004d.0001.0001.0c11.1111.00
To remove all interface IP addresses from the ISIS database, use "advertise passive only" under router isis configuration level. This is more suitable for large-scale network.
router isis
passive-interface Loopback0
net 47.0004.004d.0001.0001.0c11.1111.00
advertise-passive-only
Remember, you must have "passive-interface loopback0" configured in both cases or else loopback0 will also be gone from your network and hence breaking up everything in the core. If you would like to go into details on how this can be achieved, there is a very detailed lab document by Gregg Schudel that describes the above mechanism in-depth. Please refer the attached file (ISIS_Security_Gregg_Schudel.ppt) and should you have any questions, feel free to email me.
Advantages of ISIS over OSPF: Fuds and Facts
There are several other fuds and facts about why ISIS excels OSPF. Let us go through some of the most commonly seen ones and debunk any myths that sometimes come with them.
[argument #1] The whole core is hidden with this core-hiding technique
Fact: Not entirely...
Remember, direct traceroute from a CE to another will still reveal the link address along the path. Under assumptions that no ACL or any equivalent technology is used, you can still ping the the link addresses that are directly connected to the PE. For example, consider the following simple diagram.
CE1 ----------- PE1 --------- P1 ------ P2 ---------- PE2 ----------- CE2
In this case, when you do a traceroute from CE1 to CE2, you are still able to see the infrastructure link IP that the traceroute traverses. You can also ping any infrastructure link IP that is a "C" route on PE1. However, you cannot ping any infrastructure link IP beyond that.
[argument #2] There is no comparable function of overload bit in OSPF
Fact: It is correct if one is referring to the concept of overload bit itself. However, it is wrong if the equivalent function of overload bit is referred.
It is true that OSPF does not support the concept of overload bit that enables a router to signal memory overload, real or fictitiously, in order to deflect potential transit packets before the router is ready to forward them. However, a feature that allows OSPF link-cost manipulation during BGP convergence should provide similar functionality, preventing unnecessary blackholing of traffic in certain transient situations. In this application, a router advertises Router LSAs with large cost values so that it is not preferred for transit traffic until it is ready.
ISIS
router isis
set-overload-bit on-startup | wait-for-bgp
OSPF
router ospf 100
max-metric router-lsa on-startup | wait-for-bgp
[argument #3] ISIS is more secure than OSPF
Fact: It is true at the time when authentication methods using MD5 etc was not available.
As ISIS packets are not encapsulated in IP packets but rather over the data link, they are harder to spoof and, therefore, less susceptible to common denial of service attacks. OSPF packets, in the contrary, are encapsulated over IP and are therefore subject more easily to spoofing and other denial of service attacks. However, the use MD5 authentication for OSPF deployment has significantly, if not totally, eradicated this shortcoming.
[argument #4] ISIS is more efficient than OSPF
Fact: This is a two-pronged argument...
First point, the reason why OSPF supports many LSAs is because it is designed with intentions such as limiting fragmentation and reducing bandwidth consumption by providing granular link-state information. This means that potential small-size packets and only the specific information would be advertised in response to any event (this undoubtedly introduces complexity into the management of link-state information though). On the other hand, ISIS LSPs are larger and fewer in a network of comparable size (this implies less complexity in managing the ISIS LS database). Hence, a lot of redundant information is retransmitted with a regenerated LSP in response to network events wasting bandwidth.
Second point, ISIS is able to group all its ISIS updates and sends them as one LSP. However, in OSPF, there are many LSA types and you cannot squeeze the different type LSAs into one LSU. For example, if you have two type1 and 2 type2 LSA, you need two LSUs, one with two type1 LSA and another with two type2 LSA in.
So who is the winner here? It depends but generally, the two points mentioned above did matter back in late 1980s but it is no longer relevant at this era where high-speed routing technology is nothing extraordinary.
[argument #5] ISIS is less CPU and Bandwidth intensive than OSPF
Fact: It is true since ISIS does not have to recalculate the and refresh the LSAs every 30 minutes like OSPF.
However, this is no longer an issue with modern CPUs and and interface speeds. Sending a few megs of data every 30 mins is not a big load on CPU. Same as argument #4.
[argument #6] It is a design fault for not being able to configure MaxAge (the maximum time an LSP/LSA can exist before it expires and purged) in OSPF
Fact: Whether it is a design fault or otherwise, it is true that MaxAge is fixed at 60min in OSPF whereas in ISIS, the default is 20min but is configurable upto a maximum of 18.7 hours.
Link-state routing protocols provide mechanisms to remove stale information from the Link-State database. Both ISIS and OSPF provide aging timers in link-state packets for this purpose. The Remaining Lifetime field (LSP Holdtime on Cisco routers) in ISIS is a down-counting timer that starts from 1200 seconds (default) and indicates how many more seconds before the LSP will expire. OSPF uses an up-counting counter that indicates the number of seconds since the LSA was originated.
However, how many designers really configure this MaxAge of ISIS? How many really care about MaxAge in OSPF is 60min? I guess most folks would just leave this value to its default except in some very complex topologies where MaxAge really needs to be considered.
[argument #7] ISIS is more feature-rich than OSPF
Fact: Wrong wrong wrong.
This point is still being raised whenever there is any ISIS vs OSPF discussion. The fact is, it is not true especially when it comes to IOS. As you can see in some IOS trains, ISIS is lagging behind OSPF when it comes to some features. The reason? OSPF is more widely deployed and hence there is more urgency to integrate those features into it. ISIS on the other hand, sits quietly in most Tier1 ISP core, where every Tier 1 ISP would prefer not to touch it for the sake of network stability.
Conclusion
Probably no one can tell you conclusively which protocol is way much better than the other due to the following reasons:
- [reason #1] Both have been established as practical IGPs and widely deployed in large scale IP networks (with OSPF more prominent in medium-large networks while ISIS in Tier 1 ISP networks)
- [reason #2] Both are functionally identical in most parts
- [reason #3] Developments are still being done on both IGPs; both protocols continue to cross features and capabilities
- [reason #4] Both support IPv6
Personally, if you ask me which protocol you should recommend your customers to go for, besides the four listed above, the following would also serve as a good guideline for your customers.
[Additional point #1] Except in some extreme complex topology, both protocols are about the same when it comes to scalability and functionality
[Additional point #2] Technical familiarity of the Network Engineering and Operations staff is probably the single most important factor in choosing one over another
[Additional point #3] Is there any dual IP and CLNS support requirement (well you don't believe it but Telco DCN is one of those that definitely requires ISIS)
[Additional point #4] Multivendor interoperability requirements
There is no point to switch your OSPF network which has been running for years without major incidents just because you hear that ISIS is a bit more stable than OSPF or ISIS has a cool command to hide the core (hey did I say this is not the only available core-hiding technique by the way?) :-)
So why did Compay XYZ choose OSPF over ISIS?
The reasons are actually quite simple and straightforward....
- Design Team voted in favor of OSPF as more are experienced in OSPF (democracy rules)
- Customers do not know ISIS well
- Management and troubleshooting will be made more difficult for NOC if ISIS is deployed
- ISIS core-hiding technique can be easily compensated using i-ACL and some other Security Best Practices. In fact, you still need iACL even if you can hide the core with ISIS technique
- Both OSPF and ISIS are expected to have similar scalability and performance judging from the scale of Compay XYZ, even with future network expansion taken into consideration
Personal experience
When I was with Japan's biggest ISP in Tokyo, I was part of the team which was responsible in switching our MPLS networks from OSPF to ISIS due to various stability and scalability reason. However, that was way back in 2000 and the routing devices then were not as powerful as today. OSPF suffered a lot of setbacks in ISP back then as the performance of the routing devices could not keep pace with the exploding network growth happening worldwide(and also partly due to poorly designed core). I still remember one of my wild thoughts then: Cisco accelerated the exploding growth by bringing MPLS into limelight only to see Juniper got the best of the both worlds by launching their powerful new hardware at a right time (purposely designed to better Cisco then; M5 could easily dethrone a 7500 then)
Some good references
Stability issues in OSPF Routing: http://conferences.sigcomm.org/sigcomm/2001/p18-basu.pdf
ISIS and OSPF Difference Discussions: http://geocities.com/mnvbhatia/draft-bhatia-manral-diff-isis-ospf-00.txt
Disclaimers
Some materials were quoted from other articles
2009 Apr 15
No comments:
Post a Comment