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

Alan Gravett alangra at gmail.com
Sat Jun 12 22:56:22 EDT 2010


Use static host mapping for each VR/lo0.x to avoid confusion

set system static-host-mapping R1 sysid 0100.0011.0001

and so on...

On Fri, Jun 11, 2010 at 7:23 PM, Clarke Morledge <chmorl at wm.edu> wrote:

> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list