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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 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 <clin...@scripty.com> 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 juniper-nsp@puck.nether.net >>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>>> _______________________________________________ >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
