Re: Linux Router distro's with dual stack capability

[Steve Bertrand]

Jack Carrozzo wrote:
> Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See
> the freebsd-isp list.

Raises hand. I do, on these boxes:

http://www.mikrotikrouter.net/

Steve

Ticket/Asset Managment system

[Brandon Grant]

I am currently evaluating my options for an open source trouble ticket
management system that is based on assets (the trouble ticket is opened
on a particular server, network element, etc.).  Also, I am hoping to
find a tool that can tie in with SNMP software so I can have tickets
auto-generated for certain types of SNMP traps or polling failures. 

 

Any recommendations? 

 

So far, the best two that I have been able to find are:

 

1.OTRS.org

2.   GLIP-project.org

 

Any insight would be appreciated.

 

Brandon

 

 

Re: Ticket/Asset Managment system

[Simon Morvan]

On 12/02/2010 16:56, Brandon Grant wrote:
> I am currently evaluating my options for an open source trouble ticket
> management system that is based on assets (the trouble ticket is opened
> on a particular server, network element, etc.).  Also, I am hoping to
> find a tool that can tie in with SNMP software so I can have tickets
> auto-generated for certain types of SNMP traps or polling failures. 
>
>  
>
> Any recommendations? 
>
>  
>
> So far, the best two that I have been able to find are:
>
>  
>
> 1.OTRS.org
>
> 2.   GLIP-project.org
>
>  
>
> Any insight would be appreciated.
>
>
>   
Request-Tracker (RT) with RT-IR (Incident Response) ?

-- 
Simon.

Re: Ticket/Asset Managment system

[charles]

Have you looked into any cmdb systems? 

There are some good open source ones. Opencmdb.org I think. 
Sent via BlackBerry from T-Mobile

Re: Ticket/Asset Managment system

[Phil Regnauld]

Brandon Grant (brandon) writes:
> I am currently evaluating my options for an open source trouble ticket
> management system that is based on assets (the trouble ticket is opened
> on a particular server, network element, etc.).

Hi Brandon,

Maybe RT (already mentioned) could do the trick -- it's a matter of
choosing how you will set up the system, i.e.: number of queues, custom
fields, etc...

Since it's ticket centric, it really doesn't matter how many servers
or assets you have.

> Also, I am hoping to
> find a tool that can tie in with SNMP software so I can have tickets
> auto-generated for certain types of SNMP traps or polling failures. 

That's not really dependent on the ticket system.  I've done this
with Trac and RT: it's more a matter of whether the NMS platform
allows triggers (arbitrary actions) to be tied to events, and also
in which cases.  It's trivial with Nagios to open tickets on down
or unreachable events.  You could even instrument the script to
update the ticket (never close a ticket automatically!) every time
a new event related to this equipment took place.

> 1.OTRS.org
> 
> 2.   GLIP-project.org

You mean http://www.glpi-project.org/ -- I've heard it should be quite
complicated to setup, but have no first hand experience myself.

Cheers,
Phil

Re: Ticket/Asset Managment system

[Jens Link]

"Brandon Grant"  writes:

> Also, I am hoping to find a tool that can tie in with SNMP software so
> I can have tickets auto-generated for certain types of SNMP traps or
> polling failures.

Do it the other way round: Use something like Nagios, Zabbix or Icinga
for monitoring and if a fault is detected let the monitoring system 
send a message to your ticket system. 

Jens
-- 
-
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264 |
| http://www.quux.de | http://blog.quux.de   | jabber: jensl...@guug.de |
-

Re: Ticket/Asset Managment system

[Ray Sanders]

A previous employer did something similar with Solarwind's ipMonitor and 
Kayako eSupport.
Neither are open source, but at the time, the cost for each piece of 
software was reasonable.


Jens Link wrote:

"Brandon Grant"  writes:

  

Also, I am hoping to find a tool that can tie in with SNMP software so
I can have tickets auto-generated for certain types of SNMP traps or
polling failures.



Do it the other way round: Use something like Nagios, Zabbix or Icinga
for monitoring and if a fault is detected let the monitoring system 
send a message to your ticket system. 


Jens
  




No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.733 / Virus Database: 271.1.1/2683 - Release Date: 02/12/10 00:35:00


  



--
-"Prediction is very difficult, especially about the future."
-Niels Bohr
--
Ray Sanders
Linux Administrator
Village Voice Media
Office: 602-744-6547
Cell: 602-300-4344

RE: Ticket/Asset Managment system

[Jeffrey Negro]

I'd second this.  RT is a really nice ticketing system with great email
capabilities.  Use nagios to send an email to an address you have RT
configured to receive, and you can even pipe that email address directly
into a specific ticket queue within RT.

-Original Message-
From: Jens Link [mailto:li...@quux.de] 
Sent: Friday, February 12, 2010 12:31 PM
To: nanog@nanog.org
Subject: Re: Ticket/Asset Managment system

"Brandon Grant"  writes:

> Also, I am hoping to find a tool that can tie in with SNMP software so
> I can have tickets auto-generated for certain types of SNMP traps or
> polling failures.

Do it the other way round: Use something like Nagios, Zabbix or Icinga
for monitoring and if a fault is detected let the monitoring system 
send a message to your ticket system. 

Jens
-- 

-
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264
|
| http://www.quux.de | http://blog.quux.de   | jabber: jensl...@guug.de
|

-

Re: Ready to get your federal computer license?

[Florian Weimer]

* Scott Morris:

> Florian Weimer wrote:
>> * Scott Morris:
>>
>>   
>>> I'm trying really hard to find my "paranoia hat", and just to relieve
>>> some boredom I read the entire bill to try to figure out where this was
>>> all coming from
>>>
>>> "(2) may declare a cybersecurity emergency and order the limitation or
>>> shutdown of Internet traffic to and from any compromised Federal
>>> Government or United States critical infrastructure information system
>>> or network;"
>>> 
>>
>> Wouldn't this mean you're allowed to set emergency ACLs only if a
>> cybersecurity emergency has been declared by the President?

> I must have missed the phrasing that says "nobody else can make an
> independent decision regarding any security measure above and beyond the
> minimum standards"...
>
> I'll go back and look for that.

The thing your looking for is called "exclusio unius". 8-)

Re: Ready to get your federal computer license?

[Jorge Amodio]

On Fri, Feb 12, 2010 at 7:11 AM, Florian Weimer  wrote:
> * Scott Morris:
>
>> Florian Weimer wrote:
>>> * Scott Morris:
>>>
>>>
 I'm trying really hard to find my "paranoia hat", and just to relieve
 some boredom I read the entire bill to try to figure out where this was
 all coming from

 "(2) may declare a cybersecurity emergency and order the limitation or
 shutdown of Internet traffic to and from any compromised Federal
 Government or United States critical infrastructure information system
 or network;"

