date:20111208

Re: Juniper <-> Cisco IPv6 BGP peering

2011-12-08 Thread Jen Linkova

On Thu, Dec 8, 2011 at 11:53 AM, Randy Carpenter  wrote:
> Tried that. I agree with others that it is an NDP issue. NDP for the GUA is 
> fine, but just not for the link local. Is there something that would block 
> only link local by default?
>
> I should add that I have another uplink to a different provider that works 
> perfectly. The other end is Juniper for that one.

Just to begin with:
0) Does your Juniper device have the neighbor cache entry for Cisco
link-local address? What is the state of the entry?

Can you get packet capture on both sides?

1) is Cisco sending NS packets?
2) is your Juniper receiving them?
3) is Juniper device sending anything back?
4) are those NA reaching Cisco?

Any switch on the path?

[lazy mode on] I'd also suggest:
 - debug ipv6 nd on cisco
 - checking for bugs for IOS and JunOS versions you are using

> On Dec 7, 2011, at 17:53, Peter Rubenstein  wrote:
>
>> Try setting local-address in the bgp neighbor config on the Juniper side?
>>
>> --Peter
>>
>> On Dec 7, 2011, at 4:54 PM, Randy Carpenter  wrote:
>>
>>>
>>> Does anyone have any suggestions on setting up BGP peering between Juniper 
>>> (SRX) and Cisco?
>>>
>>> I successfully have cisco-cisco and juniper-juniper without problems.
>>>
>>> When I am trying to peer to one of my upstreams (who has cisco) with my 
>>> Juniper SRX, They are seeing the link-local address as the next-hop, but 
>>> are unable to get an ND entry for it, and thus cannot forward traffic to me.
>>>
>>>
>>> -Randy
>>>
>>> --
>>> | Randy Carpenter
>>> | Vice President - IT Services
>>> | Red Hat Certified Engineer
>>> | First Network Group, Inc.
>>> | (800)578-6381, Opt. 1
>>> 
>>>
>>>
>>
>



-- 
SY, Jen Linkova aka Furry

seeking clueful assistance at speakeasy-now-megapath

2011-12-08 Thread Matthew Kaufman


See subject. Contact me off-list please.

Matthew Kaufman

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

2011-12-08 Thread Jimmy Hess

On Thu, Dec 8, 2011 at 7:00 PM, Michael Painter  wrote:
> Sean's apology for their 'mistake' rings hollow.
> They've had almost 4 months to implement a solution to rectify these
> 'mistakes', but chose to ignore it until the uproar caused by the nmap
[snip]

I would say it doesn't read 'unhollow'   It's just plain inadequate
and doesn't do anything to settle the concerns,  whether you accept
the apology as sincere or not.  Yes, it is obviously a mistake...
but the clear  mistake is not a technical one of "bundling an open
source application";   the mistake is actually a bad decision. The
decision to "bundle" anything;  something they obviously haven't
admitted yet is a bad practice or failure in judgement.

Apparently they don't comprehend that, if you are a download
repository, you don't surprise your users by tampering with files,
regardless of whether the application is open source or proprietary.
Oh..  that they apologized about one thing, essentially means they
admit the existence of the other bad thing that they don't apologize
for.

Their explanation of the problem is they don't intend to bundle open
source software.
Well,  that implies there _ARE_  things they intend to tamper with the
file for by bundling in their own installer.  Otherwise they wouldn't
have written the bundling system in the first place.

I'm saying...  if  Download.com  wanted to continue to be a trusted
download site,
they shouldn't have been tampering with any author application files,
whether open source or not.
They got caught red-handed.

The de facto admission that they do ever,   has one simple implication...
Download.com  is simply not to be trusted,  anymore, to not bundle
executables with unknown software.

In my book,  nothing  download.com  does can redeem their trust at
this point,  they destroyed their sites and CNET's status permanently;
  end users need to be warned that they are no longer safe for any
download,  even "known programs",  period.

--
-JH

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

2011-12-08 Thread Michael Painter


Kyle Duren wrote:

http://download.cnet.com/8301-2007_4-57338809-12/a-note-from-sean-regarding-the-download.com-installer/

In case no one saw this yet.

-Kyle


Sean's apology for their 'mistake' rings hollow.
They've had almost 4 months to implement a solution to rectify these 'mistakes', but chose to ignore it until the uproar 
caused by the nmap community.

http://www.extremetech.com/computing/93504-download-com-wraps-downloads-in-bloatware-lies-about-motivations

It's always about the Money.

--Michael

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

2011-12-08 Thread Kyle Duren

http://download.cnet.com/8301-2007_4-57338809-12/a-note-from-sean-regarding-the-download.com-installer/

In case no one saw this yet.

-Kyle

Re: {Spam?} Re: Traceroute explanation

2011-12-08 Thread Raymond Dijkxhoorn


Hi!


Using LFT:
root@debian:~# lft 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  172.28.1.1 (172.28.1.1)  0.798 ms  0.711 ms
2  10.16.0.2 (10.16.0.2)  0.414 ms  0.331 ms
3  41.200.16.1 (41.200.16.1)  11.400 ms  11.474 ms
4  172.17.2.25 (172.17.2.25)  10.184 ms  11.322 ms
5  213.140.58.10 (213.140.58.10)  11.264 ms  10.623 ms
6  212.73.253.65 (212.73.253.65)  30.330 ms  32.391 ms
7  ae-4-5.bar1.Marseille1.Level3.net (4.69.151.9)  32.177 ms  32.219 ms
8  ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238)  42.160 ms  42.318 ms



