[j-nsp] juniper-nsp Digest, Vol 126, Issue 61
Ayman El Nashar
nashar_ay at hotmail.com
Mon May 27 14:04:39 EDT 2013
Best Regards,
Ayman El Nashar
TE Data Network Specialist
web: www.tedata.net
> From: juniper-nsp-request at puck.nether.net
> Subject: juniper-nsp Digest, Vol 126, Issue 61
> To: juniper-nsp at puck.nether.net
> Date: Mon, 27 May 2013 12:00:08 -0400
>
> Send juniper-nsp mailing list submissions to
> juniper-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> or, via email, send a message with subject or body 'help' to
> juniper-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> juniper-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of juniper-nsp digest..."
>
>
> Today's Topics:
>
> 1. EX4550 DC Power Supply (Jed Laundry)
> 2. Re: SRX 3600 dropped packets - how to debug? (Pavel Lunin)
> 3. Re: SRX 3600 dropped packets - how to debug? (Phil Mayers)
> 4. Re: SRX 3600 dropped packets - how to debug? (Phil Mayers)
> 5. Re: SRX 3600 dropped packets - how to debug? (Pavel Lunin)
> 6. Re: SRX 3600 dropped packets - how to debug? (Pavel Lunin)
> 7. Re: SRX 3600 dropped packets - how to debug? (OBrien, Will)
> 8. [OT] unit-level vs interface-level description (Nick Kritsky)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 May 2013 16:08:01 +1200
> From: Jed Laundry <jlaundry at jlaundry.com>
> To: Juniper nsp <juniper-nsp at puck.nether.net>
> Subject: [j-nsp] EX4550 DC Power Supply
> Message-ID:
> <CALYPt1TyzD5nVyBCRzhmNQH0pVDXN6vf9oP=WA=Gsiu48vQjjg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello,
>
> I see that the DC power supplies for the EX4550 have two inputs - is this
> for A/B systems (what I would expect), or are they wired together in
> parallel?
>
> If A/B, what's the wiring configuration? A1,3 B2,4?
>
> Thanks,
> Jed.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 27 May 2013 13:41:21 +0400
> From: Pavel Lunin <plunin at senetsy.ru>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug?
> Message-ID: <51A32A41.2060902 at senetsy.ru>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
>
> 22.05.2013 21:01, Phil Mayers wrote:
> > How can I determine what the dropped packets are, and why they're
> > being dropped?
>
> "show interfaces extensive" and check out "Flow error statistics
> (Packets dropped due to):"
> Another place to look at: "show security screen statistics zone/iface."
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 27 May 2013 10:44:37 +0100
> From: Phil Mayers <p.mayers at imperial.ac.uk>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug?
> Message-ID: <51A32B05.5040206 at imperial.ac.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 05/27/2013 10:41 AM, Pavel Lunin wrote:
> >
> >
> > 22.05.2013 21:01, Phil Mayers wrote:
> >> How can I determine what the dropped packets are, and why they're
> >> being dropped?
> >
> > "show interfaces extensive" and check out "Flow error statistics
> > (Packets dropped due to):"
>
> Nothing in there corresponding to the numbers/rates I'm seeing on the
> "show security flow statistics"
>
> > Another place to look at: "show security screen statistics zone/iface."
>
> As I believe I said, the screens are all disabled.
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 27 May 2013 11:04:34 +0100
> From: Phil Mayers <p.mayers at imperial.ac.uk>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug?
> Message-ID: <51A32FB2.2020307 at imperial.ac.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 27/05/2013 10:44, Phil Mayers wrote:
> > On 05/27/2013 10:41 AM, Pavel Lunin wrote:
> >>
> >>
> >> 22.05.2013 21:01, Phil Mayers wrote:
> >>> How can I determine what the dropped packets are, and why they're
> >>> being dropped?
> >>
> >> "show interfaces extensive" and check out "Flow error statistics
> >> (Packets dropped due to):"
> >
> > Nothing in there corresponding to the numbers/rates I'm seeing on the
> > "show security flow statistics"
> >
> >> Another place to look at: "show security screen statistics zone/iface."
> >
> > As I believe I said, the screens are all disabled.
> >
>
> By way of elaboration:
>
> admin at srx-eval> show security flow statistics | match dropped | refresh 2
> ---(refreshed at 2013-05-27 11:01:03 BST)---
> Packets dropped: 72232499
> Packets dropped: 142788174
> Packets dropped: 145382728
> Packets dropped: 360403401
> ---(refreshed at 2013-05-27 11:01:05 BST)---
> Packets dropped: 72232835
> Packets dropped: 142788815
> Packets dropped: 145385883
> Packets dropped: 360407533
> ---(*more 100%)---[abort]
>
> Note the "total" packets dropped (4th item) claims to be climbing at
> ~1500pps, on the above sample. At the same time "sh int extensive" for
> the relevant interfaces says:
>
> Flow Input statistics :
> Self packets : 50680
> ICMP packets : 2950329
> VPN packets : 0
> Multicast packets : 1228
> Bytes permitted by policy : 13201459013373
> Connections established : 8925850
> Flow Output statistics:
> Multicast packets : 0
> Bytes permitted by policy : 3161441830843
> Flow error statistics (Packets dropped due to):
> Address spoofing: 0
> Authentication failed: 0
> Incoming NAT errors: 0
> Invalid zone received packet: 0
> Multiple user authentications: 0
> Multiple incoming NAT: 0
> No parent for a gate: 0
> No one interested in self packets: 0
> No minor session: 0
> No more sessions: 0
> No NAT gate: 0
> No route present: 18570
> No SA for incoming SPI: 0
> No tunnel found: 0
> No session for a gate: 0
> No zone or NULL zone binding 0
> Policy denied: 0
> Security association not active: 0
> TCP sequence number out of window: 0
> Syn-attack protection: 0
> User authentication errors: 0
>
> ...over the *entire* lifetime of the box. So, pretty clearly not enough
> for 1500pps of denies.
>
> As for the screens:
>
> admin at srx-eval> show security screen statistics zone trust
> error: "screen object not found for this zone/interface"
>
> admin at srx-eval> show security screen statistics zone untrust
> error: "screen object not found for this zone/interface"
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 27 May 2013 14:03:25 +0400
> From: Pavel Lunin <plunin at senetsy.ru>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug?
> Message-ID: <51A32F6D.3090604 at senetsy.ru>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 27.05.2013 13:44, Phil Mayers wrote:
> >
> >> "show interfaces extensive" and check out "Flow error statistics
> >> (Packets dropped due to):"
> >
> > Nothing in there corresponding to the numbers/rates I'm seeing on the
> > "show security flow statistics"
> If users are complaining, try to understand what exactly they have
> problems with. Figure out a particular pattern for possibly dropped
> packets (like s/d addresses, etc) and catch it with "security flow
> traceoption + packet-filter". Most probably you'll see the reason of a
> drop there.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 27 May 2013 14:14:39 +0400
> From: Pavel Lunin <plunin at senetsy.ru>
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug?
> Message-ID: <51A3320F.20908 at senetsy.ru>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
>
> 24.05.2013 19:05, Alex Arseniev wrote:
> > If You run any kind peer-to-peer apps (uTorrent, eMule, etc, also
> > includes Skype) then You'll see that outside peers trying to establish
> > LOADS of unsolicited connection to Your inside hosts.
> > And all of them will be dropped unless You enable full cone NAT.
>
> A bit off topic, but seems to be worth to note here as I've seen it
> several times.
>
> Often people don't have a route for source NAT pools (especially in case
> of static routing). This leads to the following. When a disallowed
> connection from outside comes, it matches a default route, than a policy
> checkout occurs and, if untrust-to-untrust policy permits it (for some
> reason; say, folks managing NAT for broadband access tend to not bother
> with policies and just permit all everywhere), you have 1) a routing
> loop 2) session table flooded with this trash. Even if there is no
> permitting policy for untrust-to-untrust, this anyway leads to
> additional performance consumption due to policy checkup. So the best is
> to nail it down with a route like "nat-pool/xx -> deny" in order to drop
> the unwanted incoming connections as early as possible.
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 27 May 2013 14:45:01 +0000
> From: "OBrien, Will" <ObrienH at missouri.edu>
> To: Pavel Lunin <plunin at senetsy.ru>
> Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
> Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug?
> Message-ID: <D582F22C-568C-4EB2-BD74-7E9F9D377F85 at missouri.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> You never sent your policy to the list. Is there traffic being routed inside your zones? Do you have a trust to trust permit policy for example? Are you using any alg? Have you used trace options to determine what's dropping? Are you allowing assymetric traffic flows across the cluster? Have you had a user pull a capture using wire shark to show you what's dropping? Are you using nat at all? If so what? It's very easy to shoot yourself in the foot with nat. Have you checked your chassis cluster health? Any system alarms?
>
> Will
>
> On May 27, 2013, at 5:15 AM, "Pavel Lunin" <plunin at senetsy.ru> wrote:
>
> >
> >
> > 24.05.2013 19:05, Alex Arseniev wrote:
> >> If You run any kind peer-to-peer apps (uTorrent, eMule, etc, also
> >> includes Skype) then You'll see that outside peers trying to establish
> >> LOADS of unsolicited connection to Your inside hosts.
> >> And all of them will be dropped unless You enable full cone NAT.
> >
> > A bit off topic, but seems to be worth to note here as I've seen it
> > several times.
> >
> > Often people don't have a route for source NAT pools (especially in case
> > of static routing). This leads to the following. When a disallowed
> > connection from outside comes, it matches a default route, than a policy
> > checkout occurs and, if untrust-to-untrust policy permits it (for some
> > reason; say, folks managing NAT for broadband access tend to not bother
> > with policies and just permit all everywhere), you have 1) a routing
> > loop 2) session table flooded with this trash. Even if there is no
> > permitting policy for untrust-to-untrust, this anyway leads to
> > additional performance consumption due to policy checkup. So the best is
> > to nail it down with a route like "nat-pool/xx -> deny" in order to drop
> > the unwanted incoming connections as early as possible.
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 27 May 2013 18:58:50 +0400
> From: Nick Kritsky <nick.kritsky at gmail.com>
> To: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
> Subject: [j-nsp] [OT] unit-level vs interface-level description
> Message-ID:
> <CAJ8_BxpeR77v7OwqWbgVJQbJqJs=vuLWNeRVALdQf9BCTOw4Sw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi fellow J-users,
>
> I hope I will not trigger some long-forgotten flame-war by that question.
> But I do wonder: what are the best practices for interface/unit
> descriptions?
> Do you put them on interface-level or unit-level? Especially when you have
> pure-L3 interface that only has "unit 0" with "family inet" on it.
>
> Do you put description to interface level? Unit level? Or both levels? Or
> do you put it on both levels but different descriptions?
>
> I've seen people using different approaches, and I am just curious what's
> driving them.
>
> To be completely honest, this question is not entirely theoretical.
> Recently I was writing some reporting scripts for my NetFlow data. And I
> have noticed that InterfaceIn and InterfaceOut fields are populated with
> unit-level ifIndex. And in my case that meant - no description. That made
> me wonder if I am actually "doing it right" (TM)
>
> thanks
>
> nick
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> juniper-nsp mailing list
> juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ------------------------------
>
> End of juniper-nsp Digest, Vol 126, Issue 61
> ********************************************
More information about the juniper-nsp
mailing list