Re: Sflow billing or usage calculation software

[Deepak Jain]

Thanks for the pointers and suggestions!

Now I know I'm pushing my luck... but do certain vendors more fully 
embrace sFlow than others? maybe one of the whitebox vendors if not one 
of the majors?


Hacking support into something isn't the worse thing in the world, but 
if there is any experience on this to leverage off of, that is helpful.


TIA,

Deepak

On 4/16/2019 6:30 AM, Yang Yu wrote:

On Tue, Apr 16, 2019 at 2:14 AM Nick Morrison  wrote:

Actually the sflow standard is flexible, and there are many fields widely 
available, including input interface and output interface, vlan/vxlan/mpls 
headers, etc. The sending device just needs to support the fields.



Vendor support for sFlow extended data types seems to be very limited
and there are quite a few caveats on when the data is
missing/inaccurate.

RFC5472 Section 4.2 Using IPFIX for Billing (Reliability Limitations)
might be applicable to sFlow as well.
https://tools.ietf.org/html/rfc5472#section-4.2


Yang

Re: Ownership of Routers on Both Ends of Transnational Links

[Tom Beecher]

"Can anyone confirm that these are indeed managed by the Chinese ISPs (even
though they are physically located in the US according to the traceroute
and RTT analysis)?"

If a router is part of the CU AS, it's owed and managed by them. Physical
location isn't really relevant to your question.

On Tue, Apr 16, 2019 at 8:53 AM Pengxiong Zhu  wrote:

> Howdy folks,
>
> We are a group of researchers at UC Riverside conducting some measurement
> about transnational networks. In particular, we are interested in studying
> the ownership of routers on the two sides of transnational links.
>
> We have some concrete questions which we hope someone can shed some light
> on. Basically when we send packets from US/Canada to China, through
> traceroute and the RTT of each hop, we can locate the last hop in the US
> before the packets enter China (*there is a large jump of RTT of 100+ms
> from this hop onwards*). Oftentimes the ownership of such routers is
> ambiguous.
>
> These hops whose IPs seem to belong to US or European ISPs (*according to
> BGP info*) but their reverse DNS names have *chinaunicom* in it, which is
> a Chinese ISP.
> AS1299 Telia Company AB
> 62.115.170.57name = chinaunicom-ic-341501-sjo-b21.c.telia.net.
> 62.115.33.230name = chinaunicom-ic-302366-las-bb1.c.telia.net.
> 213.248.73.190  name = chinaunicom-ic-127288-sjo-b21.c.telia.net.
>
> AS701 Verizon Business
> 152.179.103.254  name = chinaunicom-gw.customer.alter.net.
>
> While the following routers, they don't have a reverse DNS name at all,
> which seem to be uncommon if they were managed by US or European ISPs but
> quite common for Chinese ISPs.
> AS6453 TATA COMMUNICATIONS (AMERICA) INC
> 63.243.205.90
> 66.110.59.118
>
> Can anyone confirm that these are indeed managed by the Chinese ISPs (even
> though they are physically located in the US according to the traceroute
> and RTT analysis)?
>
>
> Best,
> Pengxiong Zhu
> Department of Computer Science and Engineering
> University of California, Riverside
>

Re: Ownership of Routers on Both Ends of Transnational Links

[Pengxiong Zhu]

>
> this is totally true :) but... if the next hop after
> chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better
> than average chance that the
> chinaunicom-ic-341501-sjo-b21.c.telia.net
> address is a telia /30 (or /31) on the ptp link between CU/Telia. That
> Telia owns the ip space and that PROBABLY the customer identification
> is correct. (cu)


Yes, in our case, the next hops after all the six routers are some CU IPs.


Best,
Pengxiong Zhu
Department of Computer Science and Engineering
University of California, Riverside


On Tue, Apr 16, 2019 at 2:34 PM Christopher Morrow 
wrote:

> On Tue, Apr 16, 2019 at 5:19 PM Nimrod Levy 
> wrote:
> >
> >
> >
> > On Tue, Apr 16, 2019, 16:52 Ross Tajvar  wrote:
> >>
> >> I think it's clear that the IPs belong to Telia, but I understood
> James's point to be that the router using the IP in question may belong to
> China Unicom. (I agree with that, I was not thinking clearly this morning.)
> As this is an interconnect link, one side must belong to Telia and the
> other to China Unicom. The question, then, is which side are we looking at?
> Well, first I want to know how big the subnet is. I assume either /30 or
> /31. So, I do a reverse DNS lookup on all the IPs in the surrounding /30
> block:
> >> 62.115.170.56 - sjo-b21-link.telia.net
> >> 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net
> >> 62.115.170.58 - las-b24-link.telia.net
> >> 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net
> >> That looks like two /31s. Only one IP in each has the name of China
> Unicom in it, so that one is probably in use by China Unicom, and the other
> is probably in use by Telia.
> >
>
> that was my point yes.
>
> > I think we're making a lot of assumptions about how well PTR records are
> maintained. All of this could be totally accurate. Or...not...
>
> this is totally true :) but... if the next hop after
> chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better
> than average chance that the
> chinaunicom-ic-341501-sjo-b21.c.telia.net
>
> address is a telia /30 (or /31) on the ptp link between CU/Telia. That
> Telia owns the ip space and that PROBABLY the customer identification
> is correct. (cu)
>
> -chris
>

Re: Ownership of Routers on Both Ends of Transnational Links

[Pengxiong Zhu]

Thank you so much for your insightful replies. We are asking the right
people!

I checked the rest of them, they all seem to be /30 or /31s.
62.115.33.227 jax-b1-link.telia.net
62.115.33.228 telconet-ic-337544-jax-b1.c.telia.net
62.115.33.229 las-bb1-link.telia.net
* 62.115.33.230 chinaunicom-ic-302366-las-bb1.c.telia.net

213.248.73.185 adm-b4-link.telia.net
213.248.73.186 riot-ic-303251-adm-b4.c.telia.net
213.248.73.187
213.248.73.188
213.248.73.189 sjo-b21-link.telia.net  
* 213.248.73.190 chinaunicom-ic-127288-sjo-b21.c.telia.net.

152.179.103.250 0.xe-1-2-1.GW7.LAX1.ALTER.NET
152.179.103.250 chinaunicom-gw.customer.alter.net
152.179.103.251
152.179.103.252
152.179.103.253 0.xe-1-0-0.gw2.lax1.alter.net
* 152.179.103.254  chinaunicom-gw.customer.alter.net.

63.243.205.89 ix-xe-0-3-3-0.tcore1.sqn-san-jose.as6453.net

* 63.243.205.90
63.243.205.91
63.243.205.92
63.243.205.93  ix-xe-8-2-5-0.tcore1.sqn-san-jose.as6453.net


66.110.59.117  ix-xe-2-1-3-0-0.tcore1.lvw-los-angeles.as6453.net
* 66.110.59.118
66.110.59.119
66.110.59.120
66.110.59.121 ix-ae-2-611.tcore1.lvw-los-angeles.as6453.net

How about the two IPs(63.243.205.90, 66.110.59.118) that don't have a
reserve DNS name? Since they don't have any PTR records.

Best,
Pengxiong Zhu
Department of Computer Science and Engineering
University of California, Riverside


On Tue, Apr 16, 2019 at 1:50 PM Ross Tajvar  wrote:

> I think it's clear that the IPs belong to Telia, but I understood James's
> point to be that the router using the IP in question may belong to China
> Unicom. (I agree with that, I was not thinking clearly this morning.) As
> this is an interconnect link, one side must belong to Telia and the other
> to China Unicom. The question, then, is which side are we looking at? Well,
> first I want to know how big the subnet is. I assume either /30 or /31. So,
> I do a reverse DNS lookup on all the IPs in the surrounding /30 block:
> 62.115.170.56 - sjo-b21-link.telia.net
> 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net
> 62.115.170.58 - las-b24-link.telia.net
> 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net
> That looks like two /31s. Only one IP in each has the name of China Unicom
> in it, so that one is probably in use by China Unicom, and the other is
> probably in use by Telia.
>
> On Tue, Apr 16, 2019, 3:50 PM Christopher Morrow 
> wrote:
>
>> On Tue, Apr 16, 2019 at 10:59 AM James Jun 
>> wrote:
>>
>> > More likely, thease routers are China Unicom's routers in their US POP,
>> not managed by VZ/Telia.
>> > The /30s in this case are unmanaged IP transit hand-offs, coming in as
>> Nx10G or 100G.  When your
>> > IP transit provider assigns the /30, your router looks like it belongs
>> to your upstream, common
>> > mistake when interpreting traceroutes[1].
>> >
>>
>> $ nslookup 62.115.170.56
>> 56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net.
>>
>> if you model (as james says) each interconnect as a /30 or /31 ...
>> look for the adjacent ip and see the PTR for that ip.
>> (the above is your first link example's peer ip)
>>
>> > [1]: see Page 22 on
>> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
>> >
>> > James
>>
>

Re: Ownership of Routers on Both Ends of Transnational Links

[Christopher Morrow]

On Tue, Apr 16, 2019 at 5:19 PM Nimrod Levy  wrote:
>
>
>
> On Tue, Apr 16, 2019, 16:52 Ross Tajvar  wrote:
>>
>> I think it's clear that the IPs belong to Telia, but I understood James's 
>> point to be that the router using the IP in question may belong to China 
>> Unicom. (I agree with that, I was not thinking clearly this morning.) As 
>> this is an interconnect link, one side must belong to Telia and the other to 
>> China Unicom. The question, then, is which side are we looking at? Well, 
>> first I want to know how big the subnet is. I assume either /30 or /31. So, 
>> I do a reverse DNS lookup on all the IPs in the surrounding /30 block:
>> 62.115.170.56 - sjo-b21-link.telia.net
>> 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net
>> 62.115.170.58 - las-b24-link.telia.net
>> 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net
>> That looks like two /31s. Only one IP in each has the name of China Unicom 
>> in it, so that one is probably in use by China Unicom, and the other is 
>> probably in use by Telia.
>

that was my point yes.

> I think we're making a lot of assumptions about how well PTR records are 
> maintained. All of this could be totally accurate. Or...not...

this is totally true :) but... if the next hop after
chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better
than average chance that the
chinaunicom-ic-341501-sjo-b21.c.telia.net

address is a telia /30 (or /31) on the ptp link between CU/Telia. That
Telia owns the ip space and that PROBABLY the customer identification
is correct. (cu)

-chris

Re: Ownership of Routers on Both Ends of Transnational Links

[Ross Tajvar]

I think it's clear that the IPs belong to Telia, but I understood James's
point to be that the router using the IP in question may belong to China
Unicom. (I agree with that, I was not thinking clearly this morning.) As
this is an interconnect link, one side must belong to Telia and the other
to China Unicom. The question, then, is which side are we looking at? Well,
first I want to know how big the subnet is. I assume either /30 or /31. So,
I do a reverse DNS lookup on all the IPs in the surrounding /30 block:
62.115.170.56 - sjo-b21-link.telia.net
62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net
62.115.170.58 - las-b24-link.telia.net
62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net
That looks like two /31s. Only one IP in each has the name of China Unicom
in it, so that one is probably in use by China Unicom, and the other is
probably in use by Telia.

On Tue, Apr 16, 2019, 3:50 PM Christopher Morrow 
wrote:

> On Tue, Apr 16, 2019 at 10:59 AM James Jun  wrote:
>
> > More likely, thease routers are China Unicom's routers in their US POP,
> not managed by VZ/Telia.
> > The /30s in this case are unmanaged IP transit hand-offs, coming in as
> Nx10G or 100G.  When your
> > IP transit provider assigns the /30, your router looks like it belongs
> to your upstream, common
> > mistake when interpreting traceroutes[1].
> >
>
> $ nslookup 62.115.170.56
> 56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net.
>
> if you model (as james says) each interconnect as a /30 or /31 ...
> look for the adjacent ip and see the PTR for that ip.
> (the above is your first link example's peer ip)
>
> > [1]: see Page 22 on
> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
> >
> > James
>

Re: Ownership of Routers on Both Ends of Transnational Links

[Christopher Morrow]

On Tue, Apr 16, 2019 at 10:59 AM James Jun  wrote:

> More likely, thease routers are China Unicom's routers in their US POP, not 
> managed by VZ/Telia.
> The /30s in this case are unmanaged IP transit hand-offs, coming in as Nx10G 
> or 100G.  When your
> IP transit provider assigns the /30, your router looks like it belongs to 
> your upstream, common
> mistake when interpreting traceroutes[1].
>

$ nslookup 62.115.170.56
56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net.

if you model (as james says) each interconnect as a /30 or /31 ...
look for the adjacent ip and see the PTR for that ip.
(the above is your first link example's peer ip)

> [1]: see Page 22 on 
> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
>
> James

Re: Ownership of Routers on Both Ends of Transnational Links

[James Jun]

On Tue, Apr 16, 2019 at 09:13:30AM -0400, Ross Tajvar wrote:
> "company-ic" and "company-gw" are commonly used names for /30s used for
> interconnection to a customer or another carrier. Those routers are likely
> owned/managed by Telia/Verizon.
> 

I highly doubt VZ or Telia owns and provides a Big Expensive Router as CPE 
sitting on US landing
POP for a major international carrier.

More likely, thease routers are China Unicom's routers in their US POP, not 
managed by VZ/Telia.
The /30s in this case are unmanaged IP transit hand-offs, coming in as Nx10G or 
100G.  When your
IP transit provider assigns the /30, your router looks like it belongs to your 
upstream, common
mistake when interpreting traceroutes[1].

[1]: see Page 22 on 
https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf

James

Re: Ownership of Routers on Both Ends of Transnational Links

[Ross Tajvar]

"company-ic" and "company-gw" are commonly used names for /30s used for
interconnection to a customer or another carrier. Those routers are likely
owned/managed by Telia/Verizon.

On Tue, Apr 16, 2019 at 8:54 AM Pengxiong Zhu  wrote:

> Howdy folks,
>
> We are a group of researchers at UC Riverside conducting some measurement
> about transnational networks. In particular, we are interested in studying
> the ownership of routers on the two sides of transnational links.
>
> We have some concrete questions which we hope someone can shed some light
> on. Basically when we send packets from US/Canada to China, through
> traceroute and the RTT of each hop, we can locate the last hop in the US
> before the packets enter China (*there is a large jump of RTT of 100+ms
> from this hop onwards*). Oftentimes the ownership of such routers is
> ambiguous.
>
> These hops whose IPs seem to belong to US or European ISPs (*according to
> BGP info*) but their reverse DNS names have *chinaunicom* in it, which is
> a Chinese ISP.
> AS1299 Telia Company AB
> 62.115.170.57name = chinaunicom-ic-341501-sjo-b21.c.telia.net.
> 62.115.33.230name = chinaunicom-ic-302366-las-bb1.c.telia.net.
> 213.248.73.190  name = chinaunicom-ic-127288-sjo-b21.c.telia.net.
>
> AS701 Verizon Business
> 152.179.103.254  name = chinaunicom-gw.customer.alter.net.
>
> While the following routers, they don't have a reverse DNS name at all,
> which seem to be uncommon if they were managed by US or European ISPs but
> quite common for Chinese ISPs.
> AS6453 TATA COMMUNICATIONS (AMERICA) INC
> 63.243.205.90
> 66.110.59.118
>
> Can anyone confirm that these are indeed managed by the Chinese ISPs (even
> though they are physically located in the US according to the traceroute
> and RTT analysis)?
>
>
> Best,
> Pengxiong Zhu
> Department of Computer Science and Engineering
> University of California, Riverside
>

SAFNOG-5 & iWeek 2019

[Mark Tinka]

Hello all.

We are proud to announce that for the 5th installment of SAFNOG, we will
be returning to Johannesburg, South Africa where it all began.

SAFNOG and iWeek will be teaming up again this year to bring you
SAFNOG-5 and the 2019 edition of iWeek in Johannesburg, South Africa.

The meeting will be held on 26-28 August 2019 at the Indaba Hotel, in
Fourways, Johannesburg, South Africa.

More details about the meeting will be posted to our web site in the
coming weeks:

    http://www.safnog.org/

We look forward to seeing you in Johannesburg. Thanks.

Mark.

Ownership of Routers on Both Ends of Transnational Links

[Pengxiong Zhu]

Howdy folks,

We are a group of researchers at UC Riverside conducting some measurement
about transnational networks. In particular, we are interested in studying
the ownership of routers on the two sides of transnational links.

We have some concrete questions which we hope someone can shed some light
on. Basically when we send packets from US/Canada to China, through
traceroute and the RTT of each hop, we can locate the last hop in the US
before the packets enter China (*there is a large jump of RTT of 100+ms
from this hop onwards*). Oftentimes the ownership of such routers is
ambiguous.

These hops whose IPs seem to belong to US or European ISPs (*according to
BGP info*) but their reverse DNS names have *chinaunicom* in it, which is a
Chinese ISP.
AS1299 Telia Company AB
62.115.170.57name = chinaunicom-ic-341501-sjo-b21.c.telia.net.
62.115.33.230name = chinaunicom-ic-302366-las-bb1.c.telia.net.
213.248.73.190  name = chinaunicom-ic-127288-sjo-b21.c.telia.net.

AS701 Verizon Business
152.179.103.254  name = chinaunicom-gw.customer.alter.net.

While the following routers, they don't have a reverse DNS name at all,
which seem to be uncommon if they were managed by US or European ISPs but
quite common for Chinese ISPs.
AS6453 TATA COMMUNICATIONS (AMERICA) INC
63.243.205.90
66.110.59.118

Can anyone confirm that these are indeed managed by the Chinese ISPs (even
though they are physically located in the US according to the traceroute
and RTT analysis)?


Best,
Pengxiong Zhu
Department of Computer Science and Engineering
University of California, Riverside

Fwd: [safnog] SAFNOG-5 and iWeek 2019

[Mark Tinka]

FYI.

Mark.

 Forwarded Message 
Subject:[safnog-mc] SAFNOG-5 and iWeek 2019
Date:   Thu, 11 Apr 2019 14:59:24 +
From:   Portia Rabonda - FLEXOPTIX 
To: safnog-mc , saf...@safnog.org




SAFNOG-5 and iWeek 2019

 




 


  SAFNOG-5 & iWeek 2019

www.safnog.org


 


 


 

https://gallery.mailchimp.com/88792d6999cc80b3de7b079b8/images/1fc94a4f-c2fc-4ed3-99a6-4261679bf7dd.png

 


 


 

We are proud to announce that for the 5th instalment of SAFNOG, we will
be returning to Johannesburg, South Africa where it all began.

SAFNOG and iWeek will be teaming up again this year to bring you
SAFNOG-5 and the 2019 edition of iWeek in Johannesburg, South Africa.

The meeting will be held on 26-28 August 2019 at the Indaba Hotel, in
Fourways,  Johannesburg, South Africa. 

For more details and updates on the event, visit our
website www.safnog.org

 and www.iweek.org.za


 


 


 

*Find Out More*


https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-facebook-48.png




https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-twitter-48.png




https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-instagram-48.png




https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-link-48.png




https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-linkedin-48.png




https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-youtube-48.png


 


 

/Copyright © /SAFNOG ORG 2019/, All rights reserved./

*Our mailing address is:*
saf...@safnog.org 

Want to change how you receive these emails?
You can update your preferences
 or
unsubscribe from this list
.
 






https://gmail.us20.list-manage.com/track/open.php?u=88792d6999cc80b3de7b079b8=be6ce54966=7ffa6a58f8

___
safnog-mc mailing list
safnog...@safnog.org
http://lists.safnog.org/listinfo/safnog-mc

Re: Sflow billing or usage calculation software

[Yang Yu]

>On Tue, Apr 16, 2019 at 2:14 AM Nick Morrison  wrote:
>
> Actually the sflow standard is flexible, and there are many fields widely 
> available, including input interface and output interface, vlan/vxlan/mpls 
> headers, etc. The sending device just needs to support the fields.


Vendor support for sFlow extended data types seems to be very limited
and there are quite a few caveats on when the data is
missing/inaccurate.

RFC5472 Section 4.2 Using IPFIX for Billing (Reliability Limitations)
might be applicable to sFlow as well.
https://tools.ietf.org/html/rfc5472#section-4.2


Yang

Re: Sflow billing or usage calculation software

[Nick Morrison]

> On 16. Apr 2019, at 00:21, Deepak Jain  wrote:
> 
> I'm only aware of Sflow being IP/protocol/etc aware.

Actually the sflow standard is flexible, and there are many fields widely 
available, including input interface and output interface, vlan/vxlan/mpls 
headers, etc. The sending device just needs to support the fields.

To give you an idea of some of the fields you can query from a TS server for 
example, here’s a description of one of the tables in the database: 
https://inmon.com/sentinel_help/8.0/help/en/report/api_view_traffic.shtml

Browse sflow.org for more fun info, including ideas for running sflow agents on 
your hypervisors (for eg correlating CPU and RAM usage per VM) etc :-)

Nick