Re: [j-nsp] About RD in vpls multi-homing environment.
Hi Nat, You should always want to use unique RDs (possibly type-2 RD using router-id IP address) in any MPLS services when RRs are involved. RD as the name suggests makes the route (or any information carried) distinguishable/unique thus not subject for BGP best path selection. As you know BGP only advertises best-paths to its neighbours so if two sites advertise the same information to the RR -RR will select only one and advertise it to the rest of the AS -unless you make the otherwise same information unique by prepending it with a unique RD. AS you might rightly infer using unique RDs will increase the amount of information flooded to the PEs but the advantage, as Sebastian pointed out, is that PEs will have a backup route at hand and thus can use techniques to fast failover to the backup path if the primary path is down. adam -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Pyxis LX Sent: 11 April 2015 19:18 To: juniper-nsp@puck.nether.net Subject: [j-nsp] About RD in vpls multi-homing environment. Hi, All. I am not sure whether PEs connected to the same vpls site should be configured with the same RD or not. JNCIS-SP Study Guide Part 3 P.415 states that both PE connected to the same site should be configured with the same RD. (The topology chart is available at P.409, PE2 PE3 connect to the same site) However, when I configure them with the same RD, PE3 will not announce any l2vpn routes to other PEs, is that normal? And I found another configuration example on Juniper website: http://www.juniper.net/documentation/en_US/junos14.2/topics/topic- map/vpls-bgp-multihoming.html This example suggests that PE1 and PE2 should use different RDs. Which one is correct, or I take the wrong example? Thank You. -Nat ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
Hi Sukhjit, Why don't you use local template accounts to accomplish that? http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configuration/authentication-user-local-template-account-configuring.html ACS should be able to push 'local-username' attribute via tacacs+. HTH, Ivan, On Mon, Apr 13, 2015 at 11:58 PM, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: yeah I've used this too and depending on the local profile it shows what I expect it too, but what it doesn't show is minus the ACS attributes if at all I would see that here... I think a deeper packet inspection can identify what the messages are saying, will try to do that at some point On 13 Apr 2015, at 23:42, Chris Kawchuk juniperd...@gmail.com wrote: Show cli authorization. Should show you the current login credentials and such. On 14 Apr 2015, at 8:23 am, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: hi Chris thanks for the reply, actually I did not see any user file in /var/tmp whilst logged-in im running vSRX firefly 12.1X47-D10.4 On Mon, Apr 13, 2015 at 4:07 PM, Chris Morrow morr...@ops-netman.net wrote: On 04/13/2015 11:01 AM, Eduardo Barrios wrote: When I tested this a while back I could not get the allow-commands attribute to work. The deny-commands attribute does work however. So our ACS shell-profile read only group we had to start with a junos login with a super-user class then use the deny-commands attribute to strip the access ...request, restart, configure, etc. it might help you to look in /var/tmp on the juniper when the affected user is logged in.. there will be a file named per the user's login PID which has their access requirements outlined. You can probably reverse engineer the right answer from that data. ___ 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 -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
Hi Ivan The goal is for ACS to be able to control this otherwise I can argue what's the point in using ACS at all? There are attributes which are supposed to be working for which I don't understand technically why they are not i.e allowed-commands (check the link) On 14 Apr 2015, at 10:49, Ivan Ivanov ivanov.i...@gmail.com wrote: Hi Sukhjit, Why don't you use local template accounts to accomplish that? http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configuration/authentication-user-local-template-account-configuring.html ACS should be able to push 'local-username' attribute via tacacs+. HTH, Ivan, On Mon, Apr 13, 2015 at 11:58 PM, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: yeah I've used this too and depending on the local profile it shows what I expect it too, but what it doesn't show is minus the ACS attributes if at all I would see that here... I think a deeper packet inspection can identify what the messages are saying, will try to do that at some point On 13 Apr 2015, at 23:42, Chris Kawchuk juniperd...@gmail.com wrote: Show cli authorization. Should show you the current login credentials and such. On 14 Apr 2015, at 8:23 am, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: hi Chris thanks for the reply, actually I did not see any user file in /var/tmp whilst logged-in im running vSRX firefly 12.1X47-D10.4 On Mon, Apr 13, 2015 at 4:07 PM, Chris Morrow morr...@ops-netman.net wrote: On 04/13/2015 11:01 AM, Eduardo Barrios wrote: When I tested this a while back I could not get the allow-commands attribute to work. The deny-commands attribute does work however. So our ACS shell-profile read only group we had to start with a junos login with a super-user class then use the deny-commands attribute to strip the access ...request, restart, configure, etc. it might help you to look in /var/tmp on the juniper when the affected user is logged in.. there will be a file named per the user's login PID which has their access requirements outlined. You can probably reverse engineer the right answer from that data. ___ 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 -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
Hi Ivan Thanks for the additional information. But the fact remains we only use ACS for authentication and not authorisation, I want to be able to use ACS for authorisation control hence I need the additional attributes to work or at least understand why they don't when support is supposed to be in place. On 14 Apr 2015, at 11:26, Ivan Ivanov ivanov.i...@gmail.com wrote: Hi Sukhjit, The idea with local templates is that you configure couple of them or more with different privileges. Then using the ACS you control which user which template to inherit. If you look in the link you will see that those local templates look like users but they do not have authentication attached. So he only way to be used is if they are pushed from authentication server. For example you configure two templates with different privileges and assign hundred users from ACS to one of them and other hundred to the other. That is why they are called templates. This is usually how is done on Junos to have users with different privileges authenticated via RADIUS or TACACS+ servers. I hope now is more clear to you! Ivan, On Tue, Apr 14, 2015 at 11:08 AM, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: Hi Ivan The goal is for ACS to be able to control this otherwise I can argue what's the point in using ACS at all? There are attributes which are supposed to be working for which I don't understand technically why they are not i.e allowed-commands (check the link) On 14 Apr 2015, at 10:49, Ivan Ivanov ivanov.i...@gmail.com wrote: Hi Sukhjit, Why don't you use local template accounts to accomplish that? http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configuration/authentication-user-local-template-account-configuring.html ACS should be able to push 'local-username' attribute via tacacs+. HTH, Ivan, On Mon, Apr 13, 2015 at 11:58 PM, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: yeah I've used this too and depending on the local profile it shows what I expect it too, but what it doesn't show is minus the ACS attributes if at all I would see that here... I think a deeper packet inspection can identify what the messages are saying, will try to do that at some point On 13 Apr 2015, at 23:42, Chris Kawchuk juniperd...@gmail.com wrote: Show cli authorization. Should show you the current login credentials and such. On 14 Apr 2015, at 8:23 am, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: hi Chris thanks for the reply, actually I did not see any user file in /var/tmp whilst logged-in im running vSRX firefly 12.1X47-D10.4 On Mon, Apr 13, 2015 at 4:07 PM, Chris Morrow morr...@ops-netman.net wrote: On 04/13/2015 11:01 AM, Eduardo Barrios wrote: When I tested this a while back I could not get the allow-commands attribute to work. The deny-commands attribute does work however. So our ACS shell-profile read only group we had to start with a junos login with a super-user class then use the deny-commands attribute to strip the access ...request, restart, configure, etc. it might help you to look in /var/tmp on the juniper when the affected user is logged in.. there will be a file named per the user's login PID which has their access requirements outlined. You can probably reverse engineer the right answer from that data. ___ 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 -- Best Regards! Ivan Ivanov -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
Hi Sukhjit, The idea with local templates is that you configure couple of them or more with different privileges. Then using the ACS you control which user which template to inherit. If you look in the link you will see that those local templates look like users but they do not have authentication attached. So he only way to be used is if they are pushed from authentication server. For example you configure two templates with different privileges and assign hundred users from ACS to one of them and other hundred to the other. That is why they are called templates. This is usually how is done on Junos to have users with different privileges authenticated via RADIUS or TACACS+ servers. I hope now is more clear to you! Ivan, On Tue, Apr 14, 2015 at 11:08 AM, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: Hi Ivan The goal is for ACS to be able to control this otherwise I can argue what's the point in using ACS at all? There are attributes which are supposed to be working for which I don't understand technically why they are not i.e allowed-commands (check the link) On 14 Apr 2015, at 10:49, Ivan Ivanov ivanov.i...@gmail.com wrote: Hi Sukhjit, Why don't you use local template accounts to accomplish that? http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configuration/authentication-user-local-template-account-configuring.html ACS should be able to push 'local-username' attribute via tacacs+. HTH, Ivan, On Mon, Apr 13, 2015 at 11:58 PM, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: yeah I've used this too and depending on the local profile it shows what I expect it too, but what it doesn't show is minus the ACS attributes if at all I would see that here... I think a deeper packet inspection can identify what the messages are saying, will try to do that at some point On 13 Apr 2015, at 23:42, Chris Kawchuk juniperd...@gmail.com wrote: Show cli authorization. Should show you the current login credentials and such. On 14 Apr 2015, at 8:23 am, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: hi Chris thanks for the reply, actually I did not see any user file in /var/tmp whilst logged-in im running vSRX firefly 12.1X47-D10.4 On Mon, Apr 13, 2015 at 4:07 PM, Chris Morrow morr...@ops-netman.net wrote: On 04/13/2015 11:01 AM, Eduardo Barrios wrote: When I tested this a while back I could not get the allow-commands attribute to work. The deny-commands attribute does work however. So our ACS shell-profile read only group we had to start with a junos login with a super-user class then use the deny-commands attribute to strip the access ...request, restart, configure, etc. it might help you to look in /var/tmp on the juniper when the affected user is logged in.. there will be a file named per the user's login PID which has their access requirements outlined. You can probably reverse engineer the right answer from that data. ___ 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 -- Best Regards! Ivan Ivanov -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Problem with ether-type changing on QFX3500 VC
Hello,
I've got two QFX3500 in a virtual chassis with JunOS 13.2X51-D30.4.
I've upgraded from a standalone QFX3500 with JunOS 12.3X50-D30.2 where
I've got this statement:
ethernet-switching-options {
dot1q-tunneling {
ether-type 0x8100;
}
}
But after upgrading to 13.2 there's no even stanza
ethernet-switching-options in the configuration mode, although there's a
link in the documentation about it
(http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/ethernet-switching-options-qfx-series.html).
How can I change ether-type in JunOS 13.2?
Thanks in advance.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
On Apr 14, 2015, at 03:36, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: Hi Ivan Thanks for the additional information. But the fact remains we only use ACS for authentication and not authorisation, I want to be able to use ACS for authorisation control hence I need the additional attributes to work or at least understand why they don't when support is supposed to be in place. On 14 Apr 2015, at 11:26, Ivan Ivanov ivanov.i...@gmail.com wrote: Hi Sukhjit, The idea with local templates is that you configure couple of them or more with different privileges. Then using the ACS you control which user which template to inherit. If you look in the link you will see that those local templates look like users but they do not have authentication attached. So he only way to be used is if they are pushed from authentication server. For example you configure two templates with different privileges and assign hundred users from ACS to one of them and other hundred to the other. That is why they are called templates. This is usually how is done on Junos to have users with different privileges authenticated via RADIUS or TACACS+ servers. I hope now is more clear to you! Ivan, -- Best Regards! Ivan Ivanov Hi Sukhjit, JunOS does not support command authorization from TACACS+ or RADIUS, as far as I am aware. The method Ivan describes is the correct way to do authorization with JunOS. This is how we control authn/authz at my company (we also use ACS), and it works very well if you have some method of ensuring the user template configuration is correct across all your devices. (Some form of config auditing or automation, perhaps.) I realize that half the point of TACACS+ is per-command authz similar to how it works on Cisco IOS, but JunOS just doesn’t support that part of TACACS+. The only way to control authz via TACACS+/ACS is mapping users to local user templates. Justin Seabrook-Rocha -- Xenith || xen...@xenith.org || http://xenith.org/ Jabber: xen...@xenith.org || AIM: JustinR98 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] iBGP and IPv6
So I have a lab with two routers exchanging iBGP between them. They have both IPv4 and IPv6 addresses configured on the loopback. There aren't any export or import policies defined between the two. When I examine the routes for the local loopback interface on router1 I see the following: router1 show route 172.30.110.248 vr-1.inet.0: 15 destinations, 24 routes (15 active, 0 holddown, 2 hidden)+ = Active Route, - = Last Active, * = Both 172.30.110.248/32*[Direct/0] 6d 19:54:25 via lo0.1 [OSPF/10] 6d 19:54:20, metric 0 via lo0.1 router1 show route 172.30.110.248 hidden vr-1.inet.0: 15 destinations, 24 routes (15 active, 0 holddown, 2 hidden)+ = Active Route, - = Last Active, * = Both 172.30.110.248/32 [BGP ] 21:19:38, from 172.30.110.249 AS path: I Unusable This seems to be as expected. This is the IPv6 loopback route information: router1 show route 2001:db8:4000::1 vr-1.inet6.0: 9 destinations, 13 routes (9 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both 2001:db8:4000::1/128*[Direct/0] 6d 20:02:07 via lo0.1 [OSPF3/10] 6d 20:02:02, metric 0 via lo0.1 [BGP/170] 00:21:37, MED 1, localpref 100, from 2001:db8:4000::2 AS path: I to fe80:db8:4000:1::3 via ge-0/0/8.0 Why does the router flag the BGP route for the IPv4 loopback as Unusable but doesn't do the same for the IPv6 loopback address? Does it even matter? Jonathan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] iBGP and IPv6
On 14/Apr/15 19:37, Jonathan Call wrote: Why does the router flag the BGP route for the IPv4 loopback as Unusable but doesn't do the same for the IPv6 loopback address? Does it even matter? Can you show extensive for the route? Also, try formatting your paste better - I can't quite make it out. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Problem with ether-type changing on QFX3500 VC
Hi Andrew,
according to
http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/getting-started-els.html
http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/getting-started-els.html
you have to use some ether-options ethernet-switch-profile tag-protocol-id,
under the interface...
Olivier
Le 14 avr. 2015 à 15:42, Andrew Osnach and...@osnach.kiev.ua a écrit :
Hello,
I've got two QFX3500 in a virtual chassis with JunOS 13.2X51-D30.4.
I've upgraded from a standalone QFX3500 with JunOS 12.3X50-D30.2 where I've
got this statement:
ethernet-switching-options {
dot1q-tunneling {
ether-type 0x8100;
}
}
But after upgrading to 13.2 there's no even stanza ethernet-switching-options
in the configuration mode, although there's a link in the documentation about
it
(http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/ethernet-switching-options-qfx-series.html).
How can I change ether-type in JunOS 13.2?
Thanks in advance.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
On Apr 14, 2015, at 12:55, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: Hi Justin - thanks for the reply im just a little stumped at why anyone would want to design this using ACS in which case, as most the configuration is local on Juniper boxes and not at all scalable. I've replied to Eduardo from the thread who seems to have this working, unfortunately i could not replicate his results… It’s most useful if you only need to map people into specific groups. I map every user into tier1, tier2, or tier3, each which a different set of permissions. I also have a service account group for things like RANCID. ACS manages authentication against Active Directory/LDAP and tells JunOS which group the user belongs to (local-username), then the user template manages permissions. And JunOS still uses TACACS+ for command accounting back to the ACS box. (Which we then dump into Splunk for log archiving.) It works very well for us, and is completely scalable. You only have to configure a small number of user templates (4 in our case), and have some way to keep them in sync across devices. The only additional feature I would wish for (aside from per-command authorization which is handled by the user templates) is the ability for TACACS+/ACS to be able to provide JunOS with the public ssh key of the user instead of needing to authenticate with a password. Justin Seabrook-Rocha -- Xenith || xen...@xenith.org || http://xenith.org/ Jabber: xen...@xenith.org || AIM: JustinR98 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Aggregate policer config
Hello Matthew, This looks like yet another sales guy craziness and the answer should have been no way. I'm wondering how your OPS folks are going to support this aggregate-fw-filter based policing. As in couple of months no one is going to recall there are some PFE restrictions. adam -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Matthew Crocker Sent: 07 April 2015 22:16 To: jnsp list Subject: [j-nsp] Aggregate policer config Hello, A customer with two connections to my mx240. I want to police their total bandwidth to 800mbps. Right now I have a 800mbps policer but that gives them 800mbps on each circuit. Customer Interface 1 is a VLAN on a 10G interface Customer Interface 2 is a VLAN on a 1G interface Each interface has its own /30 IP subnet with a BGP session on each customer IP Customer buys X bandwidth we want to give them X bandwidth over a pair of circuits. If one circuit goes down the policer needs to be set to the X bandwidth the purchased. Thanks -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
appreciate the advice and you seem to have a nice setup. I would still refer back to original post, specifically: http://www.cisco.com/c/en/us/support/docs/security/secure-access-control-system/115926-tacacs-radius-devices-00.html Cisco advise The values of the allow-commands, allow-configuration, deny-commands, and deny-configuration attributes can be entered in regex format. The values that these attributes are set to are in addition to the operational/configuration mode commands authorized by the user's login class permissions bits. So what their saying here is as well as the local class-permission bits in JUNOS then these attributes will compliment that policy and in my view giving the user the control in ACS to control user permissions.. Only a packet capture will show what's really going on, and whether or not Junos is bothered with the option if at all they're being sent via TACACS+ from ACS On 14 Apr 2015, at 21:17, Justin Seabrook-Rocha xen...@xenith.org wrote: On Apr 14, 2015, at 12:55, Sukhjit Hayre sukhjit.ha...@googlemail.com wrote: Hi Justin - thanks for the reply im just a little stumped at why anyone would want to design this using ACS in which case, as most the configuration is local on Juniper boxes and not at all scalable. I've replied to Eduardo from the thread who seems to have this working, unfortunately i could not replicate his results… It’s most useful if you only need to map people into specific groups. I map every user into tier1, tier2, or tier3, each which a different set of permissions. I also have a service account group for things like RANCID. ACS manages authentication against Active Directory/LDAP and tells JunOS which group the user belongs to (local-username), then the user template manages permissions. And JunOS still uses TACACS+ for command accounting back to the ACS box. (Which we then dump into Splunk for log archiving.) It works very well for us, and is completely scalable. You only have to configure a small number of user templates (4 in our case), and have some way to keep them in sync across devices. The only additional feature I would wish for (aside from per-command authorization which is handled by the user templates) is the ability for TACACS+/ACS to be able to provide JunOS with the public ssh key of the user instead of needing to authenticate with a password. Justin Seabrook-Rocha -- Xenith || xen...@xenith.org || http://xenith.org/ Jabber: xen...@xenith.org || AIM: JustinR98 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX550 SRX-GP-8SERIAL
Hi, Does anyone know how many 8 port serial GPIM's can be installed into an SRX550? Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX550 SRX-GP-8SERIAL
On 15 Apr 2015, at 9:22 am, Herro91 herr...@gmail.com wrote: Hi, Does anyone know how many 8 port serial GPIM's can be installed into an SRX550? http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/gpim-srx-series-overview.html seems to suggest up to 6 can be installed in the available GPIM slots Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