root@debian:~# lft www.rri.ro
traceroute to www.rri.ro (193.231.72.52), 30 hops max, 60 byte packets
1  172.28.1.1 (172.28.1.1)  0.819 ms  0.737 ms
2  10.16.0.2 (10.16.0.2)  0.402 ms  0.335 ms
3  41.200.16.1 (41.200.16.1)  10.592 ms  10.209 ms
4  172.17.2.25 (172.17.2.25)  10.146 ms  10.559 ms
5  213.140.58.10 (213.140.58.10)  11.258 ms  10.369 ms
6  pos14-0.palermo9.pal.seabone.net (195.22.197.125)  30.817 ms  31.439 ms
7  ae-5-6.bar2.Marseille1.Level3.net (4.69.151.13)  33.968 ms  31.395 ms
8  ge-0-0-0.mil19.ip4.tinet.net (213.200.68.145)  57.178 ms 
xe-1-1-0.mil10.ip4.

tinet.net (213.200.68.61)  57.749 ms
9  ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249)  61.835 ms  62.317 ms
10  euroweb-gw.ip4.tinet.net (77.67.66.154)  61.361 ms  60.292 ms
11  v15-core1.stsisp.ro (193.151.28.1)  163.662 ms  144.245 ms
12  inet-crli1.qrli1.buh.ew.ro (81.24.28.226)  91.309 ms  89.880 ms
13  193.231.72.10 (193.231.72.10)  80.790 ms  79.354 ms
14  ip4-89-238-225-90.euroweb.ro (89.238.225.90)  91.067 ms  90.906 ms
15  webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52)  79.196 ms  79.389 
ms

root@debian:~#


lft -A snows ASN also.

Example:

[root@lft ~]# lft -A www.rri.ro -d 80
Tracing .T
TTL LFT trace to webrri.rri.ro.72.231.193.in-addr.arpa 
(193.231.72.52):80/tcp

 1  [34108] vrrp-253.bbd.prolocation.net (95.128.88.253) 0.3/0.3ms
 2  [41887] breedband-delft-rc02-gige-1.prolocation.net (94.228.128.57) 
11.8/1.4ms

 3  [12871] gigabone10-3.prolocation.net (213.197.27.165) 1.3/1.4ms
 4  [1200] amx1.fra.ew.ro (195.69.144.121) 59.5/31.5ms
 5  [6663] inet-qrli1.crli1.buh.ew.ro (81.24.28.225) 38.1/38.1ms
 6  [6663] inet-crli1.qrli1.buh.ew.ro (81.24.28.226) 37.4/37.5ms
 7  [6663] qrli11.drli1.buh.ew.ro (81.24.28.242) 37.9/37.9ms
 8  [6663] ip4-89-238-225-90.euroweb.ro (89.238.225.90) 37.7/37.7ms
 9  [34808] 193.231.72.10 37.9/37.9ms
10  [34808] [target open] webrri.rri.ro.72.231.193.in-addr.arpa 
(193.231.72.52):80 37.8/38.0ms


Bye,
Raymond.

Re: Traceroute explanation

2011-12-08 Thread Meftah Tayeb

bone, then level3, then Tinet, then level3, then tinet ?
if is that a routing stufs that i don't know, please let me know :)
i never saw that befaure

 Meftah Tayeb
IT Consulting
http://www.tmvoip.com/
phone: +21321656139
Mobile: +213660347746


__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com








--Steve Bellovin, https://www.cs.columbia.edu/~smb







__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com






__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: Traceroute explanation

2011-12-08 Thread Raymond Dijkxhoorn

Hai!

Check with lft or mtr ... 

Thanks,
Raymond Dijkxhoorn, Prolocation


Op 7 dec. 2011 om 20:56 heeft "Meftah Tayeb"  het 
volgende geschreven:

> please tel me how to ?
> i don't know astraceroute:)
> 
> - Original Message - From: "Steven Bellovin" 
> To: "Meftah Tayeb" 
> Cc: "Fred Baker" ; 
> Sent: Thursday, December 08, 2011 11:33 PM
> Subject: Re: Traceroute explanation
> 
> 
> On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:
> 
>> big thank for that
>> but, i am testing that for one day :)
> 
> 
> 
> Can you do an AStraceroute or manually translate those addresses into AS#s?
> That is, might level3 and tinet  be using multiple AS#s, in which case this
> isn't unreasonable?
> 
> 
> 
> 
> 
>> 
>> 
>> - Original Message - From: "Fred Baker" 
>> To: "Meftah Tayeb" 
>> Cc: 
>> Sent: Thursday, December 08, 2011 11:23 PM
>> Subject: Re: Traceroute explanation
>> 
>> 
>> This is just a guess, but I'll bet the route changed while you were 
>> measuring it.
>> 
>> Traceroute sends a request, awaits a response, sends a request, ... Suppose 
>> that the route was
>> 
>> 172.28.0.1 -> 10.16.0.2
>> -> 41.200.16.1
>> -> 172.17.2.25
>> -> 213.140.58.10
>> -> 195.22.195.125
>> -> 4.69.151.13
>> -> 213.200.68.61
>> -> somewhere else
>> 
>> and after the test got that far, two systems got inserted into the path 
>> before level3, resulting in the route entering level3 at a different point, 
>> 4.69.141.249. What you now have is
>> 
>> 172.28.0.1 -> 10.16.0.2
>> -> 41.200.16.1
>> -> 172.17.2.25
>> -> 213.140.58.10
>> -> 195.22.195.125
>> -> unknown
>> -> unknown
>> -> 4.69.141.249
>> -> 77.67.66.154
>> -> and so on
>> 
>> The effect would be to get a result like this.
>> 
>> Next time you see something like this, suggestion: repeat the traceroute and 
>> see what you get.
>> 
>> 
>> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
>> 
>>> Hey folks,
>>> i see a strange traceroute there
>>> 
>>> Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
>>> avec un maximum de 30 sauts :
>>> 
>>> 1 2 ms 1 ms 1 ms  172.28.0.1
>>> 2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
>>> 310 ms10 ms13 ms  41.200.16.1
>>> 411 ms10 ms11 ms  172.17.2.25
>>> 521 ms21 ms21 ms  213.140.58.10
>>> 634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
>>> [195.22.197.125
>>> ]
>>> 734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net 
>>> [4.69.151.13]
>>> 8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>>> 974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
>>> [4.69.141.249]
>>> 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>>> 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
>>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>>> 1381 ms81 ms81 ms  193.231.72.10
>>> 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>>> 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
>>> [193.231.7
>>> 2.52]
>>> Itinéraire déterminé.
>>> C:\Documents and Settings\TAYEB>
>>> Seabone, then level3, then Tinet, then level3, then tinet ?
>>> if is that a routing stufs that i don't know, please let me know :)
>>> i never saw that befaure
>>> 
>>>  Meftah Tayeb
>>> IT Consulting
>>> http://www.tmvoip.com/
>>> phone: +21321656139
>>> Mobile: +213660347746
>>> 
>>> 
>>> __ Information from ESET NOD32 Antivirus, version of virus 
>>> signature database 6695 (20111208) __
>>> 
>>> The message was checked by ESET NOD32 Antivirus.
>>> 
>>> http://www.eset.com
>>> 
>> 
>> 
>> 
>> __ Information from ESET NOD32 Antivirus, version of virus signature 
>> database 6695 (20111208) __
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> __ Information from ESET NOD32 Antivirus, version of virus signature 
>> database 6695 (20111208) __
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> 
> 
> 
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
>

