On 24/10/16 21:20, Donald Neal wrote:
On 21/10/16 10:23, Ewen McNeill wrote:
For those playing along at home, it turns out that the Juniper EX platform (apparently including the EX4600) does not support route leaking of direct (connected) routes between virtual router instances:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB23027&smlogin=true
Thanks for posting that. I take it the same limitation is not present on QFX5x00's?
I've been told that the same issue has been replicated on a Juniper QFX5100 (which I think has a fairly similar set of ASICs to the EX4600, so presumably the same hardware options for the packet forwarding engine). I don't know about the rest of the QFX5x00 line, but I'd at least keep an eye out for it. "show route forwarding-table destination ... table ..." has also been mentioned as a possible diagnostic option. Apparently all the affected routes have a type of "rtbl", which is not a type that appears in the "show route forwarding-table" documentation: http://www.juniper.net/techpubs/en_US/junos14.1/topics/reference/command-sum... (nor can I find documented elsewhere, but it does appear in a few "why is this happening" discussions online). Assuming the VRs on the EX have only linknets to another ultimate router/gateway for the VLAN/subnets with the actual hosts on them, the main impact would seem to be additional latency on, eg, monitoring to the far end of the linknet. Eg on: v201 -> router -> v10 -> VR-10 EX VR-20 -> v20 -> router -> v202 with routes leaked between VR-10 and VR-20, it seems like a monitoring system in v201 might see the extra latency on pinging the router between v20 and v202 on the v20 address. But traffic from v201 to v202 would be handled via a gateway route on the EX, and thus hardware accelerated. In which case monitoring the v202 address of the router might be more representative in terms of latency. (This monitoring case may also be why someone decided to implement the process switching work around....) Now that we know about it, I think it's a limitation that it's possible to design around, by either ensuring there's an intermediate router between the EX and the final hosts, or avoiding leaked routes. Where it isn't possible to design around, you probably want something based on a more capable router chipset... Ewen