>>>
>>> Wouldn't this mean you're allowed to set emergency ACLs only if a
>>> cybersecurity emergency has been declared by the President?
>
>> I must have missed the phrasing that says "nobody else can make an
>> independent decision regarding any security measure above and beyond the
>> minimum standards"...
>>
>> I'll go back and look for that.
>
> The thing your looking for is called "exclusio unius". 8-)

Now the President will not only carry "The football" now he will also
start carrying "The switch".

Cheers

Re: Ready to get your federal computer license?

[Joly MacFie]

As secretary of the Internet Society's NY Chapter I'd like to back up
Chris's appeal. We are in a position of familiarity and consultation
with local government but definitely needful of the kind of technical
expertise so abundant in Nanog. We'd very much welcome fresh blood.

Steven - I believe you are in our neighborhood?

joly

http://isoc-ny.org



On Mon, Aug 31, 2009 at 10:57 AM, Chris Grundemann
 wrote:
> On Sun, Aug 30, 2009 at 20:28, Steven M. Bellovin wrote:

>> "A journey of a thousand miles begins with a single step."
>>
>> I don't know that a NagOn is the best way or the only way to make
>> progress.  I do know that the most likely source of that kind of
>> funding is (many of) our employers, who may not have technical
>> excellence on the top of their lists.  But I'm even more certain that
>> if technical people never speak up, their message will never be heard,
>> except perhaps by accident.
>>
>>                --Steve Bellovin, http://www.cs.columbia.edu/~smb
>>
>>
>
> I believe that this is exactly the kind of thing that the US ISOC
> Chapters should be (and are to varying degrees) involved in --
> providing legitimate technical information and expert analysis of
> local, state and federal policies which impact the Internet, to those
> making the policies.  The global ISOC already does this for ICANN and
> other international organizations, it seems fitting that the chapters
> do more of this here inside the USA.
>
> I encourage everyone with even a fleeting interest in tech-policy to
> seek out their local ISOC chapter
> (http://www.isoc.org/isoc/chapters/list.php?region=worldwide&status=A)
> and let them know that you care.  I can tell you as the founding chair
> of the Colorado chapter that my largest hurdle today is getting active
> members to participate - I have funding, etc, just no help...  (I
> invite everyone to contact me directly with suggestions and ideas in
> this vein - I have some vehicles in place to start making this happen
> quickly with a bit of help)
>
> 
> ~Chris
>
> --
> Chris Grundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
>
>



-- 
---
Joly MacFie  917 442 8665 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
http://pinstand.com - http://punkcast.com
---

Video: 10G switches

[Anshuman Kanwar]

I am capacity planning for 8-10K streams of video (150-300Kbps) through a Nexus 
7000 or an EX 8200 pair. The same infrastructure will be carrying quite a few 
audio minutes as well. Does someone have experience with either of these 
platforms with this scale of audio/video ?

Looking for some practical advice about buffers/specific line cards/things to 
avoid etc. not for the usual teal/blue debate.

Thanks,
-ansh

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 13 Feb, 2010

Report Website: http://thyme.apnic.net
Detailed Analysis:  http://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  311463
Prefixes after maximum aggregation:  144143
Deaggregation factor:  2.16
Unique aggregates announced to Internet: 152471
Total ASes present in the Internet Routing Table: 33274
Prefixes per ASN:  9.36
Origin-only ASes present in the Internet Routing Table:   28899
Origin ASes announcing only one prefix:   14066
Transit ASes present in the Internet Routing Table:4375
Transit-only ASes present in the Internet Routing Table:102
Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  23
Max AS path prepend of ASN ( 9503)   21
Prefixes from unregistered ASNs in the Routing Table:   848
Unregistered ASNs in the Routing Table: 138
Number of 32-bit ASNs allocated by the RIRs:427
Prefixes from 32-bit ASNs in the Routing Table: 400
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:289
Number of addresses announced to Internet:   2184202944
Equivalent to 130 /8s, 48 /16s and 74 /24s
Percentage of available address space announced:   58.9
Percentage of allocated address space announced:   66.1
Percentage of available address space allocated:   89.1
Percentage of address space in use by end-sites:   81.1
Total number of prefixes smaller than registry allocations:  149910

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:75345
Total APNIC prefixes after maximum aggregation:   25911
APNIC Deaggregation factor:2.91
Prefixes being announced from the APNIC address blocks:   72008
Unique aggregates announced from the APNIC address blocks:31613
APNIC Region origin ASes present in the Internet Routing Table:3950
APNIC Prefixes per ASN:   18.23
APNIC Region origin ASes announcing only one prefix:   1076
APNIC Region transit ASes present in the Internet Routing Table:619
Average APNIC Region AS path length visible:3.6
Max APNIC Region AS path length visible: 23
Number of APNIC addresses announced to Internet:  491620128
Equivalent to 29 /8s, 77 /16s and 135 /24s
Percentage of available APNIC address space announced: 77.1

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
   55296-56319, 131072-132095
APNIC Address Blocks 1/8,  27/8,  43/8,  58/8,  59/8,  60/8,  61/8,
   110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8,
   117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8,
   124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8,
   183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8,
   220/8, 221/8, 222/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:129695
Total ARIN prefixes after maximum aggregation:67717
ARIN Deaggregation factor: 1.92
Prefixes being announced from the ARIN address blocks:   103832
Unique aggregates announced from the ARIN address blocks: 39504
ARIN Region origin ASes present in the Internet Routing Table:13492
ARIN Prefixes per ASN: 7.70
ARIN Region origin ASes announcing only one prefix:5209
ARIN Region transit ASes present in the Internet Routing Table:1324
Average ARIN Region AS path length visible: 3.4
Max ARIN Region AS path length visible:  22
Number of ARIN addresses announced to Internet:   738753312
Equivalent to 44 /8s, 8 /16s and 123 /24s
Percentage of available ARIN address space announced:  64.8

AR

Re: Google to offer fiber to end users

[Joel Jaeggli]

James Hess wrote:
> For now.. with 1gigabit residential connections,  BCP 38  OUGHT to be
> Google's answer.  If Google handles that properly,  they  _should_
> make it mandatory that all traffic  from residential customers be
> filtered, in all cases,   in order to  only forward   packets with
> their  legitimately assigned  or registry-issued publicly verifiable
> IP prefix(es)  in the  IP source field. Must be mandatory even for
>  'resellers',  otherwise there's no point.

The  amount of DOS that is spoofed today is by all reports significantly
lower as percentage of overall DOS than it was in say 2000.

BCP 38 is all fine and dandy, and you should implement it, but it's not
going to stop the botnets.


> And Google should provide _reasonable_ response to investigate  manual
> abuse reports to well-publicized points of contact which go directly
> to a well-staffed dedicated abuse team, with authority and a clear and
> expeditious resolution process,  as a bare minimum,  and in addition
> to  any and all automatic measures.
> 
> 
> P.S.  reasonable abuse response is not defined as a  4-day delayed
> answer to a  'help, no contact addresses will answer me' post on nanog
> (long after automated processes finally kicked in).. Reasonable
> response to a  continuous  1gigabit  flood  or  100 kilopacket  flood
> should be  less than 12 hours.
> 
> If  they think things through carefully   (rather than copy+paste
> Google groups e-mail abuse management),it'll  probably be alright
> 
> --
> -J
> 

CYMRU Bogon Peering

[Thomas Magill]

In efforts to further protect us against threats I am considering
establishing Bogon peers to enable me to filter unallocated address
space.  I am just wondering if this is a worthwhile step to take and if
anyone has ran into any issues or points of concern that I may want to
take into account.  Thanks in advance for any input.

 

Thomas Magill
Network Engineer

Office: (858) 909-3777

Cell: (858) 869-9685
mailto:tmag...@providecommerce.com  


provide-commerce 
4840 Eastgate Mall

San Diego, CA  92121

 

ProFlowers   | redENVELOPE
  | Cherry Moon Farms
  | Shari's Berries
 

 

Re: CYMRU Bogon Peering

[Bill Blackford]

I've been doing this for some time on two routers injecting the null routes
into my AS. No issues. Beats the heck out of trying to use ACLs. However,
the prefix count is rapidly diminishing as more blocks are being released by
the various RIRs hence being pulled from the bogon list.

-b

On Fri, Feb 12, 2010 at 12:51 PM, Thomas Magill  wrote:

> In efforts to further protect us against threats I am considering
> establishing Bogon peers to enable me to filter unallocated address
> space.  I am just wondering if this is a worthwhile step to take and if
> anyone has ran into any issues or points of concern that I may want to
> take into account.  Thanks in advance for any input.
>
>
>
> Thomas Magill
> Network Engineer
>
> Office: (858) 909-3777
>
> Cell: (858) 869-9685
> mailto:tmag...@providecommerce.com 
>
>
> provide-commerce
> 4840 Eastgate Mall
>
> San Diego, CA  92121
>
>
>
> ProFlowers   | redENVELOPE
>   | Cherry Moon Farms
>   | Shari's Berries
> 
>
>
>
>


-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.

Re: CYMRU Bogon Peering

[Steve Bertrand]

Thomas Magill wrote:
> In efforts to further protect us against threats I am considering
> establishing Bogon peers to enable me to filter unallocated address
> space.  I am just wondering if this is a worthwhile step to take and if
> anyone has ran into any issues or points of concern that I may want to
> take into account.  Thanks in advance for any input.

I've used the service for a couple of years, and I find it works
wonderfully. Newly distributed IANA blocks are removed promptly, so no
need to worry about that.

I peer with Cymru on my RTBH trigger boxes, which then redistribute the
list to all edge gear which blackholes it (dest and source) thanks to uRPF.

No manual config or rule manipulation.

Steve

Re: CYMRU Bogon Peering

[Jack Carrozzo]

I agree - quick setup and no issues. A++ Would Peer Again

-Jack Carrozzo

On Fri, Feb 12, 2010 at 4:10 PM, Steve Bertrand  wrote:
> Thomas Magill wrote:
>> In efforts to further protect us against threats I am considering
>> establishing Bogon peers to enable me to filter unallocated address
>> space.  I am just wondering if this is a worthwhile step to take and if
>> anyone has ran into any issues or points of concern that I may want to
>> take into account.  Thanks in advance for any input.
>
> I've used the service for a couple of years, and I find it works
> wonderfully. Newly distributed IANA blocks are removed promptly, so no
> need to worry about that.
>
> I peer with Cymru on my RTBH trigger boxes, which then redistribute the
> list to all edge gear which blackholes it (dest and source) thanks to uRPF.
>
> No manual config or rule manipulation.
>
> Steve
>
>
>

RE: CYMRU Bogon Peering

[Thomas Magill]

Thanks to everyone who replied.  That settles it!  I'm going to do it.

-Original Message-
From: Jack Carrozzo [mailto:j...@crepinc.com] 
Sent: Friday, February 12, 2010 1:14 PM
To: Steve Bertrand
Cc: Thomas Magill; nanog@nanog.org
Subject: Re: CYMRU Bogon Peering

I agree - quick setup and no issues. A++ Would Peer Again

-Jack Carrozzo

On Fri, Feb 12, 2010 at 4:10 PM, Steve Bertrand  wrote:
> Thomas Magill wrote:
>> In efforts to further protect us against threats I am considering
>> establishing Bogon peers to enable me to filter unallocated address
>> space.  I am just wondering if this is a worthwhile step to take and if
>> anyone has ran into any issues or points of concern that I may want to
>> take into account.  Thanks in advance for any input.
>
> I've used the service for a couple of years, and I find it works
> wonderfully. Newly distributed IANA blocks are removed promptly, so no
> need to worry about that.
>
> I peer with Cymru on my RTBH trigger boxes, which then redistribute the
> list to all edge gear which blackholes it (dest and source) thanks to uRPF.
>
> No manual config or rule manipulation.
>
> Steve
>
>
>

Re: CYMRU Bogon Peering

[Mr. James W. Laferriere]

Hello All ,

On Fri, 12 Feb 2010, Bill Blackford wrote:

On Fri, Feb 12, 2010 at 12:51 PM, Thomas Magill 
wrote:



In efforts to further protect us against threats I am considering
establishing Bogon peers to enable me to filter unallocated address
space.  I am just wondering if this is a worthwhile step to take and if
anyone has ran into any issues or points of concern that I may want to
take into account.  Thanks in advance for any input.



Thomas Magill
Network Engineer
Office: (858) 909-3777
Cell: (858) 869-9685
mailto:tmag...@providecommerce.com 
provide-commerce
4840 Eastgate Mall
San Diego, CA  92121


I've been doing this for some time on two routers injecting the null routes
into my AS. No issues. Beats the heck out of trying to use ACLs. However,
the prefix count is rapidly diminishing as more blocks are being released by
the various RIRs hence being pulled from the bogon list.
-b
	I've a question for the CYMRU Team ,  My reasoning for posting here is 
to get a much wide knowledge base .


	Does or Is the 'Bogon Peering' Product(?) ,  Only at the IANA->RIR 
allocations level ?   F.E.:  IANA has allocated 1.0.0.0/8 to RIPE .


Or

	Does the product also include the actual remaining non-allocated space 
at the RIR->EU level ? (**)   F.E: RIPE has allocated 1.0.1.0/24 to anubusstupidity, inc.


Tia ,  JimL

ps:	I am Very well aware that (so far) there is no standard format for 
returned requests from *whois daemons .

--
+--+
| James   W.   Laferriere | SystemTechniques | Give me VMS |
| Network&System Engineer | 3237 Holden Road |  Give me Linux  |
| bab...@baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+--+

Re: CYMRU Bogon Peering

[Jack Carrozzo]

Current list of prefixes Cymru considers bogon:

http://www.cymru.com/Documents/bogon-bn-nonagg.txt

Does that answer the question?

-Jack Carrozzo

On Fri, Feb 12, 2010 at 4:21 PM, Mr. James W. Laferriere
 wrote:
>        Hello All ,
>
> On Fri, 12 Feb 2010, Bill Blackford wrote:
>>
>> On Fri, Feb 12, 2010 at 12:51 PM, Thomas Magill
>> >>
>>> wrote:
>>
>>> In efforts to further protect us against threats I am considering
>>> establishing Bogon peers to enable me to filter unallocated address
>>> space.  I am just wondering if this is a worthwhile step to take and if
>>> anyone has ran into any issues or points of concern that I may want to
>>> take into account.  Thanks in advance for any input.
>>>
>>>
>>>
>>> Thomas Magill
>>> Network Engineer
>>> Office: (858) 909-3777
>>> Cell: (858) 869-9685
>>> mailto:tmag...@providecommerce.com 
>>> provide-commerce
>>> 4840 Eastgate Mall
>>> San Diego, CA  92121
>>
>> I've been doing this for some time on two routers injecting the null
>> routes
>> into my AS. No issues. Beats the heck out of trying to use ACLs. However,
>> the prefix count is rapidly diminishing as more blocks are being released
>> by
>> the various RIRs hence being pulled from the bogon list.
>> -b
>
>        I've a question for the CYMRU Team ,  My reasoning for posting here
> is to get a much wide knowledge base .
>
>        Does or Is the 'Bogon Peering' Product(?) ,  Only at the IANA->RIR
> allocations level ?   F.E.:  IANA has allocated 1.0.0.0/8 to RIPE .
>
>        Or
>
>        Does the product also include the actual remaining non-allocated
> space at the RIR->EU level ? (**)   F.E: RIPE has allocated 1.0.1.0/24 to
> anubusstupidity, inc.
>
>                Tia ,  JimL
>
> ps:     I am Very well aware that (so far) there is no standard format for
> returned requests from *whois daemons .
> --
> +--+
> | James   W.   Laferriere | System    Techniques | Give me VMS     |
> | Network&System Engineer | 3237     Holden Road |  Give me Linux  |
> | bab...@baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
> +--+
>
>

Re: CYMRU Bogon Peering

[Tim Wilde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/12/2010 4:21 PM, Mr. James W. Laferriere wrote:
> I've a question for the CYMRU Team ,  My reasoning for posting here
> is to get a much wide knowledge base .
> 
> Does or Is the 'Bogon Peering' Product(?) ,  Only at the IANA->RIR
> allocations level ?   F.E.:  IANA has allocated 1.0.0.0/8 to RIPE .
> 
> Or
> 
> Does the product also include the actual remaining non-allocated
> space at the RIR->EU level ? (**)   F.E: RIPE has allocated 1.0.1.0/24
> to anubusstupidity, inc.

Jim & All,

The current bogon reference projects we have available only include the
first of your examples - netblocks which have not been allocated by IANA
to an RIR.  However, we are currently in a beta testing phase of a
similar feed which also includes netblocks that have not yet been
allocated or assigned by the RIRs.  We will also be offering the same
type of bogon feed for IPv6, something we've been asked about quite a
bit recently!

We will be releasing more information about this service once it is
ready for a wider audience.  You can keep an eye on a number of places
for this type of announcement:

 * Our web site, http://www.team-cymru.org/
 * Our announcements mailing list, subscribe via
cymru-announce-subscr...@cymru.com
 * Our Twitter feed, http://twitter.com/teamcymru
 * Our weekly YouTube show, http://www.youtube.com/teamcymru

Thanks to all for your interest and feedback - we're glad to hear that
you are finding the bogon references useful in your networks!

Best Regards,
Tim Wilde

- -- 
Tim Wilde, Senior Software Engineer, Team Cymru, Inc.
twi...@cymru.com | +1-630-230-5433 | http://www.team-cymru.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt1zH4ACgkQluRbRini9tjQEwCcDwVNldtYR+tcmaUGoF9KaPi8
90IAn2tQA57bnLQQPS7A8qFZIh+11Z9F
=Q+yv
-END PGP SIGNATURE-

Re: Linux Router distro's with dual stack capability

[Randy Bush]

> FreeBSD has supported polling for a long time (V6?) and interrupt
> coalescing since some release of V7. (Latest release is V8.)

exactly.  and they kick ass

randy

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 04-Feb-10 -to- 11-Feb-10 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS3300   188306 14.4%3552.9 -- BT-INFONET-EUROPE 
BT-Infonet-Europe
 2 - AS18170   84302  6.4%4958.9 -- CHANGWON-AS-KR Changwon 
National University
 3 - AS24084   61350  4.7%3608.8 -- 
 4 - AS943047691  3.6%1644.5 -- STPI-NOIDA Software Technology 
Parks of India,Block-IV
 5 - AS26118   24585  1.9% 409.8 -- Ministerio Publico 
Federal-Proc. Geral daRepublica
 6 - AS31055   19524  1.5%9762.0 -- CONSULTIX-AS Consultix GmbH
 7 - AS730315725  1.2%  23.8 -- Telecom Argentina S.A.
 8 - AS38028   14295  1.1%4765.0 -- MCKINSEY-AP MCKINSEY-AP
 9 - AS18167   13474  1.0%3368.5 -- HCLCOMNET-AS-IN HCL Comnet 
Systems & Services Ltd
10 - AS580012932  1.0%  49.0 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
11 - AS3   11618  0.9% 213.0 -- AZRT-AS Azertelekom
12 - AS45408   11558  0.9%5779.0 -- 
13 - AS14420   11077  0.8%  28.5 -- CORPORACION NACIONAL DE 
TELECOMUNICACIONES CNT S.A.
14 - AS553610018  0.8% 135.4 -- Internet-Egypt
15 - AS9829 9139  0.7%  15.4 -- BSNL-NIB National Internet 
Backbone
16 - AS1916 8768  0.7% 143.7 -- Rede Nacional de Ensino e 
Pesquisa
17 - AS179748465  0.7%  17.0 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
18 - AS288788463  0.7%1057.9 -- SIGNET-AS Signet B.V.
19 - AS369928455  0.7%  28.1 -- ETISALAT-MISR
20 - AS165698352  0.6%8352.0 -- ASN-CITY-OF-CALGARY - City of 
Calgary


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS31055   19524  1.5%9762.0 -- CONSULTIX-AS Consultix GmbH
 2 - AS165698352  0.6%8352.0 -- ASN-CITY-OF-CALGARY - City of 
Calgary
 3 - AS45408   11558  0.9%5779.0 -- 
 4 - AS260255293  0.4%5293.0 -- COC - City of Calgary
 5 - AS18170   84302  6.4%4958.9 -- CHANGWON-AS-KR Changwon 
National University
 6 - AS38028   14295  1.1%4765.0 -- MCKINSEY-AP MCKINSEY-AP
 7 - AS24084   61350  4.7%3608.8 -- 
 8 - AS3300   188306 14.4%3552.9 -- BT-INFONET-EUROPE 
BT-Infonet-Europe
 9 - AS18167   13474  1.0%3368.5 -- HCLCOMNET-AS-IN HCL Comnet 
Systems & Services Ltd
10 - AS5691 2349  0.2%2349.0 -- MITRE-AS-5 - The MITRE 
Corporation
11 - AS943047691  3.6%1644.5 -- STPI-NOIDA Software Technology 
Parks of India,Block-IV
12 - AS182213501  0.3%1167.0 -- TSN-AP TSN Communications
13 - AS288788463  0.7%1057.9 -- SIGNET-AS Signet B.V.
14 - AS27245 972  0.1% 972.0 -- HEIDRICK-CHICAGO - HEIDRICK
15 - AS29421 784  0.1% 784.0 -- DCI-AS Digital Communications 
Incorporated Ltd.
16 - AS33405 603  0.1% 603.0 -- CLIFFORD-PROJECTS - Clifford 
Projects, Inc.
17 - AS354001071  0.1% 535.5 -- MFIST Interregoinal 
Organization Network Technologies
18 - AS27027 436  0.0% 436.0 -- ANBELL ASN-ANBELL
19 - AS18439 428  0.0% 428.0 -- VISTATSI - VISTA Technology 
Services Inc.
20 - AS104452548  0.2% 424.7 -- HTG - Huntleigh Telcom


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 62.168.199.0/24   19522  1.4%   AS31055 -- CONSULTIX-AS Consultix GmbH
 2 - 208.98.230.0/248352  0.6%   AS16569 -- ASN-CITY-OF-CALGARY - City of 
Calgary
 3 - 62.193.80.0/24 7544  0.5%   AS5536  -- Internet-Egypt
 4 - 203.28.157.0/246100  0.4%   AS4802  -- ASN-IINET iiNet Limited
 5 - 193.177.160.0/23   5867  0.4%   AS28878 -- SIGNET-AS Signet B.V.
 6 - 114.70.96.0/24 5779  0.4%   AS45408 -- 
 7 - 114.70.97.0/24 5779  0.4%   AS45408 -- 
 8 - 208.98.231.0/245293  0.4%   AS26025 -- COC - City of Calgary
 9 - 203.187.128.0/20   5248  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
10 - 203.187.131.0/24   5248  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
11 - 203.187.155.0/24   5248  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
12 - 203.187.154.0/24   5246  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
13 - 203.158.95.0/245246  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
14 - 203.187.151.0/24   5246  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
15 - 203.158.94.0/245246  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
16 - 61.14.12.0/24  5245  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
17 - 61.14.2.0/23   5244  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe
18 - 61.14.1.0/24   5244  0.4%   AS3300  -- BT-INFONET-EUROPE 
BT-Infonet-Europe

The Cidr Report

[cidr-report]

This report has been generated at Fri Feb 12 21:11:25 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
05-02-10313323  192821
06-02-10313551  192770
07-02-10313475  192927
08-02-10313644  193088
09-02-10313515  193528
10-02-10313485  193739
11-02-10313242  194090
12-02-10313721  194102


AS Summary
 33558  Number of ASes in routing system
 14272  Number of ASes announcing only one prefix
  4376  Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
  93118976  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 12Feb10 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 313967   194156   11981138.2%   All ASes

AS6389  4122  321 380192.2%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  4376 1831 254558.2%   TWTC - tw telecom holdings,
   inc.
AS4766  1858  485 137373.9%   KIXS-AS-KR Korea Telecom
AS4755  1453  408 104571.9%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS22773 1113   71 104293.6%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS1785  1843  855  98853.6%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS17488 1266  316  95075.0%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS8151  1590  684  90657.0%   Uninet S.A. de C.V.
AS18101 1091  201  89081.6%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS10620  988  163  82583.5%   TV Cable S.A.
AS19262 1063  244  81977.0%   VZGNI-TRANSIT - Verizon
   Internet Services Inc.
AS8452  1004  325  67967.6%   TEDATA TEDATA
AS6478  1104  434  67060.7%   ATT-INTERNET3 - AT&T WorldNet
   Services
AS4808   850  237  61372.1%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS4804   678   72  60689.4%   MPX-AS Microplex PTY LTD
AS18566 1059  478  58154.9%   COVAD - Covad Communications
   Co.
AS7303   676  107  56984.2%   Telecom Argentina S.A.
AS4134  1019  460  55954.9%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS7018  1558 1005  55335.5%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS24560  844  293  55165.3%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS3356  1206  663  54345.0%   LEVEL3 Level 3 Communications
AS17908  766  228  53870.2%   TCISL Tata Communications
AS7545   967  465  50251.9%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS4780   630  141  48977.6%   SEEDNET Digital United Inc.
AS5668   801  320  48160.0%   AS-5668 - CenturyTel Internet
   Holdings, Inc.
AS17676  563   82  48185.4%   GIGAINFRA Softbank BB Corp.
AS9443   555   79  47685.8%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS35805  571  113  45880.2%   UTG-AS United Telecom AS
AS22047  528   74  45486.0%   VTR BANDA ANCHA S.A.
AS9299   665  216  44967.5%   IPG-AS-AP Philippine Long
   Distance Telephone Company

Total  36807113712543669.1%   Top 30 total


Possible Bogus Routes

2.0.0.0/16   AS12654 RIPE-NCC-RI

Re: CYMRU Bogon Peering

[Seth Mattinen]

On 2/12/2010 13:47, Tim Wilde wrote:
> On 2/12/2010 4:21 PM, Mr. James W. Laferriere wrote:
>> I've a question for the CYMRU Team ,  My reasoning for posting here
>> is to get a much wide knowledge base .
> 
>> Does or Is the 'Bogon Peering' Product(?) ,  Only at the IANA->RIR
>> allocations level ?   F.E.:  IANA has allocated 1.0.0.0/8 to RIPE .
> 
>> Or
> 
>> Does the product also include the actual remaining non-allocated
>> space at the RIR->EU level ? (**)   F.E: RIPE has allocated 1.0.1.0/24
>> to anubusstupidity, inc.
> 
> Jim & All,
> 
> The current bogon reference projects we have available only include the
> first of your examples - netblocks which have not been allocated by IANA
> to an RIR.  However, we are currently in a beta testing phase of a
> similar feed which also includes netblocks that have not yet been
> allocated or assigned by the RIRs.  We will also be offering the same
> type of bogon feed for IPv6, something we've been asked about quite a
> bit recently!
> 

While I have your attention, I've noticed there's been a bit of
instability lately with the BGP sessions (in fact one of mine right now
is down). With 30 routes it's not a big deal to have frequent churn, but
if you're going to expand that to a larger feed then it could become a
problem.

~Seth

dns interceptors

[Randy Bush]

i just lost ten minutes debugging what i thought was a server problem
which turned out to be a dns trapper on the wireless in the changi sats
lounge.  this is not the first time i have been caught by this.

what are other roaming folk doing about this?

randy

Re: Ready to get your federal computer license?

[Jorge Amodio]

>> "A journey of a thousand miles begins with a single step."

Absolutely true, but many folks from the technical side are sick tired
trying to talk to people that "hear" but do not "listen" and dealing
with others that have nothing else to contribute than their selfish
interests or the interests of the corporation backing them.

Unfortunately many organizations including ISOC lost their appeal and
mission, and in many cases is just a platform to self promote
particular individuals.

Have a great weekend and happy chocolate in heart shape day.

Cheers
Jorge

Re: dns interceptors

[Jared Mauch]

On Feb 12, 2010, at 5:15 PM, Randy Bush wrote:

> i just lost ten minutes debugging what i thought was a server problem
> which turned out to be a dns trapper on the wireless in the changi sats
> lounge.  this is not the first time i have been caught by this.
> 
> what are other roaming folk doing about this?
> 
> randy

I typically VPN out of broken networks whenever possible.

Operate a VPN/PPTP/IPSEC/squid-proxy/ssh on tcp/80/443 to work around the 
issues.

- Jared

Re: dns interceptors

[Jim Richardson]

On Fri, Feb 12, 2010 at 2:15 PM, Randy Bush  wrote:
> i just lost ten minutes debugging what i thought was a server problem
> which turned out to be a dns trapper on the wireless in the changi sats
> lounge.  this is not the first time i have been caught by this.
>
> what are other roaming folk doing about this?
>
> randy
>
>

ssh tunnels to IP address


-- 
http://neon-buddha.net

BIRD vs Quagga

[Fried, Jason (US - Hattiesburg)]

I was wondering what kind of experience the nanog userbase has had with these 
two packages.
Thanks

--
Jason Fried



This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message.

Any disclosure, copying, or distribution of this message, or the taking of any 
action based on it, is strictly prohibited. [v.E.1]

Re: Google to offer fiber to end users

[Jared Mauch]

On Feb 12, 2010, at 3:17 PM, Joel Jaeggli wrote:

> BCP 38 is all fine and dandy, and you should implement it, but it's not
> going to stop the botnets.

Yup.  Many have these devices they call "Routers" they buy locally that 
translate spoofed addresses to some well-known outside "public" IP.

(They may well still emit "spoofed garbage" but typically for another reason).

- Jared

Re: BIRD vs Quagga

[Steve Bertrand]

Fried, Jason (US - Hattiesburg) wrote:
> I was wondering what kind of experience the nanog userbase has had with these 
> two packages.

Quagga++.

I've never tried the other.

I use Quagga for OSPF, OSPFv3 and BGP (IPv4 and IPv6). With a bit of
trickery, it fits in nicely with my RANCID setup, and what I like best
is that it (mostly) follows Cisco's command convention.

There are also very active developer and user mailing lists.

For the most part, I wouldn't know if I was writing a config for a Cisco
or for a Quagga box.

fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I
haven't tried those either...zebra/Quagga just stuck.

Steve

Re: CYMRU Bogon Peering

[Nick Hilliard]

On 12/02/2010 21:21, Mr. James W. Laferriere wrote:
> ps:I am Very well aware that (so far) there is no standard format
> for returned requests from *whois daemons .

eh, what are you talking about?

If you want to prefix-filter your bgp feeds using RPSL objects, you can
pull the "fltr-bogons" object from RADB or the RIPE IRRDB (which both
return objects in a standard format).

Nick

Re: CYMRU Bogon Peering

[Steve Bertrand]

Seth Mattinen wrote:
> On 2/12/2010 13:47, Tim Wilde wrote:
>> On 2/12/2010 4:21 PM, Mr. James W. Laferriere wrote:
>>> I've a question for the CYMRU Team ,  My reasoning for posting here
>>> is to get a much wide knowledge base .
>>> Does or Is the 'Bogon Peering' Product(?) ,  Only at the IANA->RIR
>>> allocations level ?   F.E.:  IANA has allocated 1.0.0.0/8 to RIPE .
>>> Or
>>> Does the product also include the actual remaining non-allocated
>>> space at the RIR->EU level ? (**)   F.E: RIPE has allocated 1.0.1.0/24
>>> to anubusstupidity, inc.
>> Jim & All,
>>
>> The current bogon reference projects we have available only include the
>> first of your examples - netblocks which have not been allocated by IANA
>> to an RIR.  However, we are currently in a beta testing phase of a
>> similar feed which also includes netblocks that have not yet been
>> allocated or assigned by the RIRs.  We will also be offering the same
>> type of bogon feed for IPv6, something we've been asked about quite a
>> bit recently!
>>
> 
> While I have your attention, I've noticed there's been a bit of
> instability lately with the BGP sessions (in fact one of mine right now
> is down). With 30 routes it's not a big deal to have frequent churn, but
> if you're going to expand that to a larger feed then it could become a
> problem.

What time frame do you determine to be instability? The following is
from a box that has ~25 neighbours. Since the box was reloaded (6w3d
ago), I've had the same uptime with the Team Cymru neighbours as I do
with internal gear. I can't say that I've experienced any instability at
all. It is not uncommon for me to have noticed uptimes well beyond 30w.

trig-2#sh ip bgp sum

NeighborVAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
State/PfxRcd
68.22.187.244 65333   81750   65849   6700 6w3d   30
216.165.129.196 4 65333   81748   65849   6700 6w3d   30

trig-2#sh ip bgp nei 68.22.187.24

  Prefix activity:      
Prefixes Current:   0 30 (Consumes 1560 bytes)
Prefixes Total: 0 36
Implicit Withdraw:  0  0
Explicit Withdraw:  0  6

...snip...

  Connections established 1; dropped 0
  Last reset never

Steve

Re: dns interceptors

[Steve Bertrand]

Jared Mauch wrote:
> On Feb 12, 2010, at 5:15 PM, Randy Bush wrote:
> 
>> i just lost ten minutes debugging what i thought was a server problem
>> which turned out to be a dns trapper on the wireless in the changi sats
>> lounge.  this is not the first time i have been caught by this.
>>
>> what are other roaming folk doing about this?
>>
>> randy
> 
> I typically VPN out of broken networks whenever possible.
> 
> Operate a VPN/PPTP/IPSEC/squid-proxy/ssh on tcp/80/443 to work around the 
> issues.

Yep...

On Windows laptop, a wrapper .bat sets up Putty (SSH) to configure a
tunnel to a remote server, and for FBSD, an sh script with the SSH
command line within.

Depending on the situation, the tunnel may handle all core protocols,
even 587 when it has been hijacked/blocked.

Steve

Re: BIRD vs Quagga

[Thomas Mangin]

http://www.uknof.org.uk/uknof15/

Has quite a few talk about Quagga/Bird as they are used as route servers in 
Europe.
For a route server use, BGP under very high number of peers, it seems bird now 
behave better than anything else.
so for "normal" use, it would seems that whatever you pick will work but quagga 
is surely the most deployed.

Thomas

On 12 Feb 2010, at 22:51, Steve Bertrand wrote:

> Fried, Jason (US - Hattiesburg) wrote:
>> I was wondering what kind of experience the nanog userbase has had with 
>> these two packages.
> 
> Quagga++.
> 
> I've never tried the other.
> 
> I use Quagga for OSPF, OSPFv3 and BGP (IPv4 and IPv6). With a bit of
> trickery, it fits in nicely with my RANCID setup, and what I like best
> is that it (mostly) follows Cisco's command convention.
> 
> There are also very active developer and user mailing lists.
> 
> For the most part, I wouldn't know if I was writing a config for a Cisco
> or for a Quagga box.
> 
> fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I
> haven't tried those either...zebra/Quagga just stuck.
> 
> Steve
> 
> 

Re: BIRD vs Quagga

[Kevin Oberman]

There will be a presentation comparing BIRD with Quagga at NANOG week
after next in Austin. II believe it will be a part of the Route Servers
Track on Monday afternoon.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Re: dns interceptors

[Steve Bertrand]

Jim Richardson wrote:
> On Fri, Feb 12, 2010 at 2:15 PM, Randy Bush  wrote:
>> i just lost ten minutes debugging what i thought was a server problem
>> which turned out to be a dns trapper on the wireless in the changi sats
>> lounge.  this is not the first time i have been caught by this.
>>
>> what are other roaming folk doing about this?
>>
>> randy
>>
>>
> 
> ssh tunnels to IP address

I sent this directly to Randy, but perhaps there are others who are
interested in doing this as well. For the archives (and my own
documentation):

My DNS server doesn't listen on localhost (a prereq), so I'll use submit
port instead:

# on the roaming laptop (hereinafter 'client')

# -f == run in background
# st...@host is the submit server
# -L means map this port "587:" to "remote-host:port"
# -N means do not execute remote command

client# ssh -f st...@208.70.104.210 -L 587:208.70.104.210:587 -N

...now I tell my local resolver (or in this case, my MUA) to use
localhost instead of the normal remote host. Note that I generally use
the standard ports on my localhost for this mapping. Doing so will not
work for things like HTTP etc, as we are focused squarely on accessing
resources located on our own equipment...

...SSH tunnelling even works over v6. The colon-separated address isn't
handled well within the port-mapping portion of the command, so we'll
use names instead:

pearl# dig  smtp.ibctech.ca
smtp.ibctech.ca.3598IN  2607:f118::b6

...

client# ssh -6 -f st...@smtp.ibctech.ca -L 587:smtp.ibctech.ca:587 -N

server# tcpdump -n -i lo0 port 587

client# telnet ::1 587
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 smtp.ibctech.ca ESMTP

server#
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
19:01:20.529444 IP6 2607:f118::b6.59842 > 2607:f118::b6.587: S
4152936854:4152936854(0) win 65535 
19:01:20.529497 IP6 2607:f118::b6.587 > 2607:f118::b6.59842: S
3425118408:3425118408(0) ack 4152936855 win 65535 
19:01:20.529532 IP6 2607:f118::b6.59842 > 2607:f118::b6.587: . ack 1 win
8211 
19:01:20.535727 IP6 2607:f118::b6.587 > 2607:f118::b6.59842: P 1:28(27)
ack 1 win 8211 
19:01:20.635335 IP6 2607:f118::b6.59842 > 2607:f118::b6.587: . ack 28
win 8211 

...I love easy workarounds. I got sick and tired of fscking around a
long time ago with troubleshooting blocked/hijacked ports, so I thought
I'd bypass the problem by hijacking and re-routing the ports myself.
Port tunnelling like this is my default whenever I'm not at home. Even
on Windows its easy...all my apps are portable.

Steve

Re: dns interceptors

[Bill Thompson]

On Fri, 12 Feb 2010 17:32:33 -0500
Jared Mauch  wrote:

> 
> On Feb 12, 2010, at 5:15 PM, Randy Bush wrote:
> 
> > i just lost ten minutes debugging what i thought was a server
> > problem which turned out to be a dns trapper on the wireless in the
> > changi sats lounge.  this is not the first time i have been caught
> > by this.
> > 
> > what are other roaming folk doing about this?
> > 
> > randy
> 
> I typically VPN out of broken networks whenever possible.
> 
> Operate a VPN/PPTP/IPSEC/squid-proxy/ssh on tcp/80/443 to work around
> the issues.
> 
> - Jared
> 

Yep, this is what I do as well. It's a little disappointing that you
have to tunnel into a trusted network in order to prevent shenanigans
like that, but it seems to be the way things are.

-- 
Bill Thompson
bi...@mahagonny.com


signature.asc
Description: PGP signature

Re: BIRD vs Quagga

[Nathan Ward]

On 13/02/2010, at 11:51 AM, Steve Bertrand wrote:

> fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I
> haven't tried those either...zebra/Quagga just stuck.

OpenBGPd would be great for a public route server at an IX.

It's not so great for use in a network unless you run it on OpenBSD - FreeBSD 
has no metric attribute in it's routing tables, so next-hop IGP metric cannot 
be compared as the two daemons do not communicate directly at all.
If you're on anything other than OpenBSD, I recommend Quagga. I can't comment 
on BIRD as I have no experience with it yet.

XORP is also interesting, it's a more JunOS like interface. It's also some 
quite heavy C++, so running it on the tiny Soekris boxes that I had meant it 
wouldn't work for me. If you can spare the CPU and RAM then give XORP a go.

--
Nathan Ward

Re: CYMRU Bogon Peering

[Seth Mattinen]

On 2/12/2010 15:03, Steve Bertrand wrote:
> 
> What time frame do you determine to be instability? The following is
> from a box that has ~25 neighbours. Since the box was reloaded (6w3d
> ago), I've had the same uptime with the Team Cymru neighbours as I do
> with internal gear. I can't say that I've experienced any instability at
> all. It is not uncommon for me to have noticed uptimes well beyond 30w.
> 


Mine are not so good:

NeighborVAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
State/PfxRcd
38.229.0.5  4 65333  115856  115859 1641181400 01:33:51   30

68.22.187.24465333   26968   29671 1631129300 2w4d
 30

I see you have 68.22.187.24 in your list too, but my uptime is less. Are
you using increased hold times?

~Seth

Re: CYMRU Bogon Peering

[Nathan Ward]

On 13/02/2010, at 2:03 PM, Seth Mattinen wrote:

> On 2/12/2010 15:03, Steve Bertrand wrote:
>> 
>> What time frame do you determine to be instability? The following is
>> from a box that has ~25 neighbours. Since the box was reloaded (6w3d
>> ago), I've had the same uptime with the Team Cymru neighbours as I do
>> with internal gear. I can't say that I've experienced any instability at
>> all. It is not uncommon for me to have noticed uptimes well beyond 30w.
>> 
> 
> 
> Mine are not so good:
> 
> NeighborVAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
> State/PfxRcd
> 38.229.0.5  4 65333  115856  115859 1641181400 01:33:51   30
> 
> 68.22.187.24465333   26968   29671 1631129300 2w4d
> 30
> 
> I see you have 68.22.187.24 in your list too, but my uptime is less. Are
> you using increased hold times?

Nevermind BGP timers, do you normally do well holding TCP connections open for 
weeks on end across the Internet?

--
Nathan Ward

Re: CYMRU Bogon Peering

[Steve Bertrand]

Seth Mattinen wrote:
> On 2/12/2010 15:03, Steve Bertrand wrote:
>> What time frame do you determine to be instability? The following is
>> from a box that has ~25 neighbours. Since the box was reloaded (6w3d
>> ago), I've had the same uptime with the Team Cymru neighbours as I do
>> with internal gear. I can't say that I've experienced any instability at
>> all. It is not uncommon for me to have noticed uptimes well beyond 30w.
>>
> 
> 
> Mine are not so good:
> 
> NeighborVAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
> State/PfxRcd
> 38.229.0.5  4 65333  115856  115859 1641181400 01:33:51   30
> 
> 68.22.187.24465333   26968   29671 1631129300 2w4d
>  30
> 
> I see you have 68.22.187.24 in your list too, but my uptime is less. Are
> you using increased hold times?

No... I haven't changed anything. Here is my exact config from said box
(for that host):

router bgp 14270

!...snip...

 neighbor cymru-bogon peer-group
 neighbor cymru-bogon description Cymru BOGON peer group
 neighbor cymru-bogon ebgp-multihop 255
 neighbor cymru-bogon update-source Loopback99

!...snip...

 neighbor 68.22.187.24 remote-as 65333
 neighbor 68.22.187.24 peer-group cymru-bogon
 neighbor 68.22.187.24 description Cymru route-server #2

!...snip...

 address-family ipv4
  redistribute static route-map RTBH-OUT
  neighbor cymru-bogon prefix-list CYMRU-OUT out
  neighbor cymru-bogon route-map CYMRU-MAP-IN in
  neighbor cymru-bogon maximum-prefix 200

!...snip...

  neighbor 68.22.187.24 activate

!...snip...

ip community-list expanded BOGON permit 65333:888
ip community-list expanded BLACKHOLE permit 14270:600
ip as-path access-list 10 permit ^65333*

!...snip...

ip prefix-list CYMRU-OUT seq 5 deny 0.0.0.0/0 le 32

!...snip...

route-map CYMRU-MAP-IN permit 10
 description Null route BOGONS learnt from Cymru
 match community BOGON
 set community 14270:888 no-export additive
 set ip next-hop 192.0.2.2

!...snip...

route-map RTBH-OUT permit 10
 match tag 600
 set local-preference 500
 set origin igp
 set community 14270:600 no-export

!__END__

Do you have any other peers on the same int that are dropping as well?

Steve

Re: CYMRU Bogon Peering

[Rob Thomas]

Hi, Seth.

> While I have your attention, I've noticed there's been a bit of
> instability lately with the BGP sessions (in fact one of mine right now
> is down). With 30 routes it's not a big deal to have frequent churn, but
> if you're going to expand that to a larger feed then it could become a
> problem.

Alas, the joy of multihop BGP.  :)  This is why we recommend at least
two peering sessions to two disparate route-servers.  We'll take the
same approach with the expanded IPv4 and IPv6 offerings.

If you could send me a list of outages with dates and times, I'll look
into those ASAP.  I can see if other sessions were dropping at the same
time, upstream outages, etc.

Feel free to hit up n...@cymru.com with outage reports as they occur as well.

Thanks!
Rob.
-- 
Rob Thomas
Team Cymru
https://www.team-cymru.org/
ASSERT(coffee != empty);

Re: CYMRU Bogon Peering

[Seth Mattinen]

On 2/12/2010 17:51, Rob Thomas wrote:
> Hi, Seth.
> 
>> While I have your attention, I've noticed there's been a bit of
>> instability lately with the BGP sessions (in fact one of mine right now
>> is down). With 30 routes it's not a big deal to have frequent churn, but
>> if you're going to expand that to a larger feed then it could become a
>> problem.
> 
> Alas, the joy of multihop BGP.  :)  This is why we recommend at least
> two peering sessions to two disparate route-servers.  We'll take the
> same approach with the expanded IPv4 and IPv6 offerings.