Re: Traceroute explanation

2011-12-08 Thread Steven Bellovin

I don't know what platform you're using, but there's a separate command.  See
http://www.shrubbery.net/astraceroute/ .  If you're using Linux, there's 
probably
a package in your favorite repository.  There seem to be other variants floating
around the net.  If you're using Windows, I have no idea what's available.


On Dec 7, 2011, at 2:56 16PM, Meftah Tayeb wrote:

> please tel me how to ?
> i don't know astraceroute:)
> 
> - Original Message - From: "Steven Bellovin" 
> To: "Meftah Tayeb" 
> Cc: "Fred Baker" ; 
> Sent: Thursday, December 08, 2011 11:33 PM
> Subject: Re: Traceroute explanation
> 
> 
> On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:
> 
>> big thank for that
>> but, i am testing that for one day :)
> 
> 
> 
> Can you do an AStraceroute or manually translate those addresses into AS#s?
> That is, might level3 and tinet  be using multiple AS#s, in which case this
> isn't unreasonable?
> 
> 
> 
> 
> 
>> 
>> 
>> - Original Message - From: "Fred Baker" 
>> To: "Meftah Tayeb" 
>> Cc: 
>> Sent: Thursday, December 08, 2011 11:23 PM
>> Subject: Re: Traceroute explanation
>> 
>> 
>> This is just a guess, but I'll bet the route changed while you were 
>> measuring it.
>> 
>> Traceroute sends a request, awaits a response, sends a request, ... Suppose 
>> that the route was
>> 
>> 172.28.0.1 -> 10.16.0.2
>> -> 41.200.16.1
>> -> 172.17.2.25
>> -> 213.140.58.10
>> -> 195.22.195.125
>> -> 4.69.151.13
>> -> 213.200.68.61
>> -> somewhere else
>> 
>> and after the test got that far, two systems got inserted into the path 
>> before level3, resulting in the route entering level3 at a different point, 
>> 4.69.141.249. What you now have is
>> 
>> 172.28.0.1 -> 10.16.0.2
>> -> 41.200.16.1
>> -> 172.17.2.25
>> -> 213.140.58.10
>> -> 195.22.195.125
>> -> unknown
>> -> unknown
>> -> 4.69.141.249
>> -> 77.67.66.154
>> -> and so on
>> 
>> The effect would be to get a result like this.
>> 
>> Next time you see something like this, suggestion: repeat the traceroute and 
>> see what you get.
>> 
>> 
>> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
>> 
>>> Hey folks,
>>> i see a strange traceroute there
>>> 
>>> Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
>>> avec un maximum de 30 sauts :
>>> 
>>> 1 2 ms 1 ms 1 ms  172.28.0.1
>>> 2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
>>> 310 ms10 ms13 ms  41.200.16.1
>>> 411 ms10 ms11 ms  172.17.2.25
>>> 521 ms21 ms21 ms  213.140.58.10
>>> 634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
>>> [195.22.197.125
>>> ]
>>> 734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net 
>>> [4.69.151.13]
>>> 8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>>> 974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
>>> [4.69.141.249]
>>> 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>>> 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
>>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>>> 1381 ms81 ms81 ms  193.231.72.10
>>> 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>>> 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
>>> [193.231.7
>>> 2.52]
>>> Itinéraire déterminé.
>>> C:\Documents and Settings\TAYEB>
>>> Seabone, then level3, then Tinet, then level3, then tinet ?
>>> if is that a routing stufs that i don't know, please let me know :)
>>> i never saw that befaure
>>> 
>>>  Meftah Tayeb
>>> IT Consulting
>>> http://www.tmvoip.com/
>>> phone: +21321656139
>>> Mobile: +213660347746
>>> 
>>> 
>>> __ Information from ESET NOD32 Antivirus, version of virus 
>>> signature database 6695 (20111208) __
>>> 
>>> The message was checked by ESET NOD32 Antivirus.
>>> 
>>> http://www.eset.com
>>> 
>> 
>> 
>> 
>> _

Re: Traceroute explanation

2011-12-08 Thread Harsha V. Madhyastha

Another explanation could be load balancing. As Fred mentioned, traceroute 
sends out different packets for different hops on the path and since these 
packets have different headers, load balancers on the path may hash packets 
with different TTL values on to different paths.

Check out http://www.paris-traceroute.net/ for more information.

