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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