Yep, I have two. It's always one or the other, but never both
simultaneously.


> If you could send me a list of outages with dates and times, I'll look
> into those ASAP.  I can see if other sessions were dropping at the same
> time, upstream outages, etc.
> 
> Feel free to hit up n...@cymru.com with outage reports as they occur as well.
> 

Thanks, I'll keep an eye on it.

~Seth

Re: dns interceptors [SEC=UNCLASSIFIED]

[Wilkinson, Alex]

0n Sat, Feb 13, 2010 at 06:15:02AM +0800, Randy Bush wrote: 

>i just lost ten minutes debugging what i thought was a server problem
>which turned out to be a dns trapper on the wireless in the changi sats
>lounge.  this is not the first time i have been caught by this.

Whats a "dns trapper" ?

   -Alex

IMPORTANT: This email remains the property of the Australian Defence 
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 
1914.  If you have received this email in error, you are requested to contact 
the sender and delete the email.

Re: dns interceptors [SEC=UNCLASSIFIED]

[John Levine]

>Whats a "dns trapper" ?

A "transparent" proxy that intercepts DNS requests and provides edited
results intended to improve your customer experience, typically
defined as returning A records for web servers full of advertisements
when you were expecting something else.

The unfortunate fact is that if you're using random networks, you'll
get increasingly random results, and there's no substitude for a tunnel
back to a known network.

R's,
John
 

Re: dns interceptors [SEC=UNCLASSIFIED]

[Brandon Galbraith]

Transparent dns rewriter inline on the network

On 2/12/10, Wilkinson, Alex  wrote:
>
> 0n Sat, Feb 13, 2010 at 06:15:02AM +0800, Randy Bush wrote:
>
> >i just lost ten minutes debugging what i thought was a server problem
> >which turned out to be a dns trapper on the wireless in the changi sats
> >lounge.  this is not the first time i have been caught by this.
>
> Whats a "dns trapper" ?
>
>-Alex
>
> IMPORTANT: This email remains the property of the Australian Defence
> Organisation and is subject to the jurisdiction of section 70 of the CRIMES
> ACT 1914.  If you have received this email in error, you are requested to
> contact the sender and delete the email.
>
>
>


-- 
Brandon Galbraith
Mobile: 630.400.6992
FNAL: 630.840.2141