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

[Smith W. Stacy]

In my configs and example topology, the only traffic that would transit abr2 would be traffic originating/terminating on abr2 (as long as abr1 and it's interfaces were up). Traffic from isis2 to ospf2, for example, would take the isis2->isis1->abr1->ospf1->ospf2 path. This is due to the 'metric add 30' lines in the policies on abr2.

It is true that due to default preferences traffic between abr1<-->abr2 would flow via abr1<--->ospf1<--->ospf2<--->abr2. If you would instead prefer it to flow via the isis domain, then you can adjust the ospf protocol preference on abr1 and abr2 to be higher than 18 (the isis preference value).

In my topology, I did not include a direct link between abr1 and abr2, because I interpreted your original topology to not include such a direct link between abr1 and abr2. If you have such a link, or want to add such a link, that doesn't really change the routing configuration. Simply include the link in the isis domain, but not the ospf domain.

Also, even with my configurations and changing the ospf preference on abr1 and abr2, traffic originating at abr2 will prefer still to reach ospf2 directly, rather than taking the path via abr1 and ospf1. I'm not sure that's a problem worth trying to solve. If you feel it's important to solve for your topology, please provide more details.

Finally, one minor correction to my policies. Remove the final 'then reject' action from the abr1-ospf-into-isis and abr2-ospf-into-isis policies. This allows the default isis policy to be triggered which will advertise the directly connected interfaces running isis (with the 'then reject' these routes are blocked).

--Stacy



On Oct 8, 2010, at 3:57 PM, Clarke Morledge wrote:
> 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