Ask the VIP Event: Unicast IP Routing Protocols - Page 2

ciscomoderator · ‎10-07-2011

With Peter Palúch

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to get expert insights and learn about Unicast IP routing protocols with Cisco Designated VIP Peter Palúch. Peter Palúch is an assistant professor and a Cisco Networking Academy instructor at the University of Zilina, Slovakia. His fields of interest include routing, switching, and MPLS technologies. He is a seasoned teacher who has cooperated in various educational activities in Slovakia and abroad, focusing particularly on networking and Linux-based network server systems. Peter holds a doctoral degree in the area of VoIP quality degradation factors; he also holds CCIP certification and CCIE certification (#23527) in Routing & Switching.

Remember to use the rating system to let Peter know if you have received an adequate response.

Peter might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Network Management discussion, discussion forum shortly after the event. This event lasts through October 21, 2011. Visit this forum often to view responses to your questions and the questions of other community members.

Kishore Chennupati · ‎10-12-2011

Hi Peter,

Interesting. So at the moment, I don't have ip pmtu turned on and if i send a 1500byte IP packet with df-bit set

from the 3750 switch , it will get to the 3845, then it adds the overhead making it a 1538byte packet. Since the df-bit is not copied this packet is fragmented into 1500bytes and 76bytes(38+38) and ships it across. right?

With the ip pmtu turned on the df-bit gets copied hence fragmentation doesn't happen and if its a buggy IOS like what you mentioned the df-bit is set regardles and it won't work.But then should'nt the ICMP be sent back to the source and the source should lower the MTU? Does this mean that EIGRP doesn't care and keeps sending the packets at large sizes?

sw00001#sh system mtu

System MTU size is 1500 bytes

System Jumbo MTU size is 1500 bytes

Routing MTU size is 1500 bytes

IOS used :

Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(44)SE2, RELEASE SOFTWARE (fc2)

Cisco IOS Software, 3800 Software (C3845-SPSERVICESK9-M), Version 12.4(20)YA, RELEASE SOFTWARE (fc1)

I have checked the tunnel with the ip pmtu on and the df-bit is actually off and the PATH MTU on that is set to 1500bytes.

Thanks for your help again.

Regards

Kishore

Kishore Chennupati · ‎10-12-2011

So, at the moment if I were to fix the CPU issue on the 3845 router caused due to fragmentation without using the ip pmtu on the 3845 then I would have to lower the size of the EIGRP update packets.

If this is the case then I have 2 options I guess

1. I need to use a route-map to clear the df-bit and let the router fragment them

2. not use ip pmtu

3. Lower the TCP mss(1420) and ip mtu to 1460 on the 3750 so that eigrp sends smaller packets. This will lead to more cef switching but atleast the eigrp packets go thru and the 3845 will not complain of CPU caused due to fragmentation. Would I be correct in saying this?

Regards,

Kishore

Peter Paluch · ‎10-12-2011

Hello Kishore,

So at the moment, I don't have ip pmtu turned on and if i send a 1500byte IP packet with df-bit set from the 3750 switch , it will get to the 3845, then it adds the overhead making it a 1538byte packet. Since the df-bit is not copied this packet is fragmented into 1500bytes and 76bytes(38+38) and ships it across. right?

EDIT: I had incorrect information posted here. I apologize for that. You are correct: Assuming that the L2TPv3 header is 4B long (with no cookie present), the total overhead is outer IP (20) + L2TP (4) + Ethernet (14) = 38 bytes. The maximum size of the inner IP packet so that the fragmentation does not take place is therefore 1500-38=1462 bytes. If a packet with 1500 bytes comes in, it will be inflated after encapsulation to 1538 bytes. Fragmenting it will result into two packets, the first being 1500 bytes long including the L2TP header, the remaining fragment will be IP (20)+remainder(38)=58 bytes long.

If 802.1Q frame tagging is used, the overhead will increase by 4 bytes, and the maximum size of the inner IP packet without necessitating fragmentation will decrease to 1458 bytes.

With the ip pmtu turned on the df-bit  gets copied  hence fragmentation doesn't happen and if its a buggy IOS  like what you  mentioned the df-bit is set regardles and it won't  work.But then  should'nt the ICMP be sent back to the source and the  source should  lower the MTU? Does this mean that EIGRP doesn't care and keeps sending  the packets at large sizes?

On my buggy IOS with the ip pmtu configured, I have noticed that the ICMP Packet-too-big messages were actually sent only if the original packet had the DF bit set. Otherwise, they were suppressed. As EIGRP did not send its packets with the DF bit set, it was impossible for it to receive a Packet-too-big message. In addition, I doubt that the IP/EIGRP implementation actually honors ICMP Packet-too-big messages.

1. I need to use a route-map to clear the df-bit and let the router fragment them

The EIGRP packets are not sent with DF bit set - I am afraid this option will not help.

2. not use ip pmtu

This is what you are using now. Obviously not satisfactory.

3.  Lower the TCP mss(1420) and ip mtu to 1460 on the 3750  so that  eigrp sends smaller  packets. This will lead to more cef switching but  atleast the eigrp  packets go thru and the 3845 will not complain of CPU  caused due to fragmentation. Would I be correct in saying this?

I am afraid that this lowering the IP MTU on the 3750 will only move the problem from the 3845 to the 3750 because now, it will be the 3750 that will be in charge of fragmenting oversized IP packets being L3-switched through it. You could actually overload your 3750 just as easily.

Clamping the TCP MSS may help for TCP connections, though - and you could actually consider using the ip tcp adjust-mss 1420 on the 3750 without modifying the IP MTU and without using the ip pmtu on the 3845. It should be a good compromise that does should not increase the load on the 3750 too much (only initial TCP segments will be process-switched), and at the same time, force the TCP streams (that should constitute a majority of flows through your L2TP tunnels) to use smaller segments, avoiding the need for fragmentation.

I am, however, still strongly interested in learning what exactly is happening to your EIGRP packets. Obviously, they get lost because of being too big - the question is, why are they not fragmented just that easily.

Do you have an option of capturing the L2TP-encapsulated packets as they are sent out by the 3845? It would be very interesting to see them after the ip pmtu is set.

Best regards,

Peter

Kishore Chennupati · ‎10-13-2011

Hi peter,

Thank you for your legendary explanation as always. I can't promise me settiing up wireshark to get the output.:-(

if there are ny debug commands that i can run i can do that after hours. You are perfectly right when u say that the issue will move from the 3845 to the 3750.

I tried to ping 1463 bytes even without the df-bit set and still no luck. I see no df-bit set even with the ip pmtu on the tunnel. So the path mtu discovery is indeed working.

I get ICMP time exceeded messages as if the routers are not fragmenting at all or not getting the reply from other side. Will paste the output in the mornig when I am at work.

Again I do appreciate all your help here

Regards,

Kishore

Kishore Chennupati · ‎10-13-2011

Hi Peter


I am, however, still strongly interested in learning what exactly is happening to your EIGRP packets. Obviously, they get lost because of being too big - the question is, why are they not fragmented just that easily.

This I believe is because PMTUD doesn't allow fragmentation packets bigger than the Path MTU which in our case is 1500bytes and sends the ICMP Packet too big back to source. and EIGRP is sending packets bigger than that.:-( Once I remove the pmtu it works fine as per your explanation.

I appreciate all the help Peter. You are really approachable and knowledgable. That's a rare combo

I won't take any more of your time here as I know there are other engineers that need your valuable knowledge.

Thanks again

Regards,

Kishore

Peter Paluch · ‎10-14-2011

Hi Kishore,

You are certainly not taking my time - after all, this event is here precisely because I want to devote my time to any and all questions posted here!

This  I believe is because PMTUD doesn't allow fragmentation packets  bigger  than the Path MTU which in our case is 1500bytes and sends the  ICMP  Packet too big back to source. and EIGRP is sending packets bigger  than  that.:-( Once I remove the pmtu it works fine as per your  explanation.

Hmmm, that would be possible for a basic PMTU discovery, but do not forget a couple of things:

EIGRP is sending its packets with DF bit cleared (i.e. fragmentation is allowed)
Even with ip pmtu on, the outer Ip header should have the DF bit clear (and if it has the DF bit set then it corresponds to the bug I've described a few posts earlier - so far the only complete explanation for the issue you are experiencing)
Fragmentation is performed on the resulting encapsulated packet if it has its DF bit clear. In such case, it can be of arbitrary resulting size (up to 64 KB which is the maximum size for an IPv4 packet)

In other words, regardless of the size of EIGRP packets, the resulting encapsulated packets should be fragmented without any problems.

I get ICMP time exceeded messages as if the routers are not fragmenting  at all or not getting the reply from other side. Will paste the output  in the mornig when I am at work.

I would be interested in seeing that. Also, is there really no way of capturing the traffic behind the 3845 to see what happens to the large EIGRP packets?

Best regards,

Peter

Peter Paluch · ‎10-15-2011

Hello Kishore,

Another thoughts about why EIGRP does not (and probably should not) honor ICMP Packet-Too-Big messages.

I think that for IGP protocols, there is no real reason to support PMTU Discovery, honor ICMP Packet-Too-Big messages and react accordingly, because they are designed to run over a single link, i.e. with no router inbetween. On a single link, every device is supposed to use the same MTU. Having different MTUs is a configuration error per se and no protocol is supposed to work around that. In addition, Packet-Too-Big messages are sent only when routing packets. In a link-local communication as with IGP protocols, there is no routing involved so no device is actually in position of sending those ICMP messages. Receiving a packet that is larger than the receiving interface's MTU results in dropping that packet, but no ICMP Packet-Too-Big will be sent. That would explain why EIGRP does not react to ICMP Packet-Too-Big even if they are received - because they would not be used at all under normal operation.

This, however, should not be a problem for EIGRP over L2TP PW. As we have spoken so often here, the resulting encapsulated EIGRP message should be properly fragmented afterwards.

In the topology exhibit you have posted, there is a firewall placed after the upper 3845. Is it by any chance possible that it has some issues with handling fragmented IP packets?

Best regards,

Peter

Kishore Chennupati · ‎10-15-2011

Hi Peter,

Thanks for your reply. I dont think the firewall is causing any issues as you know once i take off the ip pmtu and still send larger packets they get fragmented and go thru and EIGRP also works fine.

I have send some icmps without df-bit set and still they dont go thru above 1462. Also the df-bit on the tunnel is off.

Does L2TPv3 PMTUD work differently to that of GRE??.

sw00001#ping 10.201.32.254 size 1462 pinging a loopback on the other switch

Type escape sequence to abort.

Sending 5, 1462-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/9 ms

sw00001#ping 10.201.32.254 size 1463

Type escape sequence to abort.

Sending 5, 1463-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

So as you can see the packets are not getting fragmented and sent across not sure if the ip pmtu is causing it not to fragment.

I wish i cud do some wireshark stuff to capture the packets

Thanks again

Regards,

Kishore

Peter Paluch · ‎10-17-2011

Hello Kishore,

Are these two pings (the successful one with 1462 bytes and unsuccessful one with 1463, both not having DF bits set) sent while the ip pmtu is configured or unconfigured?

Ideally, to remove any doubt as I seem to be somewhat confused about when exactly the packets start getting lost in your case, would you mind performing these eights tests and label them clearly when posting your results?

Ping over the L2TP PW, size 1462, no df-bit, no ip pmtu
Ping over the L2TP PW, size 1463, no df-bit, no ip pmtu
Ping over the L2TP PW, size 1462, df-bit, no ip pmtu
Ping over the L2TP PW, size 1463, df-bit, no ip pmtu
Ping over the L2TP PW, size 1462, no df-bit, ip pmtu
Ping over the L2TP PW, size 1463, no df-bit, ip pmtu
Ping over the L2TP PW, size 1462, df-bit, ip pmtu
Ping over the L2TP PW, size 1463, df-bit, ip pmtu

Thank you very much!

Best regards,

Peter

Kishore Chennupati · ‎10-18-2011

Hi Peter,

Sorry for the delay .

+++++ Without ip mtu

sw00001#ping 10.199.32.254 size 1462

Type escape sequence to abort.

Sending 5, 1462-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms

sw00001#ping 10.199.32.254 size 1463

Type escape sequence to abort.

Sending 5, 1463-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/17 ms

sw00001#ping 10.199.32.254 size 1463 df-bit

Type escape sequence to abort.

Sending 5, 1463-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

Packet sent with the DF bit set

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms

sw00001#ping 10.199.32.254 size 1462 df-bit

Type escape sequence to abort.

Sending 5, 1462-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

Packet sent with the DF bit set

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms

++++++++ WIth IP MTU

sw00001#ping 10.199.32.254 size 1462

Type escape sequence to abort.

Sending 5, 1462-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/17/42 ms

sw00001#ping 10.199.32.254 size 1463

Type escape sequence to abort.

Sending 5, 1463-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

sw00001#ping 10.199.32.254 size 1462 df-bit

Type escape sequence to abort.

Sending 5, 1462-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

Packet sent with the DF bit set

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/16 ms

sw00001#ping 10.199.32.254 size 1463 df-bit

Type escape sequence to abort.

Sending 5, 1463-byte ICMP Echos to 10.199.32.254, timeout is 2 seconds:

Packet sent with the DF bit set

M.M.M

Success rate is 0 percent (0/5)

As you can see the PMTUD doesn't seem to fragment with the IP MTU on

Regards,

Kishore

Peter Paluch · ‎10-19-2011

Hello Kishore,

Thank you very much for performing these experiments! Please continue to read my reply here:

https://supportforums.cisco.com/message/3470308#3470308

Best regards,

Peter

MacGyver27 · ‎10-13-2011

Hey Peter,

Firstly my name is Michal Aron, I am from Presov. Maybe you remember year 2009 in Zilina - 3,4,5 place in the cisco olymp. I hear about you from Peter Fecilak when I attended CCNP class at TUKE.

Feel excited to further discussion

Now I am student & employee. I work at AT&T Brno in mobility department under Cisco vendor. When I was investigating running-config of those 7600 I got into some serious googling. What interested me was what is originally behind using 2 or more OSPF processes.. If you are taken by this topic, I will appreciate your words.

Seeing your reply soon!

Michal Aron

Peter Paluch · ‎10-13-2011

Hi Michal,

It is so good to meet you again

If two or more OSPF processes are run on a single device, each of them keeps its own set of interfaces and its own link-state database. An interface can belong to a single OSPF process only, and link-state databases of different OSPF processes are isolated and distinct from each other. As a result, multiple OSPF processes create multiple routing domains that keep their contents to themselves and do not share it with each other. A router that runs multiple OSPF processes knows about all networks in all routing domains (individual OSPF processes) it is present in, but it does not leak the information between the individual domains.

This can be beneficial if, for example, a single router is shared among two or more companies. Having each company "closed" in a different OSPF process will allow the router to provide routing services for both companies, and yet prevent networks from one company leaking into another. Another usage, very common in today's networks, is using multiple OSPF processes for VPNs where each OSPF process is constrained to run in a distinct VPN (associated with a particular Virtual Routing and Forwarding instance, VRF).

Please feel welcome to ask further!

Best regards,

Peter

tomas.kanocz · ‎10-13-2011

Hi Peter,

First of all, it is a pleasure to post on your wall for me

I have a question regardin IS-IS. I know that I somewhere red (correct me if I am wrong) that IS-IS does not support NBMA networks, but I do not know why it is like that. I've set up a small lab to test it.

The topology is as follows:

Every router has a loopback address advertised via IS-IS. R1's loopback is 1.1.1.1/32, R2's 2.2.2.2/32 and so on. The subnet between the routers is 10.10.10.0/24. The last octet is the number of the router, so for example R3 has IP 10.10.10.3.

I have a prety simple question (the answer might be not so simple :D), why is the routing table looking like it does?

I was thinking, that if I make sure, that the pseudo node is advertised by R1, the topology would function perfectly. The fact is, that it does, but it evokes one question in me. Why is the routing table looking like it does? I was expecting just L1 routes in the table, but R2 and R3 see each other's networks like level 2 routes.

The configurations are as follows:

R1:

router isis

net 49.0001.1111.1111.1111.00

interface Serial0/0

ip address 10.10.10.1 255.255.255.0

ip router isis

encapsulation frame-relay

frame-relay map clns 103 broadcast

frame-relay map clns 102 broadcast

frame-relay lmi-type ansi

isis priority 127

interface Loopback0

ip address 1.1.1.1 255.255.255.0

ip router isis

R2:

router isis

net 49.0001.2222.2222.2222.00

interface Serial0/0

ip address 10.10.10.2 255.255.255.0

ip router isis

encapsulation frame-relay

frame-relay map clns 201 broadcast

frame-relay lmi-type ansi

interface Loopback0

ip address 2.2.2.2 255.255.255.255

ip router isis

R3:

router isis

net 49.0001.3333.3333.3333.00

interface Serial0/0

ip address 10.10.10.3 255.255.255.0

ip router isis

encapsulation frame-relay

frame-relay map clns 301 broadcast

frame-relay lmi-type ansi

interface Loopback0

ip address 3.3.3.3 255.255.255.255

ip router isis

----------------------------------- end of configs -------------------------------

The routing tables:

R1#show ip route

1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, Loopback0

2.0.0.0/32 is subnetted, 1 subnets

i L1 2.2.2.2 [115/20] via 10.10.10.2, Serial0/0

3.0.0.0/32 is subnetted, 1 subnets

i L1 3.3.3.3 [115/20] via 10.10.10.3, Serial0/0

10.0.0.0/24 is subnetted, 1 subnets

C 10.10.10.0 is directly connected, Serial0/0

R2#show ip route

1.0.0.0/24 is subnetted, 1 subnets

i L1 1.1.1.0 [115/20] via 10.10.10.1, Serial0/0

2.0.0.0/32 is subnetted, 1 subnets

C 2.2.2.2 is directly connected, Loopback0

3.0.0.0/32 is subnetted, 1 subnets

i L2 3.3.3.3 [115/30] via 10.10.10.1, Serial0/0

10.0.0.0/24 is subnetted, 1 subnets

C 10.10.10.0 is directly connected, Serial0/0

R3#show ip route

1.0.0.0/24 is subnetted, 1 subnets

i L1 1.1.1.0 [115/20] via 10.10.10.1, Serial0/0

2.0.0.0/32 is subnetted, 1 subnets

i L2 2.2.2.2 [115/30] via 10.10.10.1, Serial0/0

3.0.0.0/32 is subnetted, 1 subnets

C 3.3.3.3 is directly connected, Loopback0

10.0.0.0/24 is subnetted, 1 subnets

C 10.10.10.0 is directly connected, Serial0/0

-------------------------- end of routing tables --------------------

As I expected, IS-IS does not have any problem with this hub and spoke topology (once R1 generates the pseudonode), but one that I did not expect, is that the spokes will see themselves as level 2 routes. The question is why do they exchenge level 2, but not level 1 routes, as they are in the same area, they should use Level 1. Am I right? What are the criteria for the Level 1 and 2 then, or is it tweaked for NBMA after all?

Looking forward to your post Peter, as I know IS-IS is one of your favorite protocols

Wish you all the best,

Tom

Peter Paluch · ‎10-14-2011

Hi Tom,

It is always a pleasure to answer to such a well-presented case!

Actually, you have a very good case here, and you've made me think for quite a while. My explanation here is not backed up by any reference to an ISO IS-IS standard - I've briefly skimmed the ISO/IEC 10589 standard but there does not seem to be any specific reference to this. I will have to go over it in more detail, but in the meantime, this is my opinion on the issue. The explanation is indeed a bit lengthy.

When performing a run of SPF algorithm in link-state protocols, one of the verifications made during the algorithm is the two-way connectivity check: If you are inspecting a node B reachable from node A, you also verify whether the node B advertises an adjacency to A - in other words, if they mutually consider each other to be neighbors.

In your FR network, this check would actually pass: all routers indicate their adjacency to the pseudonode created by the DIS=R1 (all routers can hear R1), and the pseudonode indicates its adjacency to all three routers (R1 can hear all routers). For OSPF, this would be completely sufficient and make it happy.

However, IS-IS, at least on Cisco routers, seems to make stronger checks. If a router, say, R2, is directly connected to a multiaccess network represented by a pseudonode, it obviously expects the routers adjacent to the pseudonode (i.e. connected to the same multiaccess network) not just to pass the two-way connectivity check but to actually be R2's valid neighbors in the Up state. This requirement is absolutely natural: routers connected to a common multiaccess segment should hear each other and be each other's neighbors. Note, however, that this requirement is not met in your network for obvious reasons: there is no PVC between R2 and R3, and naturally, they cannot directly hear each other. It is in fact quite surprising to R2 to learn that there is another router, R3, on the same multiaccess network behind R2's Serial0/0 interface (the pseudonode and the R3's LSP indicate an adjacency to each other), and yet not to see the R3 as a neighbor.

Because R2 does not recognize R3 as its neighbor on the Serial0/0 interface despite the pseudonode for the Serial0/0's network and R3's LSP indicate an adjacency, it ignores the R3's LSP and does not process it during the SPF computation. This is the reason why R2 does not see the 3.3.3.3/32 network as L1 network.

From the viewpoint of R1, R3 is both adjacent via the LSP and recognized as a valid neighbor, as R1 and R3 can directly hear each other via their PVC. Therefore, for R1, the connection towards R3 meets both the two-way connectivity check and the neighbor check, and R1 processes the R3's LSP without any hesitations, hence the 3.3.3.3/32 network in R1's routing table recognized as L1 route.

For R3, the situation is analogous to R2: because R1 and R2 see each other, R1 knows also the L1 route towards 2.2.2.2/32, however, R3 ignores the LSP from R2 because it does not recognize R2 as a valid neighbor despite being interconnected via a common network.

Now, in default configuration, Cisco IS-IS runs as L1/L2 router. Each L1/L2 router in a particular area takes L1 routes (i.e. routes internal to that area) and imports them into its L2 database automatically, advertising them as directly connected. This is what R1 is doing: it takes the L1 networks 2.2.2.2/32 and 3.3.3.3/32, injects them into its L2 database and advertises them both as if they were directly connected to R1 (with their metrics simply copied from the L1 routing table).

Now, because both R2 and R3 consider R1 as their valid neighbor, they are perfectly happy with processing R1's L2 LSP. That LSP indicates that R1 is connected to networks 2.2.2.2/32 and 3.3.3.3/32. So when processing the L2 LSDB, both R2 and R3 will process the LSP from R1 and will actually learn the networks from each other - however, as you can see, by a totally different process than intuitively expected.

If you configured any of your routers as an L1-only router, the show would be over: if R2 or R3 were L1-only routers, they would not establish L2 adjacency to R1 and would not be able to see R1's L2 LSP containing the networks 2.2.2.2/32 and 3.3.3.3/32. If R1 was running as L1-only, it would not create the L2 LSP containing those routes at all. In any case, full reachability in this network would not be attained.

There is another issue to consider: if R2 does not process the L1 LSP from R3, it will neither process L1 LSPs of routers that are possibly connected behind R3, as R2 considers R3 and everything behind it as unreachable. That could again cause reachability issues in your network. If R2 saw those networks, it would be only thanks to R1 "uptaking" those networks from L1 to L2 and advertising them in L2 LSP to R2.

Even if IS-IS did not perform the neighbor check, the situation would be unpleasant just as with OSPF running NBMA or BMA mode over partially meshed networks - you would still need to tweak the DIS priority and possibly hack around unreachable next-hop addresses for spoke networks. So in fact, IS-IS not very happy with partially meshed NBMA networks, in a way very similar to OSPF. However, the OSPF is slightly more relaxed (or better said, ignorant) about partially-meshed networks in NBMA/BMA mode while IS-IS is more stiff and even refuses to process LSPs from wannabe-neighbors that are not directly reachable.

It should be noted that if the network was fully meshed like ordinarily possible with ATM or X.25 (in general, SVCs established on demand), then the network, even being a non-broadcast multiaccess technology, would work very nicely both with OSPF and IS-IS. However, for partially-meshed networks, IS-IS is simply not suitable. In fact, even for OSPF, the NBMA mode is not intended to be used on partially-meshed networks. On those, the point-to-multipoint OSPF mode is the preferred choice. Sadly, IS-IS has no similar provisions.

Please feel welcome to ask further - this topic is quite convoluted!

Best regards,

Peter