mx up

[frederic]

well,

 the mx at fb.com is up today.

Re: Packet Loss to Google, others

[Frederic]

>From France. nothing

traceroute www.google.com
traceroute to www.l.google.com (74.125.39.104), 64 hops max, 40 byte
packets

 3  gi9-13.ccr01.par04.atlas.cogentco.com (149.6.164.177)  1 ms  1 ms  1
ms
 4  te1-3.mpd02.par01.atlas.cogentco.com (130.117.2.94)  2 ms
te3-3.mpd02.par01.atlas.cogentco.com (130.117.1.61)  2 ms
te1-3.mpd02.par01.atlas.cogentco.com (130.117.2.94)  2 ms
 5  te8-7.mpd02.lon01.atlas.cogentco.com (130.117.3.6)  10 ms
te9-7.mpd02.lon01.atlas.cogentco.com (130.117.3.134)  10 ms
te8-7.mpd02.lon01.atlas.cogentco.com (130.117.3.6)  10 ms
 6  google.lon01.atlas.cogentco.com (130.117.14.90)  10 ms  10 ms  10 ms
 7  64.233.175.27 (64.233.175.27)  10 ms (TOS=128!)  10 ms  10 ms
 8  72.14.233.63 (72.14.233.63) [MPLS: Label 386194 Exp 4]  14 ms
209.85.248.80 (209.85.248.80) [MPLS: Label 605502 Exp 4]  15 ms
209.85.241.84 (209.85.241.84) [MPLS: Label 529410 Exp 4]  11 ms
 9  209.85.250.141 (209.85.250.141)  17 ms 209.85.248.80 (209.85.248.80)
[MPLS: Label 452895 Exp 4]  16 ms 209.85.250.141 (209.85.250.141)  19 ms
10  209.85.254.112 (209.85.254.112)  18 ms 209.85.248.44 (209.85.248.44)
16 ms 209.85.254.116 (209.85.254.116)  17 ms
11  209.85.254.126 (209.85.254.126)  18 ms  22 ms  18 ms
12  fx-in-f104.google.com (74.125.39.104)  19 ms (TOS=0!) 209.85.254.116
(209.85.254.116)  18 ms (TOS=128!) fx-in-f104.google.com (74.125.39.104)
18 ms (TOS=0!)


4 mai 2009 à 11:55 -0400, Peter Beckman a écrit :
> Anyone else getting reports of Google (and other destinations) slowness?
> 
> >From Verizon FIOS Northern VA:
> 
> HOST: xxx.angryox.com Loss%   Snt   Last   Avg  Best  Wrst StDev
>1. xxx2  0.0%200.6   0.6   0.4   0.7   0.1
>2. 10.1.41.890.0%201.6   1.8   1.6   3.0   0.3
>3. G2-0-3-891.WASHDC-LCR-08.ver  0.0%201.6   1.7   1.6   2.0   0.1
>4. so-1-1-0-0.RES-BB-RTR2.veriz  0.0%202.2   2.7   2.1   7.5   1.4
>5. 0.ge-5-2-0.BR2.IAD8.ALTER.NE  0.0%202.9   2.9   2.7   3.1   0.1
>6. 204.255.168.300.0%206.2   9.4   6.1  70.6  14.4
>7. cr2.wswdc.ip.att.net  0.0%206.5   6.8   6.3   7.3   0.3
>8. 12.122.134.1570.0%206.2  27.8   6.1 196.8  51.4
>9. ???  100.0200.0   0.0   0.0   0.0   0.0
>   10. 216.239.48.108   55.0%20  328.2 335.7 326.8 389.6  20.3
>   11. 64.233.175.109   50.0%20  334.7 333.0 325.1 337.4   4.0
>   12. 72.14.236.74 30.0%20  328.3 328.3 324.3 335.5   3.5
>   13. he-in-f147.google.com40.0%20  335.2 328.6 323.6 337.0   4.5
> 
> >From Cox Fiber in Northern VA / DC:
> 
> HOST: xxx.angryox.com Loss%   Snt   Last   Avg  Best  Wrst StDev
>1. 70.164.19.3   0.0%200.2   0.2   0.2   0.4   0.1
>2. wsip-70-168-111-17.dc.dc.cox  0.0%201.7   9.6   1.5  77.5  20.9
>3. mrfddsrj01-ge706.rd.dc.cox.n  0.0%20   13.2   3.9   1.4  18.7   5.2
>4. ashbbbrj01-ae0.0.r2.as.cox.n  0.0%202.5   2.7   2.3   6.4   0.9
>5. 209.85.240.1360.0%20   39.5  10.5   3.7  63.0  15.3
>6. 64.233.175.1110.0%204.9   4.7   4.1   5.9   0.4
>7. 72.14.236.74  0.0%206.0   6.9   6.0   8.5   0.7
>8. he-in-f147.google.com 0.0%204.4   4.6   4.1   7.1   0.8
> 
> >From Level3 in New York:
> 
> HOST: xxx.angryox.com Loss%   Snt   Last   Avg  Best  Wrst StDev
>1. 208.72.185.1770.0%200.4  89.0   0.3 303.9  86.1
>2. 208.72.184.2450.0%200.4   0.8   0.3   7.7   1.6
>3. ge-6-7.car3.NewYork1.Level3.  0.0%200.5   2.3   0.5  29.9   6.6
>4. vlan69.csw1.NewYork1.Level3.  0.0%204.5   6.1   0.6  14.0   4.7
>5. ae-61-61.ebr1.NewYork1.Level  0.0%201.6   1.0   0.7   1.6   0.2
>6. ae-3-3.ebr4.Washington1.Leve  0.0%20   11.3  10.9   5.4  19.1   4.3
>7. ae-64-64.csw1.Washington1.Le  0.0%20   14.0  10.9   5.8  18.5   4.8
>8. ae-1-69.edge1.Washington1.Le  0.0%206.2   9.2   5.8  60.1  12.0
>9. ???  100.0200.0   0.0   0.0   0.0   0.0
>   10. 209.85.241.5050.0%20  330.9 330.3 329.1 331.6   0.9
>   11. 64.233.175.219   55.0%20  316.6 314.4 311.7 317.3   2.3
>   12. 72.14.236.66 60.0%20  317.4 319.6 314.1 328.0   4.5
>   13. he-in-f147.google.com45.0%20  323.9 321.5 312.1 332.9   6.9
> 
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com http://www.angryox.com/
> ---
> 
> 

