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

[Clarke Morledge]

Just to put a little closure on this topic from two months ago for the 
archives:   The issue I was having was NOT due to IS-IS database leaking 
across VRFs.   I had some routing policy problems due to configuration 
errors.

However, the fact that Juniper will only assign one IS-IS hostname per 
router regardless of the number of VRFs is a convenient red herring. 
Juniper is essentially overwriting the TLV 137 information within the 
router database everytime a TLV 137 LSP is received from a neighbor on a 
different VRF.  This is very annoying.  I did compare Juniper's IS-IS VRF 
implementation with Cisco's, and Cisco does not have this problem.  Cisco 
will assign the same IS-IS hostname across multiple VRFs without causing 
any confusion.

Perhaps Juniper can learn something from their primary competitor :-)

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

On Thu, 17 Jun 2010, Stefan Fouant wrote:

>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
>> bounces at puck.nether.net] On Behalf Of Clarke Morledge
>> Sent: Tuesday, June 15, 2010 5:31 PM
>> To: Alan Gravett
>> Cc: juniper-nsp at puck.nether.net
>> Subject: Re: [j-nsp] IS-IS database leaking across virtual routers?
>>
>> 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?
>
> Hey Clarke,
>
> Sorry, I'm just getting around to reading this now.  I would say you are
> correct in your understanding of the way that VRs are supposed to work -
> routes/TLVs/etc. in one VR should not be leaking into the other.  I'm
> curious, how are you mapping the traffic into their respective VRs?  Are
> these separate and distinct physical interfaces which are bound to their
> respect VRs or are you using some form of VLAN tagging and mapping unique
> VLANs into a given VR?  Is there any chance you have any type of rib-groups
> or some other type of vrf-import/export policy in place that might be
> causing some unintended behavior?  Care to share some of your configuration?
>
> All the best,
>
> Stefan Fouant, CISSP, JNCIEx2
> www.shortestpathfirst.net
> GPG Key ID: 0xB5E3803D