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-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Clarke Morledge Sent: Friday, October 08, 2010 2:57 PM To: juniper-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp