another cogent oddity
you may remember me from the weird cogent route retention / loop problem i brought up last week. it remains unsolved by cogent to date. also remembering i'm a relatively new cogent customer, i recently noticed some packets floating into my network that had cos and ipp markings on them. i figured i'd try to find where they were coming from, so i crafted up something like this and placed it inbound on my two transits (cogent and xo), excluding network control markings. from { dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs1 cs2 cs3 cs4 cs5 ef ]; precedence [ 1 2 3 4 5 ]; } all of it is coming in from cogent: COGENT-NOT-BE -> 4217788987 XO-NOT-BE -> 0 i shifted all traffic to XO just to make sure. the XO counter doesn't budge. seems like one transit is remarking everything to best effort before sending to me (which is preferred), and the other is not. am i odd to think that this is... odd? i also get a remarkable amount of hits against these destinations coming in on the cogent side, whereas i get none on the XO side. show policy-options prefix-list PUBLIC-BAD-NETS 10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; 224.0.0.0/4; ryan
cogent is well known not to filter in any useful way... in terms of sources that should not be there, we see the same thing (or did the last time I looked). John van Oppen Spectrum Networks Direct: 206-973-8302 Main: 206-973-8300 ________________________________________ From: NANOG [nanog-bounces+jvanoppen=spectrumnet.us@nanog.org] on behalf of ryanL [ryan.landry@gmail.com] Sent: Thursday, October 09, 2014 10:35 AM To: North American Network Operators Group Subject: another cogent oddity you may remember me from the weird cogent route retention / loop problem i brought up last week. it remains unsolved by cogent to date. also remembering i'm a relatively new cogent customer, i recently noticed some packets floating into my network that had cos and ipp markings on them. i figured i'd try to find where they were coming from, so i crafted up something like this and placed it inbound on my two transits (cogent and xo), excluding network control markings. from { dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs1 cs2 cs3 cs4 cs5 ef ]; precedence [ 1 2 3 4 5 ]; } all of it is coming in from cogent: COGENT-NOT-BE -> 4217788987 XO-NOT-BE -> 0 i shifted all traffic to XO just to make sure. the XO counter doesn't budge. seems like one transit is remarking everything to best effort before sending to me (which is preferred), and the other is not. am i odd to think that this is... odd? i also get a remarkable amount of hits against these destinations coming in on the cogent side, whereas i get none on the XO side. show policy-options prefix-list PUBLIC-BAD-NETS 10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; 224.0.0.0/4; ryan
On 10/9/14 10:35 AM, ryanL wrote:
you may remember me from the weird cogent route retention / loop problem i brought up last week. it remains unsolved by cogent to date.
also remembering i'm a relatively new cogent customer, i recently noticed some packets floating into my network that had cos and ipp markings on them. i figured i'd try to find where they were coming from, so i crafted up something like this and placed it inbound on my two transits (cogent and xo), excluding network control markings.
from { dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs1 cs2 cs3 cs4 cs5 ef ]; precedence [ 1 2 3 4 5 ]; }
all of it is coming in from cogent:
COGENT-NOT-BE -> 4217788987 XO-NOT-BE -> 0
i shifted all traffic to XO just to make sure. the XO counter doesn't budge.
seems like one transit is remarking everything to best effort before sending to me (which is preferred), and the other is not.
am i odd to think that this is... odd?
It's not that uncommon, but it's one of the reasons to sanitize on ingress if you don't want to see that (and absolutely if you're reusing them).
i also get a remarkable amount of hits against these destinations coming in on the cogent side, whereas i get none on the XO side.
show policy-options prefix-list PUBLIC-BAD-NETS 10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; 224.0.0.0/4;
you can add 100.64.0.0/10 to that list. ;)
ryan
i retract the blurb about the bad destinations coming in from cogent, as that obviously doesn't make a lot of sense. the spoofed traffic is actually arriving on my connection into an ix fabric. thx to john frazier for tickling my brain on that one. the upped markings, however, are definitely coming in from cogent.
participants (3)
-
joel jaeggli -
John van Oppen -
ryanL