Re: dynamic or static IPv6 prefixes to residential customers

[Hannes Frederic Sowa]

On Wed, Aug 03, 2011 at 01:14:52PM -0700, Owen DeLong wrote:
> > *Really*?  It bakes the endpoint MAC into the IP?  Well, that's miserably
> > poor architecture design.
> > 
> 
> It can and it is a common default. It is not required.
> 
> It's actually rather elegant architecture design for the goals it was
> implemented to accomplish.

 warned against using
hardware serial numbers in End-to-End protocols. As Privacy Extensions and DAD
actually work great in my environments I will stay with that option. Servers
will get static IP addresses. I don't see a need for embedding serial numbers
into IP addresses.

gruss,

  Hannes

Re: VRF/MPLS on Linux

[Hannes Frederic Sowa]

On Wed, Aug 24, 2011 at 10:06 AM, Brian Raaen  wrote:
> The only issue with this is that the Linux box is not acting as a router, but 
> as the egress devices.  I'm trying to figure out how to properly get my 
> application to 'color' the traffic.  standard BSD sockets appear to have no 
> concept of 'Labels'.  Still seeing what I can do to match the traffic.  I am 
> probably going to see if I can work out a hack with the development team to 
> use DSCP values to tag the traffic and then act accordingly on the ingress 
> router.  I appreciate all the ideas presented so far.

You could also have a look at linux namespaces if you want to manage
routing tables per process. Especially the new setns syscall could be
handy: 

Greetings,

  Hannes

Re: VRF/MPLS on Linux

[Hannes Frederic Sowa]

On Wed, Aug 24, 2011 at 7:37 PM, Jussi Peltola  wrote:
> Or exec your commands wrapped in route -T$TABLE exec $*

FYI, on linux you can use 'ip netns exec'. The subcommand is rather
new and you will only find it in the git repository.

Greetings,

  Hannes

Re: RADB/RIR Scraper

[Hannes Frederic Sowa]

On Wed, Sep 21, 2011 at 05:39:26AM -0700, Kate Gerry wrote:
> I'm looking for a good utility that I can run locally to scrape RADB, ARIN, 
> other RIRs to add to my or customer prefix lists... Anybody have a good tool 
> for this? I currently end up visiting https://www.dan.me.uk/filtergen and 
> creating one off that.
> 
> Thoughts?



or you could have alook at

| whois -h filtergen.level3.com -- help

if you get blocked by whois rate limiting.

