Re: [j-nsp] Any interest in my script that auto generate nagios configs for juniper devices polled via SNMP?
Hi Morgan, Very much interested in such a tool, already have several deployments of nagios in different environments. Thanks, Ido -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Friday, July 20, 2012 9:39 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Any interest in my script that auto generate nagios configs for juniper devices polled via SNMP? I have a script that I've developed which when given a list of hosts will poll via snmp and gather: Interface details BGP peers OSPF neighbors Hardware information It then has some default behavior and intelligently builds a working nagios configuration for the devices, all by itself. There are some configuration flags, but the default behavior does quite a lot. My implementation auto generates around 17,500 checks for 38 devices before ignoring access interfaces etc, things I don't care as much about. I'm able to generate all of this via my script in under five minutes. I'm assuming once I configure the interfaces I want to ignore (a lot) that amount of checks would come down significantly. Some network admins don't know unix or nagios very well. If there is enough interest I will put up a page with details on how to setup a quick nagios installation, and include details about how to use the script (its very easy). I'll probably start maintaining publicly it if there is enough interest. I run an all juniper network at work, so this script is really only designed for juniper shops. These files can also augment existing nagios configurations, a stand alone installation isn't needed. Let me know, either publicly or directly please. I've included a few screen shots. http://i.imgur.com/kfh2z.png http://i.imgur.com/IkVLo.png http://i.imgur.com/xrSUh.png Thanks! Morgan ___ 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
[j-nsp] Real-world deployment scenarios for cloud services
We're looking for people that work directly with wireline companies that have a large/medium POP presence and offer network services to end-users such as: * Cloud services * Internet services We're specifically interested in cloud services and the different deployment scenarios to deliver network services to end-users. For example providing cloud services on top of an existing managed MPLS network service. I'm looking to capture real-world designs that our customers are using today. Perhaps the cloud services can be accessed by the end-user via a private /24 that's routable within the end-user's L3VPN from the provider or it's simply a routed VLAN ID on the same wire as the managed MPLS service. These real-world deployment scenarios will begin driving how we implement features moving forward. Right now I'm focusing on distributed data center architecture. This is defined as many different data centers such as POPs that are one-hop away from end users. I'll focus on centralized data center from end-users architecture later down the road. This is defined as large, but fewer data centers that primarily offer network services to customers over the Internet. I'm looking for the following information: * What type of cloud services are you offering? * How is it being delivered to the end-users? * How do the end-users access it? Are there any prerequisites such as the end-user must already purchase managed MPLS. * A topology of the networks that are relevant to the cloud core, aggregation, access, and edge. * Relevant router configurations if possible. What we're trying to collect is how are the devices connected, what protocols are being used, and how is traffic being routed, filtered, and isolated. That's all. * Any type of scaling information. How many end-users per router, VRF, interface, or any other measurement. Obviously there are many different methods to do the same thing and this is what I'm looking to capture. The goal is to aggregate the solutions and come up with the most common methods as seen in the field. If you are someone that works with companies who have distributed data centers (think traditional wireline service providers) and offers network services, can you please unicast me? Thank you, -- Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875 Solutions Architect Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Why is this term working?
JFYI..
http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/config-guide-policy/topic-28284.html
""The nonterminating action operations carry a default accept action""
//BR
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
Sent: 22 July, 2012 9:12 PM
To: John Neiberger; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Why is this term working?
Action modifiers such as count, loss-priority, and forwarding-class implicitly
imply a terminating action of accept.
Thank you,
--
Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875 Solutions Architect EABU Juniper
Networks
On 7/22/12 10:34 AM, "John Neiberger" wrote:
>Forgive my Juniper noobiness once again. We have the following term in
>a ingress firewall filter for marking:
>
>term netmgmt {
>then {
>count fec-cs2;
>loss-priority high;
>forwarding-class MNGMT;
>
>It seems to be working, but I don't know why. If there is no "accept",
>shouldn't it be dropping the traffic? I know the default action is
>accept, but once we use a "then" statement, don't we have to specify
>the accept/reject/discard action? I'm wondering if the
>"forwarding-class" statement has an implied accept or something like
>that. I really have no idea.
>
>Thanks,
>John
>___
>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
This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.
Thank you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Why is this term working?
Thanks! I thought that must be the case, but I was told by two other
Juniper engineers that it shouldn't be working because there was no
explicit accept. That didn't seem to make sense because the term is
clearly working. I wanted to check here to make sure I understood. I
appreciate the help!
John
On Sun, Jul 22, 2012 at 12:12 PM, Doug Hanks wrote:
> Action modifiers such as count, loss-priority, and forwarding-class
> implicitly imply a terminating action of accept.
>
> Thank you,
>
> --
> Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875
> Solutions Architect EABU
> Juniper Networks
>
>
> On 7/22/12 10:34 AM, "John Neiberger" wrote:
>
>>Forgive my Juniper noobiness once again. We have the following term in
>>a ingress firewall filter for marking:
>>
>>term netmgmt {
>>then {
>>count fec-cs2;
>>loss-priority high;
>>forwarding-class MNGMT;
>>
>>It seems to be working, but I don't know why. If there is no "accept",
>>shouldn't it be dropping the traffic? I know the default action is
>>accept, but once we use a "then" statement, don't we have to specify
>>the accept/reject/discard action? I'm wondering if the
>>"forwarding-class" statement has an implied accept or something like
>>that. I really have no idea.
>>
>>Thanks,
>>John
>>___
>>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] Why is this term working?
Action modifiers such as count, loss-priority, and forwarding-class
implicitly imply a terminating action of accept.
Thank you,
--
Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875
Solutions Architect EABU
Juniper Networks
On 7/22/12 10:34 AM, "John Neiberger" wrote:
>Forgive my Juniper noobiness once again. We have the following term in
>a ingress firewall filter for marking:
>
>term netmgmt {
>then {
>count fec-cs2;
>loss-priority high;
>forwarding-class MNGMT;
>
>It seems to be working, but I don't know why. If there is no "accept",
>shouldn't it be dropping the traffic? I know the default action is
>accept, but once we use a "then" statement, don't we have to specify
>the accept/reject/discard action? I'm wondering if the
>"forwarding-class" statement has an implied accept or something like
>that. I really have no idea.
>
>Thanks,
>John
>___
>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
[j-nsp] Why is this term working?
Forgive my Juniper noobiness once again. We have the following term in
a ingress firewall filter for marking:
term netmgmt {
then {
count fec-cs2;
loss-priority high;
forwarding-class MNGMT;
It seems to be working, but I don't know why. If there is no "accept",
shouldn't it be dropping the traffic? I know the default action is
accept, but once we use a "then" statement, don't we have to specify
the accept/reject/discard action? I'm wondering if the
"forwarding-class" statement has an implied accept or something like
that. I really have no idea.
Thanks,
John
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] FW configuations which are required during failover of one db to other !!
On Sun, Jul 22, 2012 at 8:06 AM, Harri Makela wrote: > Hi All > > Application Server connecting successfully to DataBase Server01 (db01). This > DB01 now need to mirror to db02 and port 5022 will be used. > > Requirement : Application Servers which currently access DB01 should be able > to access DB02 when failover to DB02 will happen. > From FW perspective, I am not sure how I`ll add the failover on FW ? As per > my understanding, I just have to add the FW policies as per flow i.e. SRC --> > DST --> Port and rest will be done from SQL end. This depends on how you're doing failover. Two ways that I can think of: If it's purely application-layer, and your clients will fail over to connecting to db02 somehow, just be sure and have policy that allows connections to db02's IP. - Failover and test this out. If it's a VIP, High Availability IP, or some other mechanism that moves connections to the IP from one host to the other, do nothing. Your firewall should allow new connections to form normally. However, you may still see some sessions that are established but for which there is no matching connection on the host. These may time out or attempt closure after a while. --j ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] FW configuations which are required during failover of one db to other !!
Hi All Application Server connecting successfully to DataBase Server01 (db01). This DB01 now need to mirror to db02 and port 5022 will be used. Requirement : Application Servers which currently access DB01 should be able to access DB02 when failover to DB02 will happen. From FW perspective, I am not sure how I`ll add the failover on FW ? As per my understanding, I just have to add the FW policies as per flow i.e. SRC --> DST --> Port and rest will be done from SQL end. Please advice. Regards HM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
