[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