Best Regards, Ayman El Nashar TE Data Network Specialist web: www.tedata.net
> From: [email protected] > Subject: juniper-nsp Digest, Vol 126, Issue 61 > To: [email protected] > Date: Mon, 27 May 2013 12:00:08 -0400 > > Send juniper-nsp mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Juniper nsp <[email protected]> > Subject: [j-nsp] EX4550 DC Power Supply > Message-ID: > <CALYPt1TyzD5nVyBCRzhmNQH0pVDXN6vf9oP=WA=gsiu48vq...@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 <[email protected]> > To: [email protected] > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <[email protected]> > 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@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@srx-eval> show security screen statistics zone trust > error: "screen object not found for this zone/interface" > > admin@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 <[email protected]> > To: [email protected] > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <[email protected]> > 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" <[email protected]> > To: Pavel Lunin <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <[email protected]> > 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" <[email protected]> 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 [email protected] > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > ------------------------------ > > Message: 8 > Date: Mon, 27 May 2013 18:58:50 +0400 > From: Nick Kritsky <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [j-nsp] [OT] unit-level vs interface-level description > Message-ID: > <CAJ8_BxpeR77v7OwqWbgVJQbJqJs=vulwnervaldqf9bctow...@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 > [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > > ------------------------------ > > End of juniper-nsp Digest, Vol 126, Issue 61 > ******************************************** _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
