That’s interesting. I wouldn’t have expected to hear that about Juniper.
Thanks for the insight! > On Jul 8, 2016, at 2:19 PM, Aaron Dewell <[email protected]> wrote: > > > Yes, though there are occasional issues such as sshd only binding to the > local IPs within inet.0. Whether that’s working yet or not will depend on > version and the enhancement request previously mentioned. Last I heard, that > was going to be a 16.1 or farther out feature, but it depends on which > daemon, which platform, and which release. Doing management within a VRF is > a new thing for Juniper and the feature is still in process of coming out. I > would expect various issues with it, even if some things work. > >> On Jul 8, 2016, at 12:06 PM, Jason Lixfeld <[email protected]> wrote: >> >> So if my management stations are is in the same VRF as lo0, no leaking >> should be required. >> >> Of course, this implies that the underpinnings of route redistribution >> (i.e.: connected/static into MP-BGP) inside the VRF are all present, so the >> routing table on the EX knows how to get everywhere inside that VRF. >> >>> On Jul 8, 2016, at 1:52 PM, Aaron Dewell <[email protected]> wrote: >>> >>> >>> Sorry! I got stuck on SRX. Ignore that lol. >>> >>> So if you’re only putting lo0 into the VRF, then you’ll need some way to >>> route in and out of the VRF to get there. That could be via route leaking, >>> etc. That routing table will have to have a return route to the source, >>> and the main instance will have to have a route to that /32. You can’t put >>> the management interface (em0, fxp0, vme, etc. depending on platform) into >>> a VRF. >>> >>> As you’re route-leaking or whatever in order to get back and forth into the >>> VRF, it really doesn’t buy you much on a Junos platform to put it there in >>> the first place. Thus, why nobody really does it in Juniper-land. You >>> could, in theory, only leak your management routes into the VRF and >>> increase your security slightly, but you can also just filter source IPs in >>> your lo0 filter with the same benefit. >>> >>> You still get the same firewall filter protection (the input-list stuff) if >>> it’s in the main inet.0 instance. >>> >>> So the common practice is to write the lo0 filter like this: >>> >>> from a prefix list listing allowed sources using particular protocols (i.e. >>> ssh) -> accept >>> anything else -> discard >>> >>> That can be multiple terms or however you prefer to write it. >>> >>>> On Jul 8, 2016, at 11:34 AM, Jason Lixfeld <[email protected]> wrote: >>>> >>>> Sorry, I wasn’t trying to suggest I got an error, it was more of a >>>> conceptual config paste. >>>> >>>> This is on an EX9200, which I don’t think support security zones? >>>> >>>>> On Jul 8, 2016, at 1:25 PM, Aaron Dewell <[email protected]> wrote: >>>>> >>>>> >>>>> Did you write those firewall filters that you list? What was the error >>>>> that you got? >>>>> >>>>> You’ll have to assign lo0 into a security zone, that might be what’s >>>>> missing. >>>>> >>>>> "security zones functional-zone management” must be in inet.0. You can >>>>> do other zones in a VRF and do in-band management within them (though >>>>> it’s slightly recommended against, due to potential of misconfiguration >>>>> causing a security issue), but this should work. That’s what Clinton was >>>>> saying. >>>>> >>>>>> On Jul 8, 2016, at 11:20 AM, Jason Lixfeld <[email protected]> wrote: >>>>>> >>>>>> I’m not quite following. This won’t work: >>>>>> >>>>>> set interfaces lo0 unit 0 family inet address 10.219.60.54/32 >>>>>> set interfaces lo0 unit 0 family inet filter input-list >>>>>> V4-ACCEPT-COMMON-SERVICES >>>>>> set interfaces lo0 unit 0 family inet filter input-list >>>>>> V4-ACCEPT-ESTABLISHED >>>>>> set interfaces lo0 unit 0 family inet filter input-list V4-DISCARD-ALL >>>>>> set routing-instances MANAGEMENT instance-type vrf >>>>>> set routing-instances MANAGEMENT interface lo0.0 >>>>>> set routing-instances MANAGEMENT route-distinguisher 21949:21949 >>>>>> set routing-instances MANAGEMENT vrf-target target:21949:21949 >>>>>> >>>>>>> On Jul 7, 2016, at 6:07 PM, Clinton Work <[email protected]> wrote: >>>>>>> >>>>>>> I would still use lo0.0 as your always up in-band mgmt interface. >>>>>>> JunOS doesn't support putting management into a routing-instance and I >>>>>>> have been pushing Juniper for this. You can use inet.0 for management >>>>>>> and additional logical routers for data traffic, but that is different >>>>>>> than a Cisco management VRF. >>>>>>> >>>>>>> JunOS doesn't have an explicit control-plane interface and you attach >>>>>>> your control-plane filter to lo0.0 instead. >>>>>>> >>>>>>> -- >>>>>>> Clinton Work >>>>>>> Airdrie, AB >>>>>>> >>>>>>> On Thu, Jul 7, 2016, at 11:52 AM, Jason Lixfeld wrote: >>>>>>>> Hey there, >>>>>>>> >>>>>>>> Coming from a Cisco background, I generally assign a loopback interface >>>>>>>> as my in-band management channel. I stick that into my management VRF >>>>>>>> and that’s that. Without knowing any better, my instinct would be to >>>>>>>> do >>>>>>>> the same in JunOS, but it seems as though lo0 is the control plane >>>>>>>> interface between user space and the re. That feels somewhat different >>>>>>>> to me, because the Cisco equivalent is generally the control-plane >>>>>>>> “interface”. >>>>>>> >>>>>>>> >>>>>>>> So my question is what the best common practise is for an always-up, >>>>>>>> in-band management channel on JunOS in an exclusively L3 environment >>>>>>>> (i.e.: no vlan or irb interfaces used at all in the system) without >>>>>>>> fully understanding whether that could also be lo0.0, or whether it >>>>>>>> should be lo0.somethingelse, or whether it should be something else >>>>>>>> entirely. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>> >> > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
