I am trying to figure out how Junos handles IS-IS in an environment with
virtual routers (VRs). I see weird behvavior with some MX routers running
9.6 where some TLV information and some other details are "bleeding"
between different VRs when IS-IS is the routing protocol in those VRs.
By default, routing information in one VR should always remain separate
from routing information in a different VR. With our MX infrastructure, we
are stacking a bunch of different network topologies on top of one another
using VRs to keep the routing tables separate. I would assume that if you
run IS-IS in each VR that you will have a separate IS-IS database per VR,
analogous to having a separate routing table per VR. But I am having my
doubts.
Consider this case with the exchange of TLV 137 (Dynamic Host Name)
information. Each "router" should send a TLV 137 with the configured
hostname. I would assume this means that each VR would send TLV 137 and
the IS-IS databases in each VR on each physical router would then pick up
hostnames. A single hostname would correspond to multiple, unique ISO
addresses -- each ISO address per loopback per VR per phyiscal router, but
this should not matter, should it? And yet, compare the output below for
two different routing instances. Notice that only one "hostname" is
showing per IS-IS database per VR:
mxu...@cmx960-ccc> show isis database instance Wy
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
1720.1800.9006.00-00 0x3e1c 0x8317 689 L1 L2
CMX960-BBB.00-00 0x43ce 0x532d 1091 L1 L2
1720.1800.9008.00-00 0x42af 0x3ae4 647 L1 L2
1720.1800.9010.00-00 0x248f 0x61f 1020 L1 L2
1720.1800.9130.00-00 0x4271 0x2958 494 L1 L2
1720.1800.9136.00-00 0x421b 0xd22e 1148 L1 L2
1720.1800.9185.00-00 0x16da 0x7659 582 L1 L2
7 LSPs
mxu...@cmx960-ccc> show isis database instance Adm
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
1720.1810.0006.00-00 0x3f41 0x73f7 991 L1 L2
1720.1810.0007.00-00 0x3ec8 0xef93 1037 L1 L2
1720.1810.0008.00-00 0x3d6c 0x5eff 1193 L1 L2
DMX960-AAA-RE0.00-00 0x33a5 0xb07d 1093 L1 L2
1720.1810.0130.00-00 0x1e4f 0xcf02 487 L1 L2
1720.1810.0136.00-00 0x3f07 0x332e 841 L1 L2
6 LSPs
"CMX960-BBB" and "DMX960-AAA-RE0" are hostnames for two of my MX routers.
But for the other routers, the hostnames are not showing up in the
database output -- only the ISO addresses.
I wait a few minutes later and look at the IS-IS database for each routing
instance again. Here you see that "CMX960-BBB" is no longer there in the
output for instance Wy, but now "DMX960-AAA-RE0" shows up in instance Wy.
"DMX960-AAA-RE0" is no longer in instance Adm:
mxu...@cmx960-ccc> show isis database instance Wy
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
1720.1800.9006.00-00 0x3e28 0x6b23 459 L1 L2
1720.1800.9007.00-00 0x43da 0x3b39 932 L1 L2
1720.1800.9008.00-00 0x42bc 0x20f1 1061 L1 L2
DMX960-AAA-RE0.00-00 0x249c 0xeb2c 1117 L1 L2
1720.1800.9130.00-00 0x427e 0xf65 697 L1 L2
1720.1800.9136.00-00 0x4227 0xba3a 608 L1 L2
1720.1800.9185.00-00 0x16e7 0x5c66 911 L1 L2
7 LSPs
mxu...@cmx960-ccc> show isis database instance Adm
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
1720.1810.0006.00-00 0x3f41 0x73f7 940 L1 L2
1720.1810.0007.00-00 0x3ec8 0xef93 985 L1 L2
1720.1810.0008.00-00 0x3d6c 0x5eff 1141 L1 L2
1720.1810.0010.00-00 0x33a5 0xb07d 1041 L1 L2
1720.1810.0130.00-00 0x1e4f 0xcf02 436 L1 L2
1720.1810.0136.00-00 0x3f07 0x332e 790 L1 L2
6 LSPs
It is as though once a unique hostname gets associated to a particular ISO
address, that hostname can not get reused for an association to a
different ISO address on a different VR. At some point, a timer goes off
to clear the hostname correlation in the database and the associations get
rebuilt in the database, with potentially new asssignments.
I conclude that even though each VR should have a separate IS-IS databases
on a router, it looks like the different databases are in fact conflicting
with one another, "bleeding" into one another, or simply that there is but
one IS-IS database on the whole router with various tricks being played to
assign appropriate elements to different VR instances.
The issue with the TLV 137 (Dynamic Hostname) is but one example. I've
seen other weird behavior that has more detrimental impact. For example,
I can set the overload bit on a single VR and it will somehow impact IS-IS
within a completely separate VR running on the same router.
But the "leaking" problem doesn't impact every element in the IS-IS
database or databases. For example, I have not seen any problem with any
routing information such is IP prefixes being leaked from VR to another.
Thankfully, the raw link-state details of each IP prefix seems to respect
the VR boundaries. It is typically only a problem with some of the "bells
and whistles" of IS-IS, such the Hostname TVL, the Overload bit, and
perhaps a few other things.
Does anyone have any idea as to whether or not this is intended behavior
by Junos (I hope not), or is this a bug in the virtual routing
implementation?
Thanks.
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
