Re: [j-nsp] eve-ng - lab environment
Cool, yeah, my gosh I like eve more than lsys at this point -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eve-ng - lab environment
The new jcl (Juniper Cloud labs) looks like a lot to eve ng, hope to give it a look soon. Le lundi 16 juillet 2018, Christian Scholz a écrit : > Welcome to the world of EVE. > I prepped my JNCIE purely with EVE ;) > > > > > > Am 16.07.2018 um 14:16 schrieb Aaron Gould : > > > > Oh my gosh, Eve-ng is awesome! If you didn't know about it, you gotta > try > > it. It's so cool in its ability to run vSRX and vMX so far in my > testing. > > In only a short couple days I've been able to test the following. > > > > - mpls martini l2circuits using ldp > > - mpls vpls bgp ad/ldp sig (rfc4762) > > - mpls vpls bgp ad/bgp sig (rfc4761) > > - mpls evpn (my first look ever!) > > - mplsogre (my first look ever in junos!) > > > > I wanted to see it run L2 bridging technologies since I had so much > > unsuccess in my previous GNS3 attempts over the last few years (I may > have > > never set up the virtual l2 fwd'ing plane in gns3 like I should have) > > > > incase you want to take a look. > > > > http://eve-ng.com > > > > > > > > I had to take a moment and share about this. It's so clean and elegant > in > > how it runs and works. > > > > > > > > -Aaron > > > > ___ > > 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 > -- Vincent Clément +33 6 74 49 66 30 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eve-ng - lab environment
Welcome to the world of EVE. I prepped my JNCIE purely with EVE ;) > Am 16.07.2018 um 14:16 schrieb Aaron Gould : > > Oh my gosh, Eve-ng is awesome! If you didn't know about it, you gotta try > it. It's so cool in its ability to run vSRX and vMX so far in my testing. > In only a short couple days I've been able to test the following. > > - mpls martini l2circuits using ldp > - mpls vpls bgp ad/ldp sig (rfc4762) > - mpls vpls bgp ad/bgp sig (rfc4761) > - mpls evpn (my first look ever!) > - mplsogre (my first look ever in junos!) > > I wanted to see it run L2 bridging technologies since I had so much > unsuccess in my previous GNS3 attempts over the last few years (I may have > never set up the virtual l2 fwd'ing plane in gns3 like I should have) > > incase you want to take a look. > > http://eve-ng.com > > > > I had to take a moment and share about this. It's so clean and elegant in > how it runs and works. > > > > -Aaron > > ___ > 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
Re: [j-nsp] How to maintain scripts
Saku Ytti writes:
> Generally yes. But then there are some debatable things like IP
> options and DHCP snooping. Which are transit, but subject to RE. So
> should they be subject to LO0, or should you just police them in
> forwarding-filters? I believe latter, Juniper seems to think former.
I must admit I don't care much either way. My problem is that RE traffic
is subject to BOTH interface ingress filters AND lo0 ingress filters,
and similarly on egress you have to permit RE traffic outbound.
I often need an ACL that says "this interface cannot talk to/receive
traffic from RFC1918". Easily implemented for ingress traffic in two
terms with something like:
term reject-rfc1918 {
from {
destination-address 10.0.0.0/8;
destination-address 172.16.0.0/12;
destination-address 192.168.0.0/16;
}
then discard;
}
term accept-all {
then accept;
}
(plus the obvious reverse for the egress filter).
Unfortunately that breaks DHCP, ping to the router interfaces, dynamic
routing, and undoubtedly other things, if the interface address is in
RFC1918 space.
This is a needless pain, since it means I have to implement the same
rules twice: Once in lo0, and once in the interface filter. And I cannot
even do it with apply-groups, I have to actually build the appropriate
filter with the right set of interface addresses, and update it when the
list changes.
/Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to maintain scripts
On Mon, 16 Jul 2018 at 16:32, Benny Lyne Amorsen wrote: > Ideally JunOS should offer another way of distinguishing between forward > traffic and locally-terminated/originated traffic in ACL's, without > having to rely on getting lists of IP addresses correct. The box knows > whether it is terminating the traffic or not. Just let me filter based > on that... (I know, it is not that easy to implement in practice.) Generally yes. But then there are some debatable things like IP options and DHCP snooping. Which are transit, but subject to RE. So should they be subject to LO0, or should you just police them in forwarding-filters? I believe latter, Juniper seems to think former. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to maintain scripts
Pavel Lunin writes: > It's not maintaining scripts which is a bit of pain. It's on-box automaton > which is hell a lot of pain and there is very little reason to use it > nowadays. At least at any larger scale than a SOHO gateway for ten users, > doing something useless. That is all the more reason why JunOS should have a way to make an apply-group out of all local IP addresses without having to resort to full-blown scripting. Ideally JunOS should offer another way of distinguishing between forward traffic and locally-terminated/originated traffic in ACL's, without having to rely on getting lists of IP addresses correct. The box knows whether it is terminating the traffic or not. Just let me filter based on that... (I know, it is not that easy to implement in practice.) /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
On 12/Jul/18 23:07, Pavel Lunin wrote: > That's normal. Government and financial sectors always use the most > outdated solutions because of bureaucracy, compliance, certifications and > all those WTF reasons :) Probably with a big fat vendor (or vendor-partner) 10-year management & support contract to boot :-)... Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
On 12/Jul/18 18:46, Phil Bedard wrote: > This is from an industry perspective and not specific to Juniper. BIER won't > really happen without hardware support which is coming but will not be > compatible with a lot of already deployed hardware. Yes, this is what I have found so far, making the case to switch from IGP + MPLS to SR a bit less straightforward for existing operations, especially those currently running Multicast (legacy or NG-MVPN). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] eve-ng - lab environment
Oh my gosh, Eve-ng is awesome! If you didn't know about it, you gotta try it. It's so cool in its ability to run vSRX and vMX so far in my testing. In only a short couple days I've been able to test the following. - mpls martini l2circuits using ldp - mpls vpls bgp ad/ldp sig (rfc4762) - mpls vpls bgp ad/bgp sig (rfc4761) - mpls evpn (my first look ever!) - mplsogre (my first look ever in junos!) I wanted to see it run L2 bridging technologies since I had so much unsuccess in my previous GNS3 attempts over the last few years (I may have never set up the virtual l2 fwd'ing plane in gns3 like I should have) incase you want to take a look. http://eve-ng.com I had to take a moment and share about this. It's so clean and elegant in how it runs and works. -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
