[j-nsp] Joining OPSF & IS-IS areas via 2 ABRs

[Clarke Morledge]

Smith W. Stacy says

> Hi Clarke,
>
> I believe I have an answer for you...
>

Smith: I really want to thank you for the full diagram and thoughtful 
config.  That's a great solution.  Your use of logical tunnel interfaces 
to bring the different "logical" routers together is a clean way to do it, 
and it stands by itself.

My only caveat is that I was hoping to find a way to solve this by 
combining abr1 and isis1 into one physical router and abr2 and isis2 into 
a separate physical router.  True, I could follow your config and have two 
separate routing instances and/or tru-blue logical routers on these 
physical routers and accomplish what I need to do.  However, please 
correct me if I am wrong, but the main drawback I see with the logical 
tunnel approach to this problem -- at least for the MX platform that I am 
using -- is that logical tunnels consume PFE resources; i.e. the need to 
include a "tunnel-services" statement under the "edit chassis fpc <num> 
pic <num>" stanza.

Amending your diagram, I was looking at something like this:

+-------------+                           +-------------+
|    ospf1    | .1                     .2 |    ospf2    |
|  10.0.0.1   +---------------------------+  10.0.0.2   |
|             |         10.0.1.0/30       |             |
+------+------+                           +------+------+
    .1 |                                      .1 |
       | 10.0.2.0/30                             | 10.0.3.0/30
    .2 |                                      .2 |
+------+------+                           +------+------+
|    abr1     |       192.168.3.0/30      |    abr2     |
| 192.168.0.1 +---------------------------+ 192.168.0.2 |
|             | .1                    .2  |             |
+------+------+ ISIS                ISIS  +------+------+
        |                                         |
        |                                         |
        v                                         v
  other isis routers                other isis routers

Unfortunately, this makes the configuration of abr1 & 2 very complex and 
problematic.  For example, even though I could play tricks with metrics, 
abr1 and abr2 would both have OSPF routes to 10.0.1.0/30.  So, if I gave 
the path through abr1-ospf1 the better metric, but then had a packet 
transiting abr2 towards 10.0.1.0/30, it would most likely take the path 
from abr2 via ospf2 --- despite the better metric via abr1-ospf1.  For 
example:

On abr1:

10.0.1.0/30  *[OSPF/10] 1w5d 07:24:08, metric 20
                     > to 10.0.2.1 via xe-6/2/0.130

On abr2:

10.0.1.0/30  *[OSPF/10] 1w5d 07:24:18, metric 50
                     > to 10.0.3.1 via xe-6/2/0.130
                     [IS-IS/18] 7w5d 07:24:18, metric 30, tag 80
                     > to 192.168.3.1 via xe-11/0/0.130


So I was wondering about using "route preference" to solve this on abr2; 
i.e. increasing the OSPF internal route preference value to make the IS-IS 
learned route via abr1 preferred for 10.0.1.0/30.  I was looking at this 
until I realized that forcing a change in route preference applies to all 
routes from that protocol.  There did not seem to be way to use policy to 
force route preference for a prefix-list within this context (though I 
could be missing something).  Also, there could be other scary things here 
I am not considering when playing with route preference.

Any other thoughts on problem?

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187