This is sort of a follow-up to a question I had a few weeks ago about how to configure conditional default origination in IOS XR. It seems that ISIS default origination in both IOS and IOS XR behaves in a pretty suboptimal way. I don't have a lot of history with IS-IS, so I'm curious about this.
Take this topology as an example: [E1]-----[RA]------[RB]-----[RC]------[RD]------[E2] RA, RB, RC and RD are running ISIS. E1 and E2 are external BGP peers to RA and RD. E1 and E2 are advertising a default. If you want to get the default into ISIS, we can configure default-information originate on RA and RD. This seems to work as expected. Now, imagine that RD loses its link to E2. It loses the external BGP default in the RIB and now only has a default route in ISIS that it learned via RC. RD will start sending all traffic to RC, but RC will send all traffic back to RD because that is the nearest default route. It makes absolutely no sense for RD to use the ISIS default in its RIB to originate a default, but both IOS and IOS XR will happily do just that. In order to stop this insane behavior, you have to configure conditional default advertisement. OSPF does not behave in this way. If we were using OSPF, RD would not use the OSPF default in its RIB to generate yet another default, so the routing loop between RC and RD would never form. Is this behavior something specific to Cisco's implementation of IS-IS, or is there something in the standard that would suggest this behavior? It seems like an odd choice. You certainly would not recommend to OSPF users that they go around configuring "default-information originate always" all the time, so why make that essentially the behavior in IS-IS? Wouldn't it be more sensible to adopt the behavior of default origination in OSPF for IS-IS, at least when doing it by using the "default-information originate" command? I've been discussing this with some other engineers at work and no one has any idea why Cisco would implement it this way. Thanks, John _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
