Re: [j-nsp] NETCONF in Junos
> > Looks like an implementation issue. Our UI infrastructure allows > our programmers to define completion functions to list acceptable > values. Some schmuck's coded the completion function as this "sh -c show > route summary| ..." command. > > This is definitely not typical. More typically, we run something like > "ifinfo -n" or look at internal MGD info. This completion for the "table" > argument is just some suboptimal code. > > Note that the ssh-connection information being logged does not mean > that we're invoking a new ssh session, just that we're reporting > the current info. Huh. Interesting. Now that explains why it logs in as root but shows my ssh connection data. It does incur a huge performance penalty even without ssh though. My script that goes through all border routers and asks them for routes from all bgp peers to a specific destination was extremely slow until I've removed " table inet.0" from it, so I thought that it might actually ssh to itself in some strange way. Then again, it starts cli as root which is an expensive operation in itself. Well...every system has its quirks. And was written by people, some of whom are lazy and/or motivated by deadline. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF in Junos
Sometimes it does strange stuff with SSH internally though. Example: Let's say I do " show route table ?" at a router. Logs show: mgd[62935]: UI_CHILD_START: Starting child '/bin/sh' mgd[68498]: UI_AUTH_EVENT: Authenticated user 'root' at permission level 'super-user' mgd[68498]: UI_LOGIN_EVENT: User 'root' login, class 'super-user' [68498], ssh-connection ' 60259 22', client-mode 'cli' mgd[68498]: UI_CMDLINE_READ_LINE: User 'root', command 'show route summary | display xml | grep table-name ' mgd[68498]: UI_LOGOUT_EVENT: User 'root' logout mgd[62935]: UI_CHILD_STATUS: Cleanup child '/bin/sh', PID 68494, status 0 Obviously I don't login under root, but somehow my CLI spawns a shell, then sshes to itself under root (?) using my credentials (?) to do a single command. Then it logs out. Every time I request something about route tables. I'm still puzzled why it can't do that in my CLI session. On 21.12.2015 12:04, Matt Bernstein via juniper-nsp wrote: > On 21/12/2015 08:57, Martin T wrote: >> Thanks! So as I understand, the general idea is that it doesn't matter >> much for Junos if the command is executed in the CLI or from the >> remote(management server) NETCONF manager, i.e. Junos is basically >> built around the NETCONF? However, local calls(for example if one >> executes "show version" in Junos CLI) do not travel internally over >> SSH as remote calls would, do they? > Yes. the Junos CLI can itself be considered a (really nice) NETCONF > wrapper. It makes me idly wish other vendors' NETCONF implementations > were good enough that the Junos CLI could be used on them! > > I doubt the CLI uses SSH internally, but I suppose it wouldn't really > matter if it did. > > Matt > ___ > 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] SRX performance
Can anyone share real world SRX performance? ?I am looking at the SRX220 or SRX240 for a small website ~150-200Mbps in a co-location environment. The performance charts state the SRX220 can do 300Mbps with a mix of traffic and up to 900Mbps with mostly large packet sizes. SRX240 can give required bandwidth but it has no redundant power. Anyway, I don't think it's a good idea, see below. > If you go down the path of an SRX240 I’d suggest using the > screen features and tuning it for your needs. It can really > save the device from dealing with junk / attack traffic at > higher levels. Can’t help you with a 100Gbps DDoS but can > help deal with SYN floods and other junk. Um. No. It'll die under SYN flood even faster than a server would. I've tested its screen options against SYN floods and it's pathetic, epsecially compared to what a Linux box with synproxy can do. Not surprising, SRX CPU is very slow compared to Xeons and it can't offload everything. That "other junk" will probably kill it as well. Even 550/650 or "datacenter" models are not robust enough because state exhaustion attacks are easy and cheap. Magic "screen" is far from a panacea. Any stateful firewall in datacenter is just a fragile SPOF that will eventually keep over, taking your whole setup with it. With that said, SRX is a very nice box when it's used correctly. I have lots of them in branch offices and some in datacenter, but I wouldn't put it before servers expecting them to hold their ground under attack. And I'm not bashing SRXes specifically, I'm talking about any stateful firewall from any vendor, they all suck. Don't use stateful firewalls before servers. Ever. Grab an l3 switch and do stateless filtering at ingress and filter everything else on servers. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104
Some RE-S-1800X4, yeah. ASR9k has RSP440, so quad core x86 as well. Comparable I think. Not sure about 7600 but definitely something old. 02.12.2015 19:18, Colton Conor пишет: Stephen, Which RE is that on the MX480? The RE2000 or the quad core one? On Wed, Dec 2, 2015 at 4:42 AM, Stepan Kucherenko <t...@megagroup.ru <mailto:t...@megagroup.ru>> wrote: Should've put it here in the first post, got already asked about it offlist couple of times. I was testing it on MX80 with slow RE, so obviously numbers will change on faster REs but difference will still be there. ~1.5min taking full table from MX480 (nice RE, 85k updates) ~3min from 7600 (old and slow RE, 89k updates) almost 5min from ASR9k (nice RE, 450k updates) It'll be even more noticeable when Junos will be able to run rpd on a dedicated core. Keep in mind that it's still not actual convergence time, Junos is still lagging with FIB updates long after that. Sadly I was unable to find my old convergence test numbers but krt queue was dissipating for at least couple of minutes after BGP converged. I case you're wondering if it was the known rpd bug with low krt priority - no, I tested it after it was fixed. Not that I'd call it "fixed". And that's what I don't like about MX-es :-) Not sure if it's faster or slower on ASR9k though. On 02.12.2015 12:30, James Bensley wrote: On 1 December 2015 at 17:29, Stepan Kucherenko <t...@megagroup.ru <mailto:t...@megagroup.ru>> wrote: My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped grouping BGP prefixes in one update if they have same attributes so it's one prefix per update now (or sometimes two). Transit ISP we tested it with pinged TAC and got a response that it's "software/hardware limitation" and nothing can be done. I don't know when this regression happened but now taking full feed from ASR9k is almost twice as slow as taking it from 7600 with weak RE and 3-4 times slower than taking it from MX. I'm not joking, test it yourself. Just look at the traffic dump. As I understand it, it's not an edge case so you must see it as well. In my case it was 450k updates per 514k prefixes for full feed from ASR9k, 89k updates per 510k prefixes from 7600 and 85k updates per 516k prefixes from MX480. Huge difference. It's not a show stopper but I'm sure it must be a significant impact on convergence time. How long timewise is it taking you to converge? Last time I bounced a BGP session to a full table provider it took sub 1 minute to take in all the routes. I wasn't actually timing so I don't know how long exactly. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto: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] Cisco ASR 9001 vs Juniper MX104
Should've put it here in the first post, got already asked about it offlist couple of times. I was testing it on MX80 with slow RE, so obviously numbers will change on faster REs but difference will still be there. ~1.5min taking full table from MX480 (nice RE, 85k updates) ~3min from 7600 (old and slow RE, 89k updates) almost 5min from ASR9k (nice RE, 450k updates) It'll be even more noticeable when Junos will be able to run rpd on a dedicated core. Keep in mind that it's still not actual convergence time, Junos is still lagging with FIB updates long after that. Sadly I was unable to find my old convergence test numbers but krt queue was dissipating for at least couple of minutes after BGP converged. I case you're wondering if it was the known rpd bug with low krt priority - no, I tested it after it was fixed. Not that I'd call it "fixed". And that's what I don't like about MX-es :-) Not sure if it's faster or slower on ASR9k though. On 02.12.2015 12:30, James Bensley wrote: On 1 December 2015 at 17:29, Stepan Kucherenko <t...@megagroup.ru> wrote: My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped grouping BGP prefixes in one update if they have same attributes so it's one prefix per update now (or sometimes two). Transit ISP we tested it with pinged TAC and got a response that it's "software/hardware limitation" and nothing can be done. I don't know when this regression happened but now taking full feed from ASR9k is almost twice as slow as taking it from 7600 with weak RE and 3-4 times slower than taking it from MX. I'm not joking, test it yourself. Just look at the traffic dump. As I understand it, it's not an edge case so you must see it as well. In my case it was 450k updates per 514k prefixes for full feed from ASR9k, 89k updates per 510k prefixes from 7600 and 85k updates per 516k prefixes from MX480. Huge difference. It's not a show stopper but I'm sure it must be a significant impact on convergence time. How long timewise is it taking you to converge? Last time I bounced a BGP session to a full table provider it took sub 1 minute to take in all the routes. I wasn't actually timing so I don't know how long exactly. Cheers, James. ___ 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] Cisco ASR 9001 vs Juniper MX104
My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped grouping BGP prefixes in one update if they have same attributes so it's one prefix per update now (or sometimes two). Transit ISP we tested it with pinged TAC and got a response that it's "software/hardware limitation" and nothing can be done. I don't know when this regression happened but now taking full feed from ASR9k is almost twice as slow as taking it from 7600 with weak RE and 3-4 times slower than taking it from MX. I'm not joking, test it yourself. Just look at the traffic dump. As I understand it, it's not an edge case so you must see it as well. In my case it was 450k updates per 514k prefixes for full feed from ASR9k, 89k updates per 510k prefixes from 7600 and 85k updates per 516k prefixes from MX480. Huge difference. It's not a show stopper but I'm sure it must be a significant impact on convergence time. On 01.12.2015 20:08, heasley wrote: Tue, Dec 01, 2015 at 04:23:33PM +0200, Mark Tinka: XR is very JunOS like. Hmmmh, not quite. There are still some major cosmetic differences, and a few similarities, and definitely different fundamental architectural principles. Both are okay for their platforms, but I wouldn't go as far as saying they "alike". I believe that they are vastly different; just from a usability/user-friendly PoV, though both have blemishes. ___ 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] Where and how to inject the default route in DFZ
I just use a generated 0/0 route which is active only if I receive specific prefixes from upstream(s). If you don't want 0/0 in FIB then just add no-install. Not perfect but better than no delay at all. I wish I could say something like "thos route is active when there are X routes received from this neighbor(s) and they're already in FIB" but I didn't find anything like that either. On 26.11.2015 18:30, Mark Smith wrote: Hi list This is best explained by an example. Router R1 has a full bgp table (~550k prefixes). R1 needs to announce a default route using OSPF and BGP. The worst issue is when R1 boots up. Assume there is a static 0/0 route to discard. R1 brings up OSPF adjacencies and starts announcing 0/0. Blackhole. Next R1 brings up BGP adjacencies and starts announcing 0/0. Another blackhole. Only after R1 has received the complete route table (and pushed all prefixes to FIB) will the blackhole disappear. What's the best solution to work around this? Where and how do you generate the default? With OSPF or ISIS one can use overload w/ timeout. It works. What about BGP? out-delay? One can use "routing-options generate route ..." for default. But what prefix to use as contributing route? One can announce a dummy prefix from e.g. RR, but still this does not guarantee that R1 has all necessary routes (in FIB) before announcing default. And this probably leads to transient routing loop while R1 has default pointing to e.g. loopback of RR, but routers in between see the OSPF default announced by R1. Overload timeout + generate default? Thanks ___ 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] Multi Core on JUNOS?
This would allow set-ish style (since the UI really doesn't need the
braces on input) as well as allowing the placement of comments:
[edit]
cli# load terminal merge interactive
[Type ^D at a new line to end input]
protocols bgp /* foo is cool */ group foo /* local-as is also */ local-as 42;
/* You can also put braces here */
protocols {
bgp {
/* goo is not */
group goo { local-as 51; }}}
^D
load complete
Is it possible to delete last line(s) ? If yes then this way of
configuring something will become the only one I will use all the time. :-)
I think it's great.
But I need to work out what (and how) would get redrawn when you
type "?" deep under braces (like at the "51" above). I can't emit
the [edit] line, but just redrawing the current line doesn't give
the context the way I'd like it to. Perhaps a distinct key to give
the content-as-edit-line?
I'd be happy even with the current line. But maybe someone else will
have more ideas ?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
On 22.10.2015 22:37, Phil Shafer wrote:
> Stepan Kucherenko writes:
>> What else...oh, annotate ! It's clunky and not very easy to use.
>
> Yes, annotate is a sore spot. I made the grammar production:
>
> K_ANNOTATE annotate_target T_STRING
>
> with the expectation that I'd be able to coerce a path into the
> target, but it didn't happen. I should have done it as:
>
> K_ANNOTATE T_STRING annotate_target
>
> and then allow anything as a target, like:
>
> cli# annotate "Client X" interfaces ge-0/0/0.0 family inet address
> 1.2.3.4/5
>
> but can't make that work without making a new command ("comment"?).
>
>> I wish we could just add a comment in the end of a line instead, like
>> "set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and
>> then see "x.x.x.x/y //client X" and the same line when asking for
>> |display set.
>
> We generate line comments in JUNOS, so we need to discard them (and
> comments before close braces) to prevent out-of-date comments from
> getting loaded as real annotations.
>
> Hmm I should make a M-, keybinding to copy all arguments from the
> previous command so you can:
>
> [edit interfaces ge-0/0/0 unit 0]
> cli# set family inet address 1.2.3.4/5
>
> [edit interfaces ge-0/0/0 unit 0]
> cli# comment "Client X" [ESC-,]
>
> and it will insert the "family inet address 1.2.3.4/5" from
> the previous "set" command.
>
> This is similar to the existing M-. and M-/ bindings.
So when we say show interfaces ge-0/0/0.0 we'll see something like
family inet {
/* Client X */
address 1.2.3.4/5;
}
But let's say we want to add another address for another client
[edit interfaces ge-0/0/0 unit 0]
cli# set family inet address 6.7.8.9/10
[edit interfaces ge-0/0/0 unit 0]
сli# comment "Client Y" [ESC-,]
family inet {
/* Client Y */
address 1.2.3.4/5;
address 6.7.8.9/10;
}
Correct ?
I was thinking of something like that:
[edit]
cli# set interfaces ge-0/0/0.0 family inet address 1.2.3.4/5 // Client X //
[edit]
cli# set interfaces ge-0/0/0.0 family inet address 6.7.8.9/10 // Client Y //
[edit]
cli# show interfaces ge-0/0/0.0
family inet {
address 1.2.3.4/5; // Client X //
address 6.7.8.9/10; // Client Y //
}
Or maybe set interfaces ge-0/0/0.0 family inet address 1.2.3.4/5 comment
"Client X" instead of "//", or /* Client X */ in "show" output, whatever,
it'll be cosmetic anyway.
Basically the same as descr command but available at any hierarchy level for
any element but which doesn't use a separate line. Configurations are way too
big already and separate line comments will eat into precious screen real
estate.
It'll be easier to parse, easier to work with, will stay in the configuration
with the same rules as everything else, it'll be deleted after deleting the
element it comments and it won't be necessary to say "edit interfaces
ge-0/0/0.0" first to work with it, you'll be able to do it from top (inability
to do that probably annoys me the most in annotate).
Maybe even something like
set protocols bgp group ix-v4 type external import [ reject-some-prefixes
///don't like them// set-community //for further filtering// ] peer-as X
neighbor 1.2.4.5 //location// export customers-only //please don't delete this//
then if we say show protocols bgp group ix-v4 we'll get:
type external;
import [ reject-some-prefixes ///don't like them// set-community //for further
filtering// ];
peer-as X;
neighbor 1.2.4.5 //location// {
export customers-only; //please don't delete this//
}
Or with |display set:
set protocols bgp group ix-iv type external
set protocols bgp group ix-iv import reject-some-prefixes ///don't like them//
set protocols bgp group ix-iv import set-community //for further filtering//
set protocols bgp group ix-iv peer-as X
set protocols bgp group ix-iv neighbor 1.2.4.5 //location//
set protocols bgp group ix-iv neighbor 1.2.4.5 export customers-only //please
don't delete this//
Makes sense ?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multi Core on JUNOS?
If we're speaking about "quality of life" stuff then I wish JunOS/FreeBSD traceroute would stop adding source routing bit when you include source interface/gateway/bypass-routing. It's being filtered EVERYWHERE in real world so it's not possible to look at the second-best route via non-active path, it's either best route or guessing. Or maybe I'm missing something ? Also fractional interval in traceroute monitor (=mtr), I always use -i 0.1 or even less in real life for faster drop detection but can't do the same in Junos even if it's the same mtr. What else...oh, annotate ! It's clunky and not very easy to use. I wish we could just add a comment in the end of a line instead, like "set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and then see "x.x.x.x/y //client X" and the same line when asking for |display set. I'm sure you guys can add even more stuff like that. It's small but I think it's still important. And a low-hanging fruit in many cases :-) On 22.10.2015 15:33, Doug McIntyre wrote: On Thu, Oct 22, 2015 at 08:51:10AM +0200, Mark Tinka wrote: On 22/Oct/15 00:40, Chad Myers wrote: And finally putting commas in the monitor interface traffic output. Or just use the correct units of measurement, e.g., Kbps, Mbps, Gbps and Tbps :-). I so wish there was a '-h' flag to 'monitor interface' that did that.. ___ 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] SRX240 for route-reflector?
No. Just don't. SRX has 1 weak MIPS CPU for control plane and it's incredibly slow (commits took ages). Just get a couple of vMX/vRR and use them as a VM on a non-outdated x86 server, it'll work great. On 17.08.2015 08:34, Alex K. wrote: Hello all, One of my colleagues suggested using SRX240 us a route-reflector in our network. Since I've never seen SRX in such deployment, I'll be glad to know your opinion on that. The requirements are - MPLS VPN, L2VPN support (both VPLS and Pseudo wires) and multicast VRFs support. It is worth mentioning, the network comprised of both Cisco and Juniper gear. Every thought on the subject will be welcomed. ___ 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] Upgrading firmware on an EX 4300 virtual chassis?
I was doing it through request system software nonstop-upgrade. Some drops were observed but overall it worked. The main gotcha I've found is that if you have LACP LAGs configured then change it to pediodic slow, otherwise you'll have up to 6 seconds of no LACP replies and LAG shuts down even if it can pass traffic. Not sure about older 13.2 versions, I was testing NSSU between latest 13.2 and latest 14.whatever, both upgrades and downgrades. On 27.05.2015 18:00, Scott Granados wrote: Hi, I’ve downloaded the latest recommended firmware from the web site which is indicated as jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz. I’ve been googling and keep finding procedures for upgrading that involve NSSU which I’ve seen go very badly all be it quite a while ago, before the feature was supported. Will the normal method work? Will something like the following do the job request system software add /var/tmp/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz validate no-copy Once completed and valided request system reboot Will this fit the bill or do I have to use the new procedures? If this will work is there any need to define all members or is that assumed? What’s my best upgrade procedure to proceed? Also, any comments on the version that the site presented as acceptable, should I go with this release or is something else more preferred? I’m presently running a buggy version of 13.2 that was shipped with the devices. Any pointers would be most appreciated. Thank you Scott ___ 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] MX80 IPSEC VPN
I do. And would recommend you to stick to SRX instead. It'll probably be much cheaper as well. MX/MS-MIC works but I've spent too much time to get to that point. It's less documented, less used so Google can't help you, it's different, it doesn't play well with others, it was probably designed with a different use case in mind, and so on and so on. I wish someone said that a year ago somewhere so I wouldn't do that myself. Or you can get it, help Juniper to debug their problems, write blog posts about it somewhere and make it more useful for others, your choice :-) On 29.04.2015 14:51, Drew Weaver wrote: Does anyone have any real world experience in using MS-MIC-16G in an MX80 in order to create VPN tunnels? We are considering using an MX80 for a AWS direct connect and we want to make sure that we can also have a VPN backup incase the physical link goes down. Thanks in advance. -Drew ___ 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] MS-MIC-16G Licenses
We've bought JSAM licenses but it looks like they aren't enforced (yet?). I didn't even install them. Although I have to say its usage is low right now so I don't know if it will hold true later. Default MX5 licenses are subscriber/l2tp/mobile ip and those probably are enforced. As for what is better...it's hard to say. I know a fixed ISP doing CGN on MX480 with MS-MPC and it works okay, they definitely are happy to finally throw away their Linux NAT boxes. I also know a mobile ISP doing CGN for mobile customers on SRX because it happened to be cheaper for them. Don't know which SRX model though. So apparently both approaches work. Although personally I'd prefer SRXes, if only because I've spent too much time debugging the MX80/MS-MIC combination. SRX1400 or SRX3400 would probably be the closest to MS-MIC16 but again it's hard to say because the only number I saw on MS-MIC is up to 9Gbps of service throughput. Not very informative, especially compared to detailed SRX datasheets. On 29.04.2015 16:24, Colton Conor wrote: Does anyone have any clarification on if the MS-MIC-16G has any included licenses by default? For example, if I buy a MS-MIC-16G off ebay or used form somewhere else, and slide it into the back of a MX5 router. Will any of the MS-MIC-16G features function? Are there any default included licenses that you don't have to enter, but just work? Looking at the Juniper datasheet there are multiple licenses: JAA-NAT Junos Address Aware CGNAT JTV-FLOW Junos Traffic Vision J-FLOW JVPN-E Junos VPN Site Secure IPSEC JNS-FW Junos Network Secure [Stateful Firewall] JSAM Juniper Secure Address Management (NAT, Jflow, IPsec, SFW) I know the MX 5 for example includes some licenses by just buying the box that you don't necessarily have to enter. For example, inline J-flow 5G license is included, works, but doesn't show up on a show licenses command. Is the MS-MIC-16G better than a SRX for IPSEC, NAT, and Firewall functions? Which SRX model is closest to a MS-MIC-16G price/feature wise? ___ 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] SRX VPN in Virtual Router
I have a similar configuration. WAN0 and st0.0 (glued to WAN0) in inet.0, WAN1 and st0.1 (glued to WAN1) are in a VR. Works okay. On 30.03.2015 17:03, M Abdeljawad via juniper-nsp wrote: Hi All I have a question about SRX VPN support under virtual router;There are two WAN links and each link member in different Virtual Router (not inet0), and the VPN tunnels must be established from both virtual routers Per to my search I found two conflict results as below; Below KB link mention that its supported, and the st0interface and the IKE listener interface can be assigned to the custom virtualrouter. http://kb.juniper.net/InfoCenter/index?page=contentid=KB21487 And below document link mention that the IKE listener mustbe member of inet.0 for the VPN to work. http://www.juniper.net/documentation/en_US/junos11.4/topics/concept/virtual-router-support-for-route-based-vpns.html What if I used Lo0 interface and assigned it to inet.0 andused it as the external VPN interface, is this valid solution? RegardsMahmoud ___ 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] configuration archival, commit comments
We use an in-house script that checks the archive directory and if there
are new files then:
1) it logs in to a juniper host via ssh
2) asks for show system commit (the only command it can issue)
3) gets username and comments for previous commits
4) pushes everything new to git, adding username/comments.
I wish it was included in the archived configuration as well so we won't
have to do a workaround, but you can't get everything.
On 11.11.2014 05:46, Stefan Cioata wrote:
Hello everyone,
The only partial reference to my problem that I found on the net was posted
by:
Author Message
Mike Williams
PostPosted: Thu Mar 20, 2014 1:50 pmPost subject: configuration
archival, commit comments
Here is my challenge:
a) I use system archival
stefan@stefan_test_desktop show configuration system archival
configuration {
transfer-on-commit;
archive-sites {
scp://backup@x.y.z.w:/data/backup/ password
$9$a9JjqTz6ApBGDi.f56/; ## SECRET-DATA
}
}
b) the file arrives at the destination with the user striped:
[root@anetlogger backup]# zcat
stefan_test_desktop_juniper.conf.gz_20140217_221525 | more
## Last changed: 2014-02-17 22:15:20 PST *by stefan is
missing!!!*
version 12.3R2.5;
/*
* $Id$
*
* ex4200-defaults.conf - Default configurations for EX4200
*
* Copyright (c) 2010, Juniper Networks, Inc.
* All rights reserved.
*/
groups {...
the backup file is different then:
stefan@stefan_test_desktop show configuration
## Last commit: 2014-11-10 14:40:52 PST by stefan*---The info is
there!!!*
c) I would like to implement git. That will require at minimum to have the
user on the .gz transferred file.
Any help would be more the apreciated.
Thank you,
Stefan
___
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] EX4600 Licensing
EX4300 datasheet says there are several licenses, AFL and EFL, for different versions of the switch. EFL is basically everything, OSPF, BFD, etc. AFL is BGP and IS-IS (no MPLS). EX4600 datasheet has only AFL license listed, required for BGP, IS-IS and MPLS. As far as I understand, everything else is included. So no, it's not the same as EX4300. Speaking of EX4600, it's basically the same chipset as in QFX5100. It can have 12 QSFP instead of 6, but still it's very similar. Anyone knows if there is any significant difference between QFX and EX lines on the software side ? If there is none and you can use QFX-es in SP environment without unexpected problems, and you don't need 12 QSFP, then you might want to look at QFX5100 instead. Price is lower (if we count additional QSFP mods for EX4600), and AFL license for QFXes is twice as cheap. On 08.09.2014 12:38, Skeeve Stevens wrote: Excellent. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering On 8 September 2014 12:44, Chris Jones ipv6fre...@gmail.com wrote: Not sure, but it's the same licensing as the EX4300. On Sun, Sep 7, 2014 at 7:52 AM, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Hi guys, Does anyone know when this page: http://www.juniper.net/techpubs/en_US/junos14.1/topics/concept/ex-series-software-licenses-overview.html will be updated for the EX4600. Thanks. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Chris Jones JNCIE-ENT #272 CCIE# 25655 (RS) ___ 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] Dynamic NAT and MS-MIC
Without MS-MIC/MS-MPC you can only do static 1:1 NAT. So yes, if you want dynamic stateful NAT, you'll have to buy a service card. On 03.07.2014 01:18, Nicholas Schmidt wrote: Hi All, I am evaluating a few options for upgrades to various bits of routing infrastructure. One of my requirements is a very basic dynamic source NAT for some hardware sitting on private address space to be able to communicate with the outside for small amounts of basic services such as OS updates and the like. Could anyone tell me if this requires the MS-MIC? The data sheets are worded very weirdly and I can’t tell if the MS-MIC is required for all NATing or just Carrier Grade NAT. Cheers, Nick ___ 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
