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-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Clarke Morledge
Sent: Tuesday, June 15, 2010 5:31 PM
To: Alan Gravett
Cc: juniper-nsp@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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
