Re: [j-nsp] [OT] unit-level vs interface-level description
On 28/05/2013, at 12:58 AM, Nick Kritsky wrote: > 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. For external links I tend to roll with: set interfaces ge-0/0/0 description "Connected to (Device X Port Y)" set interfaces ge-0/0/0 unit 0 description "Circuit ID / Carrier Description" Where I'm talking to kit I control/where available, I tend to leave the physical stuff to something more accurate and self-updating like LLDP. On my to do list is writing an event-script that checks interfaces with LLDP neighbours every 24 hours or so and updates interface descriptions appropriately. Driving my approach is being 6 stanzas deep in a config and being able to run "top show interfaces ?" and getting a nicely summarised list of the ports I should be referencing. Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [OT] unit-level vs interface-level description
On (2013-05-27 18:58 +0400), Nick Kritsky wrote: Hi, > Do you put description to interface level? Unit level? Or both levels? Or > do you put it on both levels but different descriptions? Both for interfaces with just unit 0. For interfaces with multiple units, I guess issues is lot clearer, physical information and logical information. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper-nsp Digest, Vol 126, Issue 61
Best Regards, Ayman El Nashar TE Data Network Specialist web: www.tedata.net > From: juniper-nsp-requ...@puck.nether.net > Subject: juniper-nsp Digest, Vol 126, Issue 61 > To: juniper-nsp@puck.nether.net > Date: Mon, 27 May 2013 12:00:08 -0400 > > Send juniper-nsp mailing list submissions to > juniper-nsp@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-requ...@puck.nether.net > > You can reach the person managing the list at > juniper-nsp-ow...@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 > To: Juniper nsp > Subject: [j-nsp] EX4550 DC Power Supply > Message-ID: > > 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 > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <51a32a41.2060...@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 > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <51a32b05.5040...@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 > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? > Message-ID: <51a32fb2.2020...@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@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 packe
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
On 05/27/2013 03:45 PM, OBrien, Will wrote: Are you using any alg? Ah ha... thanks for the nudge. The ALG settings are SRX-defaults: admin@srx-eval> show security alg status ALG Status : DNS : Enabled FTP : Enabled H323 : Disabled MGCP : Disabled MSRPC: Enabled PPTP : Enabled RSH : Enabled RTSP : Disabled SCCP : Disabled SIP : Disabled SQL : Enabled SUNRPC : Enabled TALK : Enabled TFTP : Enabled IKE-ESP : Disabled Disabling the DNS ALG significantly reduces the rate of counter increments. Presumably the other traffic is other, less-used ALGs. So, the ALG(s) are suspect. That said, I can't believe the firewall was *actually* dropping 1500pps of DNS traffic; we'd have widespread problems reported, surely. So, it seems that maybe ALG-processed traffic is being counted under "packets dropped" for "show security flow statistics"? A brief test from a linux box behind the firewall shows it can do glibc-style getaddrinfo() calls (A and lookup from same UDP socket back-to-back) and both requests and replies are forwarded with the ALG enabled, so I'm disinclined to believe it's *actually* dropping. Does it seem reasonable that the counter is in error? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] [OT] unit-level vs interface-level description
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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
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" 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@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 3600 dropped packets - how to debug?
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
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" ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
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." ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