Greetings,

  Hannes

Re: RADB/RIR Scraper

[Hannes Frederic Sowa]

On Wed, Sep 21, 2011 at 04:09:40PM +0200, Hannes Frederic Sowa wrote:
> <http://www.lexa.ru/snar/bgpq/index_en.html>

The url above links to the predecessor project. The code that I actually use
is available here:

  <http://snar.spb.ru/prog/bgpq3/>

Greetings,

  Hannes

Re: Google having issues?

[Hannes Frederic Sowa]

On Fri, Aug 16, 2013 at 11:29:30PM +, win...@team-metro.net wrote:
> I’m hearing reports of Google services (Search, Youtube, Mail, etc) going 
> down all over the place, providing extremely spotty service. Works fine for 
> me right now, but a lot of people seem to be having problems all over the 
> world.
> 
> Any ideas what’s going on?

Google rolled out an erroneous update for gmail. See

and comments.

Maybe this has something to do with these problems?

Greetings,

  Hannes

end-user ipv6 deployment and concerns about privacy

[Hannes Frederic Sowa]

Hello!

As the first IPv6 deployments for end-users are in the planning stage
in Germany, I realized I have not found any BCP for handling
addressing in those scenarios. IPv6 will make it a lot easier for
static address deployments but I wonder weather this is in the best
sense for the customers. As I normally come from the technical side I
prefer static addressing. But in the world of facebook and co. I
wonder if it would be a better to let the user have the choice. A
major provider of dsl here in Germany recently blogged about this [1].
Their proposal is to serve two subnets, one being a static one while
the other one will be dynamically allocated. I have no clue how the
user would switch between these subnets (without using some kind of
command line tools).

This is not about using privacy extensions as the subnet is sufficient
for identification.

Did you reach any conclusion on this matter?

Thanks,

  Hannes

[1] 
http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http://blog.1und1.de/2010/05/07/ipv6-totale-ueberwachung/&sl=de&tl=en

Re: end-user ipv6 deployment and concerns about privacy

[Hannes Frederic Sowa]

On Wed, Aug 18, 2010 at 7:53 AM, Marco Hogewoning  wrote:
>
> On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote:
>
>> prefer static addressing. But in the world of facebook and co. I
>> wonder if it would be a better to let the user have the choice. A
>
> What does facebook have to do with it ? Ever heard of cookies ?

Facebook as an example of a company whose founder stated that privacy
is old-fashioned. Cookies sit on another network-layer I am currently
not talking about. They can be removed more easily, most simply by
reinstalling your computer. The user *can* do something about cookies.

Re: end-user ipv6 deployment and concerns about privacy

[Hannes Frederic Sowa]

On Wed, Aug 18, 2010 at 7:12 AM, Mikael Abrahamsson  wrote:
> For people who want to use DNS and run services, they'll most likely want a
> static address/subnet that doesn't change in the first place (even though it
> should be handed out via DHCPv6-PD for ease). If someone wants to be
> anonymous, there is always TOR or other anonymising services.

Tor is fairly slow using it for every days internet surfing. Why don't
have sensible defaults for most users as default. For them I don't see
a need for static prefixes.

> Personally I prefer static for both IPv4 and IPv6 and have chosen providers
> accordingly historically. I also recommend this to others.

On the technical side it is clear. Static is the way to go.

Re: end-user ipv6 deployment and concerns about privacy

[Hannes Frederic Sowa]

On Wed, Aug 18, 2010 at 12:34 PM, Mark Smith wrote:
> Haven't really thought about it before.
>
> One thing to consider is that unless the preferred and valid lifetimes
> of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic
> - they'll eventually expire unless they're refreshed. The preferred and
> valid lifetimes for prefixes that are delegated to customers could be
> something that they might be able to change via a web portal, bounded
> to within what you as an ISP are happy with e.g. 1 to 30 days, rather
> than the absolute range of lifetime values supported. CPE could also
> potentially do the same thing with the range of subnets it has been
> delegated, by phasing in and out subnets over time on it's downstream
> interfaces. (The more subnets the better, so a /48 would be ideal for
> this.)

Yep, I am in favour of such setups. This will stress internal name
services(eg. netbios) but would be a solvable problem, I think.

> As you've mentioned, privacy addresses help. A related idea is
> described in "Transient addressing for related processes: Improved
> firewalling by using IPv6 and multiple addresses per host." [0], Peter
> M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64
> addresses in a /64, and has different applications on the same host use
> different source IPv6 addresses.
>
> Pretending to be multiple hosts, or even just one with privacy
> addresses, moving around multiple subnets, on delegated prefixes that
> change fairly regularly would probably mitigate quite a lot of the
> privacy concerns people may have related to IPv6 addressing.

