[j-nsp] IS-IS database leaking across virtual routers?

[Clarke Morledge]

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:

mxuser at 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

mxuser at 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:

mxuser at 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

mxuser at 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