--Harsha

On Dec 8, 2011, at 1:23 PM, Fred Baker wrote:

> This is just a guess, but I'll bet the route changed while you were measuring 
> it.
> 
> Traceroute sends a request, awaits a response, sends a request, ... Suppose 
> that the route was
> 
> 172.28.0.1 -> 10.16.0.2
>   -> 41.200.16.1
>   -> 172.17.2.25
>   -> 213.140.58.10
>   -> 195.22.195.125
>   -> 4.69.151.13
>   -> 213.200.68.61
>   -> somewhere else
> 
> and after the test got that far, two systems got inserted into the path 
> before level3, resulting in the route entering level3 at a different point, 
> 4.69.141.249. What you now have is
> 
> 172.28.0.1 -> 10.16.0.2
>   -> 41.200.16.1
>   -> 172.17.2.25
>   -> 213.140.58.10
>   -> 195.22.195.125
>   -> unknown
>   -> unknown
>   -> 4.69.141.249
>   -> 77.67.66.154
>   -> and so on
> 
> The effect would be to get a result like this.
> 
> Next time you see something like this, suggestion: repeat the traceroute and 
> see what you get.
> 
> 
> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
> 
>> Hey folks,
>> i see a strange traceroute there
>> 
>> Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
>> avec un maximum de 30 sauts :
>> 
>> 1 2 ms 1 ms 1 ms  172.28.0.1
>> 2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
>> 310 ms10 ms13 ms  41.200.16.1
>> 411 ms10 ms11 ms  172.17.2.25
>> 521 ms21 ms21 ms  213.140.58.10
>> 634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
>> [195.22.197.125
>> ]
>> 734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>> 8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>> 974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
>> [4.69.141.249]
>> 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>> 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>> 1381 ms81 ms81 ms  193.231.72.10
>> 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>> 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
>> [193.231.7
>> 2.52]
>> Itinéraire déterminé.
>> C:\Documents and Settings\TAYEB>
>> Seabone, then level3, then Tinet, then level3, then tinet ?
>> if is that a routing stufs that i don't know, please let me know :)
>> i never saw that befaure
>> 
>>   Meftah Tayeb
>> IT Consulting
>> http://www.tmvoip.com/ 
>> phone: +21321656139
>> Mobile: +213660347746
>> 
>> 
>> __ Information from ESET NOD32 Antivirus, version of virus signature 
>> database 6695 (20111208) __
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
> 
>

Re: Traceroute explanation

2011-12-08 Thread Meftah Tayeb

please tel me how to ?
i don't know astraceroute:)

- Original Message - 
From: "Steven Bellovin" 

To: "Meftah Tayeb" 
Cc: "Fred Baker" ; 
Sent: Thursday, December 08, 2011 11:33 PM
Subject: Re: Traceroute explanation

On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:

big thank for that
but, i am testing that for one day :)

Can you do an AStraceroute or manually translate those addresses into AS#s?
That is, might level3 and tinet  be using multiple AS#s, in which case this
isn't unreasonable?

- Original Message - From: "Fred Baker" 
To: "Meftah Tayeb" 
Cc: 
Sent: Thursday, December 08, 2011 11:23 PM
Subject: Re: Traceroute explanation

This is just a guess, but I'll bet the route changed while you were 
measuring it.

Traceroute sends a request, awaits a response, sends a request, ... 
Suppose that the route was

172.28.0.1 -> 10.16.0.2
 -> 41.200.16.1
 -> 172.17.2.25
 -> 213.140.58.10
 -> 195.22.195.125
 -> 4.69.151.13
 -> 213.200.68.61
 -> somewhere else

and after the test got that far, two systems got inserted into the path 
before level3, resulting in the route entering level3 at a different 
point, 4.69.141.249. What you now have is

172.28.0.1 -> 10.16.0.2
 -> 41.200.16.1
 -> 172.17.2.25
 -> 213.140.58.10
 -> 195.22.195.125
 -> unknown
 -> unknown
 -> 4.69.141.249
 -> 77.67.66.154
 -> and so on

The effect would be to get a result like this.

Next time you see something like this, suggestion: repeat the traceroute 
and see what you get.

On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:

Hey folks,
i see a strange traceroute there

Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
avec un maximum de 30 sauts :

1 2 ms 1 ms 1 ms  172.28.0.1
2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
310 ms10 ms13 ms  41.200.16.1
411 ms10 ms11 ms  172.17.2.25
521 ms21 ms21 ms  213.140.58.10
634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
[195.22.197.125

]
734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net 
[4.69.151.13]
8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net 
[213.200.68.61]
974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
[4.69.141.249]

1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
1381 ms81 ms81 ms  193.231.72.10
1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro 
[89.238.225.90]
1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
[193.231.7

2.52]
Itinéraire déterminé.
C:\Documents and Settings\TAYEB>
Seabone, then level3, then Tinet, then level3, then tinet ?
if is that a routing stufs that i don't know, please let me know :)
i never saw that befaure

  Meftah Tayeb
IT Consulting
http://www.tmvoip.com/
phone: +21321656139
Mobile: +213660347746

__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

--Steve Bellovin, https://www.cs.columbia.edu/~smb

__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: Traceroute explanation

2011-12-08 Thread Steven Bellovin

On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:

> big thank for that
> but, i am testing that for one day :)



Can you do an AStraceroute or manually translate those addresses into AS#s?  
That is, might level3 and tinet  be using multiple AS#s, in which case this
isn't unreasonable?





> 
> 
> - Original Message - From: "Fred Baker" 
> To: "Meftah Tayeb" 
> Cc: 
> Sent: Thursday, December 08, 2011 11:23 PM
> Subject: Re: Traceroute explanation
> 
> 
> This is just a guess, but I'll bet the route changed while you were measuring 
> it.
> 
> Traceroute sends a request, awaits a response, sends a request, ... Suppose 
> that the route was
> 
> 172.28.0.1 -> 10.16.0.2
>  -> 41.200.16.1
>  -> 172.17.2.25
>  -> 213.140.58.10
>  -> 195.22.195.125
>  -> 4.69.151.13
>  -> 213.200.68.61
>  -> somewhere else
> 
> and after the test got that far, two systems got inserted into the path 
> before level3, resulting in the route entering level3 at a different point, 
> 4.69.141.249. What you now have is
> 
> 172.28.0.1 -> 10.16.0.2
>  -> 41.200.16.1
>  -> 172.17.2.25
>  -> 213.140.58.10
>  -> 195.22.195.125
>  -> unknown
>  -> unknown
>  -> 4.69.141.249
>  -> 77.67.66.154
>  -> and so on
> 
> The effect would be to get a result like this.
> 
> Next time you see something like this, suggestion: repeat the traceroute and 
> see what you get.
> 
> 
> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
> 
>> Hey folks,
>> i see a strange traceroute there
>> 
>> Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
>> avec un maximum de 30 sauts :
>> 
>> 1 2 ms 1 ms 1 ms  172.28.0.1
>> 2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
>> 310 ms10 ms13 ms  41.200.16.1
>> 411 ms10 ms11 ms  172.17.2.25
>> 521 ms21 ms21 ms  213.140.58.10
>> 634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
>> [195.22.197.125
>> ]
>> 734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>> 8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>> 974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
>> [4.69.141.249]
>> 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>> 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>> 1381 ms81 ms81 ms  193.231.72.10
>> 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>> 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
>> [193.231.7
>> 2.52]
>> Itinéraire déterminé.
>> C:\Documents and Settings\TAYEB>
>> Seabone, then level3, then Tinet, then level3, then tinet ?
>> if is that a routing stufs that i don't know, please let me know :)
>> i never saw that befaure
>> 
>>   Meftah Tayeb
>> IT Consulting
>> http://www.tmvoip.com/
>> phone: +21321656139
>> Mobile: +213660347746
>> 
>> 
>> __ Information from ESET NOD32 Antivirus, version of virus signature 
>> database 6695 (20111208) __
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
> 
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> 


--Steve Bellovin, https://www.cs.columbia.edu/~smb

Re: Traceroute explanation

2011-12-08 Thread Meftah Tayeb

big thank for that
but, i am testing that for one day :)

- Original Message - 
From: "Fred Baker" 

To: "Meftah Tayeb" 
Cc: 
Sent: Thursday, December 08, 2011 11:23 PM
Subject: Re: Traceroute explanation

This is just a guess, but I'll bet the route changed while you were 
measuring it.

Traceroute sends a request, awaits a response, sends a request, ... Suppose 
that the route was

172.28.0.1 -> 10.16.0.2
  -> 41.200.16.1
  -> 172.17.2.25
  -> 213.140.58.10
  -> 195.22.195.125
  -> 4.69.151.13
  -> 213.200.68.61
  -> somewhere else

and after the test got that far, two systems got inserted into the path 
before level3, resulting in the route entering level3 at a different point, 
4.69.141.249. What you now have is

172.28.0.1 -> 10.16.0.2
  -> 41.200.16.1
  -> 172.17.2.25
  -> 213.140.58.10
  -> 195.22.195.125
  -> unknown
  -> unknown
  -> 4.69.141.249
  -> 77.67.66.154
  -> and so on

The effect would be to get a result like this.

Next time you see something like this, suggestion: repeat the traceroute and 
see what you get.

On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:

Hey folks,
i see a strange traceroute there

Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
avec un maximum de 30 sauts :

 1 2 ms 1 ms 1 ms  172.28.0.1
 2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
 310 ms10 ms13 ms  41.200.16.1
 411 ms10 ms11 ms  172.17.2.25
 521 ms21 ms21 ms  213.140.58.10
 634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
[195.22.197.125

]
 734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net 
[4.69.151.13]
 8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net 
[213.200.68.61]
 974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
[4.69.141.249]

1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
1381 ms81 ms81 ms  193.231.72.10
1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro 
[89.238.225.90]
1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
[193.231.7

2.52]
Itinéraire déterminé.
C:\Documents and Settings\TAYEB>
Seabone, then level3, then Tinet, then level3, then tinet ?
if is that a routing stufs that i don't know, please let me know :)
i never saw that befaure

   Meftah Tayeb
IT Consulting
http://www.tmvoip.com/
phone: +21321656139
Mobile: +213660347746

__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: Traceroute explanation

2011-12-08 Thread Fred Baker

This is just a guess, but I'll bet the route changed while you were measuring 
it.

Traceroute sends a request, awaits a response, sends a request, ... Suppose 
that the route was

172.28.0.1 -> 10.16.0.2
   -> 41.200.16.1
   -> 172.17.2.25
   -> 213.140.58.10
   -> 195.22.195.125
   -> 4.69.151.13
   -> 213.200.68.61
   -> somewhere else

and after the test got that far, two systems got inserted into the path before 
level3, resulting in the route entering level3 at a different point, 
4.69.141.249. What you now have is

172.28.0.1 -> 10.16.0.2
   -> 41.200.16.1
   -> 172.17.2.25
   -> 213.140.58.10
   -> 195.22.195.125
   -> unknown
   -> unknown
   -> 4.69.141.249
   -> 77.67.66.154
   -> and so on

The effect would be to get a result like this.

Next time you see something like this, suggestion: repeat the traceroute and 
see what you get.


On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:

> Hey folks,
> i see a strange traceroute there
> 
> Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
> avec un maximum de 30 sauts :
> 
>  1 2 ms 1 ms 1 ms  172.28.0.1
>  2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
>  310 ms10 ms13 ms  41.200.16.1
>  411 ms10 ms11 ms  172.17.2.25
>  521 ms21 ms21 ms  213.140.58.10
>  634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
> [195.22.197.125
> ]
>  734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>  8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>  974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
> [4.69.141.249]
> 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
> 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
> 1381 ms81 ms81 ms  193.231.72.10
> 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
> 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
> [193.231.7
> 2.52]
> Itinéraire déterminé.
> C:\Documents and Settings\TAYEB>
> Seabone, then level3, then Tinet, then level3, then tinet ?
> if is that a routing stufs that i don't know, please let me know :)
> i never saw that befaure
> 
>Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/ 
> phone: +21321656139
> Mobile: +213660347746
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>

Re: Traceroute explanation

2011-12-08 Thread Meftah Tayeb


yeah,
i'm ok with you for that
but the hell surprise is that i am going to telecom italia that i realy 
don't like anymore, Level3 aguin, then tinet, then level3, then tinet ?

that strange.

- Original Message - 
From: "Sasa Ristic" 

To: 
Sent: Thursday, December 08, 2011 10:58 PM
Subject: Re: Traceroute explanation


Hi,

nothing surprises me from Tinet any more... at one time all my traffic
from Europe was routed through some Hong Kong router of theirs...

but, enough jokes...

this could be the path the packets are traversing through, nothing
wrong with it, as long as everything is working fine... ie. packet
gets delivered to destination, and reply comes back, within reasonable
time frame... not like traveling across the globe...   :)


Regards,

On Wed, Dec 7, 2011 at 20:12, Meftah Tayeb  wrote:

Hey folks,
i see a strange traceroute there

Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
avec un maximum de 30 sauts :

1 2 ms 1 ms 1 ms 172.28.0.1
2 1 ms 1 ms 1 ms localhost [10.16.0.2]
3 10 ms 10 ms 13 ms 41.200.16.1
4 11 ms 10 ms 11 ms 172.17.2.25
5 21 ms 21 ms 21 ms 213.140.58.10
6 34 ms 31 ms 55 ms pos14-0.palermo9.pal.seabone.net [195.22.197.125
]
7 34 ms 33 ms 35 ms ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
8 106 ms 68 ms 67 ms xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
9 74 ms 73 ms 74 ms ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
10 63 ms 63 ms 79 ms euroweb-gw.ip4.tinet.net [77.67.66.154]
11 85 ms 84 ms 84 ms v15-core1.stsisp.ro [193.151.28.1]
12 100 ms 100 ms 102 ms inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
13 81 ms 81 ms 81 ms 193.231.72.10
14 92 ms 92 ms 93 ms ip4-89-238-225-90.euroweb.ro [89.238.225.90]
15 89 ms 89 ms 89 ms webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
2.52]
Itinéraire déterminé.
C:\Documents and Settings\TAYEB>
Seabone, then level3, then Tinet, then level3, then tinet ?
if is that a routing stufs that i don't know, please let me know :)
i never saw that befaure

Meftah Tayeb
IT Consulting
http://www.tmvoip.com/
phone: +21321656139
Mobile: +213660347746


__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





--
ricky



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: Traceroute explanation

2011-12-08 Thread Sasa Ristic

Hi,

nothing surprises me from Tinet any more... at one time all my traffic
from Europe was routed through some Hong Kong router of theirs...

but, enough jokes...

this could be the path the packets are traversing through, nothing
wrong with it, as long as everything is working fine... ie. packet
gets delivered to destination, and reply comes back, within reasonable
time frame... not like traveling across the globe...   :)


Regards,

On Wed, Dec 7, 2011 at 20:12, Meftah Tayeb  wrote:
> Hey folks,
> i see a strange traceroute there
>
> Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
> avec un maximum de 30 sauts :
>
>  1     2 ms     1 ms     1 ms  172.28.0.1
>  2     1 ms     1 ms     1 ms  localhost [10.16.0.2]
>  3    10 ms    10 ms    13 ms  41.200.16.1
>  4    11 ms    10 ms    11 ms  172.17.2.25
>  5    21 ms    21 ms    21 ms  213.140.58.10
>  6    34 ms    31 ms    55 ms  pos14-0.palermo9.pal.seabone.net 
> [195.22.197.125
> ]
>  7    34 ms    33 ms    35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
>  8   106 ms    68 ms    67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>  9    74 ms    73 ms    74 ms  ae-1-12.bar1.budapest1.level3.net 
> [4.69.141.249]
>  10    63 ms    63 ms    79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>  11    85 ms    84 ms    84 ms  v15-core1.stsisp.ro [193.151.28.1]
>  12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>  13    81 ms    81 ms    81 ms  193.231.72.10
>  14    92 ms    92 ms    93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>  15    89 ms    89 ms    89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
> [193.231.7
> 2.52]
> Itinéraire déterminé.
> C:\Documents and Settings\TAYEB>
> Seabone, then level3, then Tinet, then level3, then tinet ?
> if is that a routing stufs that i don't know, please let me know :)
> i never saw that befaure
>
>    Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/
> phone: +21321656139
> Mobile: +213660347746
>
>
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>



-- 
ricky

Traceroute explanation

2011-12-08 Thread Meftah Tayeb

Hey folks,
i see a strange traceroute there

Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
avec un maximum de 30 sauts :

  1 2 ms 1 ms 1 ms  172.28.0.1
  2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
  310 ms10 ms13 ms  41.200.16.1
  411 ms10 ms11 ms  172.17.2.25
  521 ms21 ms21 ms  213.140.58.10
  634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net [195.22.197.125
]
  734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
  8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
  974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net [4.69.141.249]
 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
 1381 ms81 ms81 ms  193.231.72.10
 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa [193.231.7
2.52]
Itinéraire déterminé.
C:\Documents and Settings\TAYEB>
Seabone, then level3, then Tinet, then level3, then tinet ?
if is that a routing stufs that i don't know, please let me know :)
i never saw that befaure

Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6695 (20111208) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

