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

[Harry Reynolds]

That's Stacy for you. ;)

I believe you get a 1Gbps tunnel for free. For 10G you do per a pfe port.

Regards

 

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Clarke Morledge
Sent: Friday, October 08, 2010 2:57 PM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Joining OPSF & IS-IS areas via 2 ABRs


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

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp