> On Jan 3, 2019, at 3:34 PM, Saku Ytti wrote:
>
> On Thu, 3 Jan 2019 at 22:23, Jason Lixfeld wrote:
>
>> If you match on specific source (and presumably specific destination)
>> addresses, why is a directionally agnostic port match bad? Or is it not so
>> much bad as it is being too lazy
On Thu, 3 Jan 2019 at 22:50, Anderson, Charles R wrote:
> Thanks. I assume the same problem exists if you have VRF loopback
> interfaces inside the VPN as well (e.g. OSPF router-id loopbacks for
> the customer's VPN). So the idea is to restrict the destinations to
> ones that will never exist
On Thu, Jan 03, 2019 at 10:38:50PM +0200, Saku Ytti wrote:
> On Thu, 3 Jan 2019 at 22:32, Anderson, Charles R wrote:
>
> > > > c) always match destination-address if you're running L3 MPLS VPNs
> > >
> > > I must be misunderstanding because I’m sure you’re not suggesting that in
> > > the
On Thu, 3 Jan 2019 at 22:32, Anderson, Charles R wrote:
> > > c) always match destination-address if you're running L3 MPLS VPNs
> >
> > I must be misunderstanding because I’m sure you’re not suggesting that in
> > the absence of L3VPNs, omitting destination address matching is acceptable?
>
>
On Thu, 3 Jan 2019 at 22:23, Jason Lixfeld wrote:
> If you match on specific source (and presumably specific destination)
> addresses, why is a directionally agnostic port match bad? Or is it not so
> much bad as it is being too lazy to create a second term or an established
> filter/term?
On Thu, Jan 03, 2019 at 03:23:34PM -0500, Jason Lixfeld wrote:
> > At least the O'Reilly RE filter example is not only poor design but
> > also broken, for using stuff like 'match port bgp’.
>
> If you match on specific source (and presumably specific destination)
> addresses, why is a
Hi,
> On Jan 3, 2019, at 2:47 PM, Saku Ytti wrote:
>
> Hey,
>
>> I’ve noticed that publication is a little more liberal in it's RE filtering
>> suggestions vs. say, Juniper MX Series, O’Reilly.
>>
>> Having dug through both, the Juniper guide seems more platform agnostic,
>> which probably
Hey,
> I’ve noticed that publication is a little more liberal in it's RE filtering
> suggestions vs. say, Juniper MX Series, O’Reilly.
>
> Having dug through both, the Juniper guide seems more platform agnostic,
> which probably contributes to why it’s more liberal (variations in
>
Hi all,
Would the Day-Zero Hardening JunOS, 2nd Edition publication be the defecto BCP
for RE filter hardening?
I’ve noticed that publication is a little more liberal in it's RE filtering
suggestions vs. say, Juniper MX Series, O’Reilly.
Having dug through both, the Juniper guide seems more
I have a 10k8 that's showing "data error" discards in `show pfe
statistics traffic`. JTAC gave me the very unhelpful suggestion to run
packet captures and try and guess what's getting dropped, which isn't
really something that's feasible to do (nor am I even sure the packets
would show up
Hi!
According to Juniper documentation, MX series routers support
analyzers([edit forwarding-options analyzer]) since Junos OS Release
14.1 and one can mirror frames entering and exiting the port. However,
when I tested this with vMX running Junos 18.2R1.9, then I encountered
following
11 matches
Mail list logo
