Hi,
I am doing some flow analysis within our network primarily for understanding
application flows to aid in network segregation activity and mainly understand
what is going on inside the network. To do this I have been using netflow
where the switches/firewalls support it. In some cases I
On 17 Jun 2015, at 10:44, Maqbool Hashim wrote:
It was stated in that thread that netflow reports source/dest port 0
for non-initial fragments.
Fragmentation in this context only applies to UDP packets.
If the destination of a TCP SYN is being reported as 0 (what's the
source port?), either
Hi
Thanks for the response. There are lots of different source ports all above
10,000 (e.g. 42628,42927,39050). It is always two redhat machines generating
the traffic, can't be 100% sure due to the sampling but pretty sure the capture
has been running for 24 hours or so.It is always the
On Wed, 17 Jun 2015, Maqbool Hashim wrote:
> It is always the same destination servers and in normal operations
> these source and destination hosts do have a bunch of legitimate flows
> between them. I was leaning towards it being a reporting artifact,
> but it's interesting that there are a who
On 17 Jun 2015, at 11:23, Maqbool Hashim wrote:
Maybe I need to setup collectors and span ports on all the switches
involved to get to the bottom of this. Just feeling like we need to
look at *all* the packets not the sample!
Concur 100%.
---
Roland Dobbins
Hi,
The destination host is sending an ACK+RST with the source port set to zero.
The destination IP is always one of the two hosts that are generating the SYN
packets with a destination port of 0. The destination port however is hard to
match up to a source port in the original SYN packet due
Hello!
Looks like it's silly hping3 flood:
12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.],
win 512, le
On 17 Jun 2015, at 11:34, Maqbool Hashim wrote:
What might be easier is to set up a span port for the hosts access
port on the switch and grab that via the collector laptop I have.
It's better to collect as much information you have without perturbing
the systems involved, anyways.
---
Hmm, no flags set in your output though?
From: Pavel Odintsov
Sent: 17 June 2015 10:44
To: Maqbool Hashim
Cc: Marcin Cieslak; nanog@nanog.org
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set
Hello!
Looks like it's silly hping3 flood:
12:4
Hello!
Just add --syn flag:
12:51:51.150085 IP 192.168.0.127.14628 > 216.239.34.21.0: Flags [S],
seq 680218921, win 512, length 0
12:51:51.150092 IP 192.168.0.127.14629 > 216.239.34.21.0: Flags [S],
seq 2073100941, win 512, length 0
12:51:51.150100 IP 192.168.0.127.14630 > 216.239.34.21.0: Flags
Agreed. Might see if I can get netstat -antp output from the operators at some
point though.
I will start with one of the hosts, looks like the whole flow capturing
exercise for this LAN will need to be done using multiple laptops connected to
the different access ports for the hosts. No RSPA
So, progressed to grabbing full packet dumps via monitor ports. This confirmed
that indeed the two hosts in question are generating traffic to the same four
destinations with a destination port of zero. Now that I have a full packet
dump I see reset + ack packets coming back from source port 0
On 17 Jun 2015, at 13:56, Maqbool Hashim wrote:
Any advice on this aspect would be great, unless considered off topic.
NANOG isn't really the right alias for this sort of thing.
TCP port-scanning on TCP/0 is a common reconnaissance mechanism.
Suggest you take this to a more appropriate alia
https://www.google.com/intl/en/ipv6/statistics.html
On Mon, Jun 15, 2015 at 8:26 PM, Matt Palmer wrote:
> On Mon, Jun 15, 2015 at 05:07:22PM -0700, Dave Taht wrote:
> > On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush wrote:
> > >> "What about IPv6? We have a plan! We plan to be dead before custom
On Wed, 17 Jun 2015, Maqbool Hashim wrote:
>Finally I don't see how it could be, but be interested to hear peoples
>thoughts, no legitimate application could be generating this traffic
>could it? I mean I don't see what use an application could make of
>such a TCP conversation. Discarding net
Hi,
I'm investigating some of the protocols and will start looking at the processes
on the machines. Someone else rightly pointed out this getting off topic for
NANOG, so thanks to everyone that responded.
Regards,
MH
From: NANOG on behalf of Mark
Need some help.. Does anyone have an email contact at Google that they are
willing to pass along?
All of our mowisp.net Apps for ISP accounts were disabled last night at about
8-9PM without notice and we are now getting swamped with calls. Possibly
several hundred users affected.
--
Christophe
Google cancelled their ISP program as of the 8th of June.
Feel free to contact me off-list for more info. They cancelled ours as well.
-Original Message-
From: "Christopher Tyler"
Sent: Wednesday, June 17, 2015 9:28am
To: nanog@nanog.org
Subject: Google contact?
Need some help.. D
Hopefully, they sent you advance notice.
Google Apps for ISP EOL
https://productforums.google.com/forum/#!topic/apps/_zgHXEBjwKU
matthew black
california state university, long beach
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher Tyler
Sent: We
I'm replying on-list since it seems like a lot of people are in the same boat.
Here's a summary of what happened to us. Please feel free to jump in if you
had a different experience, or have more information.
Google sent us a notice in December that as of June 8 they would be
discontinuing
I was actually told July 6 or 9 in my email (which was delivered to that
unmonitored mail box like you). I told customers July 1. We lost it June
9.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Wed, Jun 17, 2015 at 12:10 PM, Shawn L wrote:
This seems to come up about once a month for quite some time on various lists.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
- Original Message -
From: "Shawn L"
To: "marciano lopes"
Cc: "nanog"
Sent: Wednesday, June 17, 2015 11:10:24 AM
Subject:
Anycast is generally not well-suited for stateful connectivity (e.g. most
things TCP). The use case for anycast is restricted to simple
challenge-response protocol design.
As such, you typically only see it leveraged for simple services (e.g. DNS,
NTP).
The reason for this, as you suspect, is yo
Looking at implementing DMARC for my institution. We currently have an SPF
record and use DKIM to sign a small subset of messages. Rollout recommendations
for DMARC suggest initially creating a "p=none" record to gather information on
how a domain is being used. The RUA tag specifies a URI of wh
Is that safe to use internally? Anyone using it?
Just for NATTING on Cisco gears...
On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen wrote:
> Is that safe to use internally? Anyone using it?
> Just for NATTING on Cisco gears...
>
most things, including most cisco gear, will not forward those Class E
packets or accept Class E as a valid address
If you have success, please report it
Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ray Soucy
Sent: Wednesday, June 17, 2015 3:14 PM
To: Joe Hamelin
Cc: NANOG list
Subject: Re: Anycast provider for SMTP?
>As such, you typically only see it leveraged for simple services (e.g. DNS,
>NTP).
I've be
Use 100.64.0.0/10, this is the CGNAT reserved range.I would most definitely not
recommend 240.0.0.0
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Luan Nguyen
Sent: Thursday, 18 June 2015 9:07 a.m.
To: nanog@nanog.org
Subject: Is it safe to use 240.0.0.0/4
Probably fine to NAT it yourself until it is allocated and someone starts
using it.
Why not just use RFC1918 space?
https://www.google.com/fusiontables/DataSource?docid=1JEgabzMOJx1l25zHZK5wv4_Tn9KRsyDGgSq-M4g
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy,
Cisco IOS-XE Fails
ip add 241.1.1.1 255.255.255.0
Not a valid host address - 241.1.1.1
ip route 241.0.0.0 255.0.0.0 10.10.10.1
%Invalid destination prefix
XR-OS : fails
Can take the IP on a interface, but cant route it
IOS fails
we used up all the reserved ip blocks including the 169.254 and the
b
On Jun 17, 2015, at 17:15, Chuck Church wrote:
>> As such, you typically only see it leveraged for simple services (e.g. DNS,
>> NTP).
>
> I've been thinking about this for NTP. Wouldn't you end up with constant
> corrections with NTP and Anycast?
I am not a time geek, but the general and con
And what about 0.0.0.0/8?
--
Eduardo Schoedler
2015-06-17 18:21 GMT-03:00 Luan Nguyen :
> Cisco IOS-XE Fails
> ip add 241.1.1.1 255.255.255.0
> Not a valid host address - 241.1.1.1
> ip route 241.0.0.0 255.0.0.0 10.10.10.1
> %Invalid destination prefix
> XR-OS : fails
> Can take the IP on a inte
NTP might have been a bad example for the timing reasons. One thing to
keep in mind with anycast is that unless there are problems the routes are
fairly stable and depending on how many servers you deploy and what route
visibility you have even different providers will often see the same
location
On Wed, 17 Jun 2015 17:07:25 -0400, Luan Nguyen
wrote:
Is that safe to use internally? Anyone using it?
Just for NATTING on Cisco gears...
As you've already figured out, Class E space is still restricted on Cisco
gear.
I'll wait for Curran to pop up with various links to reasons why Class
We use dmarcian.com to process the reports.
Regards
Baldur
There is already more than enough address space allocated for NAT, you
don't need to start using random prefixes that may or may not be needed for
other purposes in the future.
For all we know, tomorrow someone could write an RFC requesting an address
reserved for local anycast DNS and it could be
You'll find as well, a lot of hosts (eg, I know at least Windows XP)
won't forward to Class E destinations.
-Tom
On Wed, Jun 17, 2015 at 2:50 PM, Ray Soucy wrote:
> There is already more than enough address space allocated for NAT, you
> don't need to start using random prefixes that may or may
On Wed, Jun 17, 2015 at 05:07:25PM -0400, Luan Nguyen wrote:
> Is that safe to use [240.0.0.0/4] internally? Anyone using it? Just
> for NATTING on Cisco gears...
On Wed, Jun 17, 2015 at 06:30:04PM -0300, Eduardo Schoedler wrote:
> And what about 0.0.0.0/8?
On both counts: NO. I always assume pa
Using CGNAT doesn't sound right either, although I haven't read the whole
thing, but it seems reasonable to use that block for CGNAT only.
https://tools.ietf.org/html/rfc1918
On Wed, Jun 17, 2015 at 4:13 PM, Tony Wicks wrote:
> Use 100.64.0.0/10, this is the CGNAT reserved range.I would most
>
You have dmarcian, returnpath and agari to process reports.
https://dmarcian.com/dmarc-status/
Will give you an idea who send aggregate reports. To state the obvious,
they will send you a report only if you send them email.
Allow 24 to 48 hours to get your first reports, if you don't get any, ch
On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam wrote:
> I'll wait for Curran to pop up with various links to reasons why Class E was
> "abandoned" by ARIN. (short answer: too much broken crap thinks it's
> multicast!)
Hi Ricky,
You may be confused. ARIN never possessed class E; it's held in
reserve
On Wednesday, June 17, 2015, William Herrin wrote:
> On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam > wrote:
> > I'll wait for Curran to pop up with various links to reasons why Class E
> was
> > "abandoned" by ARIN. (short answer: too much broken crap thinks it's
> > multicast!)
>
> Hi Ricky,
>
>
In message
, Ca By
writes:
> On Wednesday, June 17, 2015, William Herrin wrote:
>
> > On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam > > wrote:
> > > I'll wait for Curran to pop up with various links to reasons why Class E
> > was
> > > "abandoned" by ARIN. (short answer: too much broken crap th
In article
you
write:
>Looking at implementing DMARC for my institution.
What problem do you expect this to solve? This is a real question,
since you can be 100% sure that any DMARC policy will wreak havoc on
any of your users who use mailing lists like this one. Academic
institutions tend to
Not used in the sense you imagine, but I designed a hack where we hash IPv6
addresses into 224/3 (class D and E space) so backends that don't support
IPv6 can still be provided a pseudo-IP. This accelerated support of IPv6
across all Google services without needing to wait for each individual
back
On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin wrote:
You may be confused. ARIN never possessed class E; it's held in
reserve by IETF. As much as I enjoy a good ARIN bashing, they and John
Curran are quite faultless here.
Quote-unquote, as in they didn't even bother *even proposing* to use
My apologies in advance to any here who might feel that this is off
topic... I don't personally believe that it is. Frankly, I don't
know of that many mailing lists where the subscribers are likely to
care as much about network security (and/or the lack thereof) as the
membership of this list doe
On Wednesday, June 17, 2015, Ricky Beam wrote:
> On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin wrote:
>
>> You may be confused. ARIN never possessed class E; it's held in
>> reserve by IETF. As much as I enjoy a good ARIN bashing, they and John
>> Curran are quite faultless here.
>>
>
> Quo
I think it would be great if you were to include some source links in
your petition/email so that folks unaware of the specifics can educate
themselves in a non-partisan and factual manner.
Just my $0.02.
Cheers,
Harry
On 6/17/15 8:54 PM, Ronald F. Guilmette wrote:
> My apologies in advance to
This is the government... you have to put on your bizarro-economics and
bizarro-ethics glasses for the State to make sense.
It does not operate like a market. Failure results in people being
shuffled around, and larger budgets. Failure justifies more control and
power. People get taken down for
>> Given how slowly IPv6 is deploying, this choice may prove to have been
>> shortsighted.
>
> I doubt it. As you said, there is A LOT of crap out there that would have to
> be updated. Pulling a number out of the air, I'd guess *most* in-use devices
> would NEVER see such an update. Even from
> What problem do you expect this to solve? This is a real question,
> since you can be 100% sure that any DMARC policy will wreak havoc on
> any of your users who use mailing lists like this one.
*Any* mailing list.
Please help stamp out this abomination by refusing to capitulate to its insane
--- r...@tristatelogic.com wrote:
From: "Ronald F. Guilmette"
*) The Director of the Office of Personnel Management, Ms. Katherine
Archueta was warned, repeatedly, and over several years, by her
own department's Inspector General (IG) that many of OPM's systems
were
On Wednesday, June 17, 2015, Jonas Björk wrote:
>
> >> Given how slowly IPv6 is deploying, this choice may prove to have been
> >> shortsighted.
> >
> > I doubt it. As you said, there is A LOT of crap out there that would
> have to be updated. Pulling a number out of the air, I'd guess *most*
> i
No, we examined this back in 2007. See your favorite cache site
for http://puck.nether.net/mailman/listinfo/240-e
--
RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
>IIRC, the short answer why it wasn't repurposed as additional unicast
>addresses was that too much deployed gear has it hardcoded as
>"reserved, future functionality unknown, do not use." Following an
>instruction to repurpose 240/4 as unicast addresses, such gear would
>not receive new firmware o
How many devices need IPs? Is there a reason ARIN can't be used?
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Jun 17, 2015 10:18 PM, "John Levine" wrote:
> >IIRC, the short answer why it wasn't repurposed as additional unicast
> >addresses was
In message
Tyler Mills wrote:
>This is the government... you have to put on your bizarro-economics and
>bizarro-ethics glasses for the State to make sense.
>
>It does not operate like a market. Failure results in people being
>shuffled around, and larger budgets. Failure justifies more control
On Wed, 17 Jun 2015 21:17:53 -0400, Ca By wrote:
https://tools.ietf.org/html/draft-wilson-class-e-02
Proposed and denied. Please stop this line and spend your efforts on ipv6
By APNIC. Cisco did, too, btw. And they weren't first, either. Nor is this
going to be the last time someone sugges
Harry Hoffman hhoffman at ip-solutions.net wrote:
>I think it would be great if you were to include some source links in
>your petition/email so that folks unaware of the specifics can educate
>themselves in a non-partisan and factual manner.
Well, as regards to the petition itself, I can't bec
60 matches
Mail list logo