If your ipv6-geolocation-service tells you that all /48 prefixes
behind this network are just static home-user networks, why not just
ignore the lower 64 bits or even the lower 80 bits? Privacy extensions
would be no help here. In IPv4-land I have the possibility to
reconnect and get a new unrelated ip-address every time.

hannes

Re: end-user ipv6 deployment and concerns about privacy

[Hannes Frederic Sowa]

On Wed, Aug 18, 2010 at 11:16 PM, Mark Smith wrote:
> They help because you're concerned about privacy. You didn't qualify
> that you're only concerned about privacy from geolocation services, so
> I described a mechanism that would provide you as much privacy as
> possible, while also being automatic, and also continuing to provide
> IPv6 Internet connectivity. No where was cryto mentioned either (on
> both our parts), yet that is also a privacy mechanism.

I tried to highlight the relationship between ipv4-address and
/48-prefixes in regard to privacy. If a provider is known for handling
out statically allocated prefixes, it should be possible to track its
clients by prefix. Sorry for picking a geolocation-service as an
example of where such information can originate from. It was
misleading.

> As a customer, it's relatively hard to hide from geolocation services
> because they use your IP address in combination with information that
> you don't have control over i.e. RIR / whois data. If a customer wants
> to hide from that, then they'll need to start tunnelling their traffic
> to another entry/exit point on the Internet.

Fully hiding from geolocation services is only possible with anonymity
services, yes.

> Much like security, privacy is relative. If you want to have
> bi-directional communications with another entity, you
> have to disclose your identity. How long you retain that identity is
> what makes one form of privacy more private than another.
> Customers who have high expectations of privacy won't trust their
> ISP at the time to preserve it - because, as the cliche goes, if you
> want something done properly, you need to do it yourself. So, as an
> ISP, you need to think about how much privacy you can provide, can
> afford to provide, and at what point it becomes irrelevant because your
> customer doesn't trust you to provide it at all.

But most people just don't care. My proposal is to have some kind of
sane defaults for them e.g. changing their prefix every week or in the
case of a reconnect. This would mitigate some of the many privacy
concerns in the internet a little bit. Of course all the already known
problems would still exist. And still people have to care about the
technology to reach a higher level of anonymity.

>>In IPv4-land I have the possibility to
>> reconnect and get a new unrelated ip-address every time.
>>
>
> They're issued by the same ISP, to they're related.

Ups. Unrelated in the sense of random ip from their pool, of course.

hannes

Re: end-user ipv6 deployment and concerns about privacy

[Hannes Frederic Sowa]

On Wed, Aug 18, 2010 at 11:41 PM, Jack Bates wrote:
> Web portals work fine, and honestly, it's not like you need to switch
> subnets, either. PPPoE/A implementations work great, as they are already
> designed to utilize radius backends to quickly alter static/dynamic on a
> session. For bridging setups, you have a variety of implementations and it
> becomes messier. Cisco, while maintaining RBE did away with the concept of
> proxy-nd, and didn't provide a mechanism for dynamically allocating the
> prefixes to the unnumbered interface. If you use dslam level controls,
> you'll most likely being using DHCPv6 TA addressing with PD on top of it,
> which works well. Most of which can support quick static/dynamic
> capabilities as it does with v4.

Thanks. I will have a deeper look in the standards. This sounds like a
viable solution to me. Albeit, I wonder if there is a drive for the
big ISPs to implement such features.

Re: eBGP Multihop

[Hannes Frederic Sowa]

On Thu, Sep 2, 2010 at 11:30 AM, Graham Beneke  wrote:
> I have been asked to investigate moving an entire network to multi-hop on
> all the eBGP sessions. Basically all upstreams, downstreams and peers will
> eBGP with a route reflector located in the core. This RR will be some kind
> of quagga or similar box. The dev guys want to be able to poke at the BGP
> feeds directly and do *magic* that standard router aren't capable of.
>
> My gut feel is that this is a bad idea. Besides anything else it makes sane
> link state detection very challenging - especially where we have multiple
> sessions with a peer.

I have not tried yet, but you could have a look at [1]. Perhaps it
could be extended to match your needs.
Do you run an IGP?

Hannes

[1] http://kbfd.sourceforge.net/