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

Clarke Morledge chmorl at wm.edu
Tue Jun 15 17:31:02 EDT 2010


Alan,

Actually, I did implement your workaround before with the static host 
mapping.  But that is rather cosmetic when compared to something like the 
overload bit.  In theory (or at least, in *my* theory), setting the IS-IS 
overload bit in one virtual routing instance should not interfere with 
IS-IS in another virtual routing instance.

Unfortunately, the observed behavior on the MX platform suggests some form 
of leaking.  I'm just not entirely convinced now that a "virtual router" 
really means a separate link-state database per virtual router.  Within 
this context, a virtual router should behave just like a physical router 
--- or like a logical router, for that matter.

Am I mistaken here?

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187

On Sun, 13 Jun 2010, Alan Gravett wrote:

> 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.
>>
>>----SNIP---SNIP-----


More information about the juniper-nsp mailing list