2011-12-08 Thread nanog-bounces

Fyodor wrote:
> switched their Nmap downloads back to our real installer.  At least
> for now.  But that isn't enough--they are still infecting the
> installers for thousands of other packages!  

I am sorry about these problems, it is unacceptable.

Sourceforge, at least a year or 2 ago, did something that was only slightly 
less unacceptable. They had (or still have?) ads that would display when you 
click a donwload link at some site, say 
http://www.clamwin.com/content/view/18/46/

In this example (and clamwin had no part in that) the redirect of the download 
link would show an add for another virus scanner (but in fact it was malware, 
or, so broken it'd behave like malware). I know of actual cases where someone 
accidentally downloaded the software from the add, and messed up their computer.

So much for pointing them to a free virus scanner...

-- 
Earthquake Magnitude: 3.1
Date: Wednesday, December  7, 2011 15:57:44 UTC
Location: northern Alaska
Latitude: 65.9462; Longitude: -148.7381
Depth: 30.90 km

[NANOG-announce] NANOG 54 Hotel Update

2011-12-08 Thread Betty Burke

Dear NANOG Community,

On behalf of the Board of Directors, I am happy to share some wonderful
news regarding hotel accommodations for our NANOG 54 meeting in San Diego.
The hotel has been undergoing renovations and recently completed remodeling
of all its guest rooms and meeting space. The last phase of the hotel
remodel will include the main lobby, which they plan to complete before our
meeting.

The Board has been working closely with the hotel to ensure the remodel
will have no effect on NANOG 54, scheduled for February 5 - 8, 2012. As a
result of our conversations, the hotel has agreed to reduce the individual
guest room rate from $199 +tax/ night to $169 + tax/night.   For
reservations already made, the hotel will make an adjustment to your daily
rate, reflecting the new NANOG 54 rate.

In addition, if you make your reservation by January 4th, 2012, you will be
entered into a drawing to win 10,000 Starwood Preferred Guest points!

For your reference, below please find a copy of the original letter from
the hotel.

We look forward to seeing you all in San Diego!

Sincerely,

Betty Burke,
Executive Director





Greetings from San Diego!


We are looking forward to welcoming you to America’s Finest City for the
NANOG Annual Meeting in February 2012.

Over the last year, The Westin Gaslamp Quarter has completed a refresh of
our guest rooms, meeting space and WestinWORKOUT®, and we are in the final
phase of our lobby renovation.  To celebrate and to help manage your travel
expense, we are happy to offer a discounted conference rate of $169 plus
tax (originally $199!)  For any reservations that have already been made,
we will reduce your confirmed rate for you.

Early Bird Special: If you make your reservation by January 4, 2012, you
will be entered into a drawing to win 10,000 Starwood Preferred Guest
points!


Be well,

Keri Robinson
General Manager
___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Flapping POS Interface on Frame-relay between a Juniper and Cisco

2011-12-08 Thread Righa Shake

The interface finally stabalised.

This after performing segment by segment loop tests at SDH level.
We found errors which were sorted after which the service has been better
the random flaps have since disappeared.

Now dealing with random BGP cease notifications I receive from my upstream.

Thank you all for your assistance in helping solve this.

Regards,
Righa Shake




On Wed, Dec 7, 2011 at 12:17 AM, Scott Morris  wrote:

> The mismatch problem of DCE/DTE should definitely indicate that your
> PVCs aren't up.  But that shouldn't result in the high quantity of CRC
> errors in the interface counters.  That should just result in your LMI
> enquiry count increasing with LMI response sitting at zero.
>
> I have to say I've never tried running frame-relay on a SONET
> interface.  And if you're only using a single PVC there, I'd certainly
> love to know WHY you're doing that!  :)
>
> But setting one side to DCE so that it'll respond to LMI will certainly
> make the frame-relay (L2) portion of things operate properly.  But if
> you have something else occurring causing the CRCs along the way, then
> that's not really going to help at all!
>
> Did anything else coincide with you changing the encapsulation?
>
> Scott
>
>
>
> On 12/6/11 4:05 PM, Scott Weeks wrote:
> > Did Jeff's suggestion work?
> >
> > : interface POS0/0/0
> > : frame-relay intf-type dce
> >
> > If so, please let the list know, so when someone comes
> > across this thread while searching for the fix they can
> > figure it out without having to email the list.  If it
> > didn't help contact me off-line and I will be happy to
> > troubleshoot it with you.
> >
> > scott
> >
> >
> >
> >
> >
> > 
> > From: Righa Shake [righa.sh...@gmail.com]
> > Sent: Saturday, November 19, 2011 11:11 AM
> > To: af...@afnog.org
> > Subject: Flapping POS Interface on Frame-relay between a Juniper and
> Cisco
> >
> > Hi,
> >
> > Am having a problem that is buffling.
> >
> > I recently changed a POS link encapsulation from PPP to Frame-relay.
> > Since that time the POS interface keeps resetting from time to time.
> >
> > On my BGP session am receiving cease notifications from my upstream
> > provider.
> >
> > The setup is such that we have a cisco on one end and a Juniper on the
> > other.
> >
> > interface POS0/0/0
> >  mtu 4474
> >  no ip address
> >  no ip unreachables
> >  encapsulation frame-relay
> >  logging event link-status
> >  crc 32
> >  pos scramble-atm
> >  frame-relay lmi-type ansi
> > end
> >
> > ROUTERshow run int pos0/0/0.101
> > Building configuration...
> >
> >
> > !
> > interface POS0/0/0.101 point-to-point
> > ip address X.X.X.X 255.255.255.252
> > frame-relay interface-dlci 101
> > end
> >
> > ROUTER#show int pos0/0/0
> > POS0/0/0 is up, line protocol is up
> >   Hardware is SPA-2XOC12-POS
> >   MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec,
> >  reliability 255/255, txload 6/255, rxload 38/255
> >   Encapsulation FRAME-RELAY, crc 32, loopback not set
> >   Keepalive set (10 sec)
> >   Scramble enabled
> >   LMI enq sent  81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up
> >   LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
> >   LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE  segmentation
> > inactive
> >   FR SVC disabled, LAPF state down
> >   Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface
> broadcasts
> > 0
> >   Last input 00:00:00, output 00:00:00, output hang never
> >   Last clearing of "show interface" counters 1w2d
> >   Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
> >   Queueing strategy: fifo
> >   Output queue: 0/40 (size/max)
> >   5 minute input rate 94336000 bits/sec, 13151 packets/sec
> >   5 minute output rate 1647 bits/sec, 7049 packets/sec
> >  12211574207 packets input, 10967607038364 bytes, 0 no buffer
> >  Received 0 broadcasts (0 IP multicasts)
> >  6970870 runts, 2179 giants, 0 throttles
> >   0 parity
> >  892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0
> ignored,
> > 3335463 abort
> >  6379191154 packets output, 1614018181446 bytes, 0 underruns
> >  0 output errors, 0 applique, 4 interface resets
> >  0 unknown protocol drops
> >  0 output buffer failures, 0 output buffers swapped out
> >  0 carrier transitions
> >
> >
> > Any assistance on this will be greatly appreciated.
> >
> >
> >
> >
> >
> >
> > --- js...@briworks.com wrote:
> >
> > From: Jeff Saxe 
> >
> > I believe this is the explanation for your flapping: a PPP link is
> intended to go between two routers over, for instance, a private leased
> line, so both of the devices are peers, neither one particularly special.
> Frame-relay, by contrast, was originally designed so that your router was
> an "end user" device and its directly-connected partner device was not your
> other router, which you control, but the frame carrier's frame-relay
> switch. Your router was a DTE device, and their swit

Re: BGP and Firewalls...

2011-12-08 Thread David

I wouldn't do it.  We have 8 x PA-2050s and run into a lot of wierd bugs 
(just doing web filtering)

David

Sent from an email server.

On Dec 7, 2011, at 12:31 PM, "Gregory Croft"  wrote:

> Hi All, 
> 
> 
> 
> Does anyone have any experience with using firewalls as edge devices
> when BGP is concerned? 
> 
> Specifically the Palo Alto series of devices. 
> 
> 
> 
> If so please contact me off list. 
> 
> 
> 
> Thank you. 
> 
> 
> 
> 
> 
> Thank you, 
> 
> Gregory S. Croft 
> 
> 
> 
> 
>

Re: BGP and Firewalls...

2011-12-08 Thread -Hammer-


Roland,
While I understand that the definition has nothing to do with IT 
Security there is no question that many folks use the phrase to 
summarize a layered IT security model.


Edge routers with ACLs to filter white noise go to edge L3/4 firewalls 
to filter their layer go to load balancers to terminate SSL (not really 
security I know) which go to L7 firewalls to inspect HTTP just to get to 
the web server. Then you have the whole layered DMZs for the 
WEBs/APPs/DBs/inside etc. We employ "defense in depth" and everyone is 
familiar with the concept even if they are using the phrase incorrectly. 
And our wonderful federal auditors expect it and call it the same thing.


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 12/07/2011 09:43 PM, Dobbins, Roland wrote:

On Dec 8, 2011, at 1:36 AM, Leo Bicknell wrote:

   

I don't think you're looking at defense in depth in the right way,
 

Actually, it sometimes seems as if nobody in the industry understands what 
'defense in depth' really means, heh.

'Defense in depth' is a military term of art which equates to 'trading space 
for time in order to facilitate attrition of enemy forces'.  It does not have 
any real relevance to infosec/opsec; unfortunately, its original meaning has 
been corrupted and so it is widely (and incorrectly) used in place of the more 
appropriate 'combined arms approach' or 'jointness' or 'mutual support' or 
'layered defense' metaphors.  Hannibal's tactics at Cannae are generally cited 
as the canonical (pardon the pun) example of actual military defense in depth.

;>

---
Roland Dobbins  //

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

2011-12-08 Thread Jeroen van Aart


Fyodor wrote:

switched their Nmap downloads back to our real installer.  At least
for now.  But that isn't enough--they are still infecting the
installers for thousands of other packages!  


I am sorry about these problems, it is unacceptable.

Sourceforge, at least a year or 2 ago, did something that was only
slightly less unacceptable. They had (or still have?) ads that would
display when you click a donwload link at some site, say
http://www.clamwin.com/content/view/18/46/

In this example (and clamwin had no part in that) the redirect of the
download link would show an add for another virus scanner (but in fact
it was malware, or, so broken it'd behave like malware). I know of
actual cases where someone accidentally downloaded the software from the
add, and messed up their computer.

So much for pointing them to a free virus scanner...

--
Earthquake Magnitude: 3.1
Date: Wednesday, December  7, 2011 15:57:44 UTC
Location: northern Alaska
Latitude: 65.9462; Longitude: -148.7381
Depth: 30.90 km

Re: Juniper <-> Cisco IPv6 BGP peering

seeking clueful assistance at speakeasy-now-megapath

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

Re: {Spam?} Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Re: Traceroute explanation

Traceroute explanation

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

[NANOG-announce] NANOG 54 Hotel Update

Re: Flapping POS Interface on Frame-relay between a Juniper and Cisco

Re: BGP and Firewalls...

Re: BGP and Firewalls...

Re: [fyo...@insecure.org: C|Net Download.Com is now bundling Nmap with malware!]

23 matches

Site Navigation

Mail list logo

Footer information