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