Re: Please help our simple bgp

[Matthew Reath]

> Hello
>
> Our router is running simple bgp. "one BGP router, two upstreams (each
> 100M
> from ISP A and ISP B)
> We are getting full feeds tables from them
>
> We discover the routes is going to ISP A only even the bandwidth 100M is
> full
>
> Can we set the weight to change to ISP B to use ISP B as preference
> routes?
>
> Can the following configuration work?
> What suggest to this weight no. too?
>
>  neighbor 1.2.3.4 description ISP B
>  neighbor 1.2.3.4 remote-as 111
>  neighbor 1.2.3.4 weight 2000
>
> If this works, how is ISP B upstream connection is down?
>
> Can it still be failover to ISP A automatically?
>
> If it won't work, Do you have any suggestion?
>
> Thank you for your help
>

Ann,

I've done this for a few customers that have requested it. Some engineers
complain that advertising /24 routes dilutes the Internet routing tables,
which is true in some regards.  However, this does work in many situations
to "balance" things out.

Check out my blog post that walks through this procedure:
http://mattreath.com/2012/01/29/bgp-load-balancing/

-Matt


--
Matt Reath
CCIE #27316 (SP)
m...@mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath

Re: Question about prefix list

[Matthew Reath]

> Ann,
> the commas not withstanding, the le/ge operands as applicable to
> prefix-lists simply mean "less-than or equal-to" or greater-than or
> "equal-to" wrt netmasks in CIDR speak.
>
> In you prefix-list below, the le operand means -
> allow following ranges:
>
> /22,/23,/24 deny all else
> for the /21
> it means allow /21 thru /24
>
> Anything without an operand means an exact-match(permit/deny)
>
> Homework for you:
>
> What do the following do:
>
> 1) ip prefix-list foo deny 0.0.0.0/0 le32
> 2) ip prefix-list foo permit 0.0.0/0 le 32
>
> Understand the above and you will understand how operands work in
> prefix-lists.
> ./Randy
>
>
> --- On Wed, 2/1/12, Ann Kwok  wrote:
>
>> From: Ann Kwok 
>> Subject: Question about prefix list
>> To: nanog@nanog.org
>> Date: Wednesday, February 1, 2012, 6:32 AM
>> Hi
>>
>> I read this prefix list.
>>
>> Can I know why there is "le 24" after network block in /22
>> and /21
>>
>> Why don't have "le 24" after /24?
>>
>> I also saw another prefix list before. They use "le 32"
>> instead of  "le 24"
>>
>> What are their different?
>>
>> ip prefix-list prefix-filter-as100 seq 10 permit
>> 202,168.136.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 20 permit
>> 202,22.92.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 30 permit
>> 202,21.148.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 40 permit
>> 203,178.88.0/21 le 24
>> ip prefix-list prefix-filter-as100 seq 50 permit
>> 178.88.74.0/24
>>
>> Thank you so much
>>
>
>

Here is how I look at prefix lists …

Lets say I have the following:
ip prefix-list EXAMPLE permit 202.21.148.0/22 le 24

What this essentially means is match any prefixes that match the first 22
bits of 202.21.148.0 with a prefix length less than or equal to /24.

The third octet (148) is 10010100 in binary, the /22 would be at
100101|00. So we would match anything that has the same bits set before
the divider or the /22 mark.

Matching prefixes would be:
202.21.148.0/22
202.21.148.0/23
202.21.150.0/23
202.21.148.0/24
202.21.149.0/24
202.21.150.0/24
202.21.151.0/24

Hope that makes sense.

--
Matt Reath
CCIE #27316 (SP)
m...@mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath

Re: bufferbloat videos are up.

[Leo Bicknell]

On Feb 3, 2012, at 10:09 PM, Mikael Abrahamsson wrote:

> So basically I agree with your problem statement, however I think it would be 
> benficial if your proposed solution was a bit more specific, or at least 
> pointed more in that direction. To propose a solution that sounds more like 
> "limit buffers to 100ms or less and everything will be fine" would indeed 
> remove some of the problem, but it would hurt performance for some 
> applications.

The key to the solution is better Adaptive Queue Management, or AQM.  As long 
as we have to decide on fixed queue sizes for all traffic, we're forced to 
cater to the most common traffic type.

It would be nice to put queues of different RTT into different queues.  Today 
that is basically impossible.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

Re: bufferbloat videos are up.

[Mikael Abrahamsson]

On Fri, 3 Feb 2012, Jim Gettys wrote:


2. The longer version of the video


Good visualisation. Just a little nitpicking, 802.11 is 54 megabit, not 
megahertz. It should also be pointed out that 802.11 is half duplex, which 
might affect things.


Also, you might want to point out in your material that large buffers are 
there to handle bursts on TCP sessions over high RTT. Your suggestion to 
improve interactive performance hurts high speed TCP high RTT sessions. 
This is probably what most people want to do, but it would be good to 
point it out. Doing a promotion for ECN support in equipment would also be 
good, because introduing WRED with high drop probability a low buffer fill 
will really hurt performance for TCP transfers. ECN will help to avoid 
restransmissions, which just wastes bw.


Where does your 100ms buffer size recommendation come from? The classical 
one is 2xRTT, with a lot of platforms developed around 2000 sized at 600ms 
of buffering (because 300 ms RTT seems like a decent value to choose for 
"max RTT" I guess). At megabit speeds I'd say to achieve your goal having 
100ms FIFO buffering is too high anyway, so to handle your problem you 
need "fairqueue" to look at flows and put persistent buffer filling TCP 
sessions in "the background". This would also mean TCP would be able to 
use full bw without hurting interactivity.


Also, for some operating systems (Linux is the one I know about), there is 
a tendency to have high buffers not only in the IP stack, but also high 
FIFO buffers towards the hardware, in the device driver. I engaged the 
linux-usb mailing list about this, and I did see some talk that indicated 
that people understood the problem.


So basically I agree with your problem statement, however I think it would 
be benficial if your proposed solution was a bit more specific, or at 
least pointed more in that direction. To propose a solution that sounds 
more like "limit buffers to 100ms or less and everything will be fine" 
would indeed remove some of the problem, but it would hurt performance for 
some applications.


The problem you're describing has been know for 25 years, unfortunately 
not by the right people in the business, especially the ones making high 
volume low cost home equipment.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: not excactly on-topic Server Cabinet question

[Doug McIntyre]

On Wed, Feb 01, 2012 at 11:05:09PM -0600, Erik Amundson wrote:
> I apologize for this being off-topic in the NANOG list, but I'm hoping some 
> of you have experience with the particulars of what I'm looking for...
> 
> I am looking for a server cabinet which has an electric latching mechanism on 
> it.  I want to use my existing security system and proximity card reader, but 
> have a cabinet door that would open when the card reader is read.
> 
> Does anyone sell anything like this?

Chatsworth has a solution..

http://www.chatsworth.com/Products/Environmental-Monitoring-and-Security/Electronic-Locking-Systems/

AT&T / prodigy.net mail admin

[Robert Glover]

Hello,

Can an AT&T mail admin contact me off-list please?  I have attempted to 
get a resolution for an issue through the normal channels and have not 
gotten anywhere.


Sincerely,
Bobby Glover
Director of Information Services
SVI Incorporated

Re: IPv6 dual stacking and route tables

[Owen DeLong]

On Feb 3, 2012, at 12:10 PM, -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers and 
> carriers with IBGP) multi-site business. Starting off with a lab of course. 
> Circuits and hardware are a few months away. I'm doing the initial designs 
> and having some delivery questions with the carrier(s). One interesting 
> question came up. There was a thread I found (and have since lost) regarding 
> what routes to accept. Currently, in IPv4, we accept a default route only 
> from both carriers at both sites. Works fine. Optimal? No. Significantly 
> negative impact? No. In IPv6, I have heard some folks say that in a 
> multi-homed environment it is better to get the full IPv6 table fed into both 
> of your edge routers. Ok. Fine. Then, The thread I was referring to said that 
> it is also advisable to have the entire IPv4 table fed in parallel. Ok. I 
> understand we are talking about completely separate protocols. So it's not a 
> layer 3 issue. The reasoning was that DNS could potentially introduce some 
> latency.
> 
> "If you have a specific route to a  record but a less specific route to 
> an A record the potential is for the trip to take longer."
> 
> That was the premise of the thread. I swear I googled it for 20 minutes to 
> link before giving up. Anyway, can anyone who's been thru this provide any 
> opinions on why or why not it is important to accept the full IPv6 table AND 
> the full IPv4 table? I have the hardware to handle it I'm just not sure long 
> term what the reasoning would be for or against. Again, I'm an end customer. 
> Not a carrier. So my concern is (A) my Internet facing applications and (B) 
> my users who eventually will surf IPv6.
> 
> Any guidance would be appreciated. Thanks.
> 
> 
> 
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 

On a purely theoretical level, mores specific routes are always better than 
default.

So, on a purely theoretical level:

IDEAL:  Full routes, both protocols
Advantage:  Most information available, theoretically best decisions 
possible.
Disadvantage:   Router cost rivals national debt of third-world country.

Second best:Full routes IPv6, default or partial routes IPv4
Advantage:  Lots of information available, theoretically best IPv6 
decisions.
Disadvantage:  IPv6 might outperform IPv4 (not really a problem in most 
cases)
Bigger disadvantage: Some IPv4 destinations might get blackholed from 
time to time.

Third choice:   Default both protocols
Advantage:  At least you're still dual-stacked.
Disadvantage: All the disadvantages applied to IPv4 above now apply to 
IPv6, too.

Worst choice:   Don't implement IPv6
Advantage:  Absolutely none.
Disadvantage: You can reach progressively less and less of the internet 
over time.

However, the real answer is more complex than that. Sometimes the route that 
looks the best in BGP might not actually be the best and so in some cases with 
full tables you might send to the provider with the less effective path even 
though default would have had you going via the more effective path. These 
circumstances are rare, however, but, BGP has lots of knobs and depending on 
how well you and your upstreams set those knobs, your experience can be 
radically better or worse as a result.

If your trip to the A destination via default takes longer than your trip to 
the  destination via specifics, I'm not seeing a problem. Clients that have 
IPv6 capability will get a better user experience and clients that don't have 
IPv6 will get the same experience they got with default-based IPv4 prior to you 
implementing IPv6.

Owen

Re: This network is too good...

[Matthew Petach]

On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom  wrote:
>
> Hi all,
>
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> whatever...
>
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")
>
> I'm all-ears like Ross Perot.
>
> Thanks,
>
> -r

Definite +1 for dummynet on freebsd; I've used in the lab at layer 2 in
bridge mode, and layer 3 both, for doing testing.  latency introduction
is good down to a few ms, but isn't accurate below that--but for most
of what we do, in terms of simulating latency and loss/jitter, it works
like a charm.

Matt

The Cidr Report

[cidr-report]

This report has been generated at Fri Feb  3 21:12:45 2012 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
27-01-12396272  229808
28-01-12395687  230060
29-01-12396508  229971
30-01-12396324  229998
31-01-12396621  229745
01-02-12396817  230146
02-02-12397186  229608
03-02-12397625  230080


AS Summary
 40099  Number of ASes in routing system
 16816  Number of ASes announcing only one prefix
  3445  Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
  109882880  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').

 --- 03Feb12 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 398212   230080   16813242.2%   All ASes

AS6389  3445  204 324194.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS7029  3260 1427 183356.2%   WINDSTREAM - Windstream
   Communications Inc
AS18566 2093  413 168080.3%   COVAD - Covad Communications
   Co.
AS4766  2478 1005 147359.4%   KIXS-AS-KR Korea Telecom
AS22773 1499  118 138192.1%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS4755  1528  197 133187.1%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS2118  1391   76 131594.5%   RELCOM-AS OOO "NPO Relcom"
AS4323  1610  386 122476.0%   TWTC - tw telecom holdings,
   inc.
AS28573 1624  407 121774.9%   NET Servicos de Comunicao S.A.
AS1785  1868  789 107957.8%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS7552  1408  363 104574.2%   VIETEL-AS-AP Vietel
   Corporation
AS19262 1386  401  98571.1%   VZGNI-TRANSIT - Verizon Online
   LLC
AS10620 1735  766  96955.9%   Telmex Colombia S.A.
AS8402  1653  726  92756.1%   CORBINA-AS OJSC "Vimpelcom"
AS7303  1260  366  89471.0%   Telecom Argentina S.A.
AS26615  885   33  85296.3%   Tim Celular S.A.
AS8151  1337  550  78758.9%   Uninet S.A. de C.V.
AS18101  935  156  77983.3%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS4808  1102  344  75868.8%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS24560 1010  299  71170.4%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS30036 1437  753  68447.6%   MEDIACOM-ENTERPRISE-BUSINESS -
   Mediacom Communications Corp
AS9498   878  206  67276.5%   BBIL-AP BHARTI Airtel Ltd.
AS9394   878  210  66876.1%   CRNET CHINA RAILWAY
   Internet(CRNET)
AS7545  1642  998  64439.2%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS3356  1098  457  64158.4%   LEVEL3 Level 3 Communications
AS17676  687   74  61389.2%   GIGAINFRA Softbank BB Corp.
AS17974 1724 1121  60335.0%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS11172  698  113  58583.8%   Alestra, S. de R.L. de C.V.
AS15557 1096  511  58553.4%   LDCOMNET Societe Francaise du
   Radiotelephone S.A
AS4804   660   95  56585.6%   MPX-AS Microplex PTY LTD

Total  44305135643074169.4%   Top 30 total


Possible Bogus Routes

10.86.64.32/30   A

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 26-Jan-12 -to- 02-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS840253901  3.1%  29.0 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS28683   39445  2.3% 646.6 -- BENINTELECOM
 3 - AS580033859  1.9% 117.2 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 4 - AS12479   25806  1.5% 154.5 -- UNI2-AS France Telecom Espana SA
 5 - AS982925640  1.5%  36.9 -- BSNL-NIB National Internet 
Backbone
 6 - AS32528   23059  1.3%7686.3 -- ABBOTT Abbot Labs
 7 - AS23154   20656  1.2%5164.0 -- SANMINA-SCI Sanmina-SCI 
Corporation
 8 - AS20632   20258  1.2% 519.4 -- PETERSTAR-AS PeterStar
 9 - AS702918611  1.1%   7.2 -- WINDSTREAM - Windstream 
Communications Inc
10 - AS671318375  1.1%  37.7 -- IAM-AS
11 - AS24560   18180  1.0%  46.0 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
12 - AS31148   16044  0.9%  24.7 -- FREENET-AS FreeNet ISP
13 - AS606612493  0.7%6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
14 - AS958311691  0.7%  11.9 -- SIFY-AS-IN Sify Limited
15 - AS17974   11635  0.7%   8.6 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
16 - AS597611626  0.7% 118.6 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
17 - AS453811580  0.7%  22.7 -- ERX-CERNET-BKB China Education 
and Research Network Center
18 - AS650311445  0.7%   7.0 -- Axtel, S.A.B. de C.V.
19 - AS37004   11269  0.7% 433.4 -- SUBURBAN-AS
20 - AS43348   10512  0.6%  79.6 -- TATARINOVA-AS PE Tatarinova 
Alla Ivanovna


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS291269346  0.5%9346.0 -- DATIQ-AS Datiq B.V.
 2 - AS32528   23059  1.3%7686.3 -- ABBOTT Abbot Labs
 3 - AS606612493  0.7%6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
 4 - AS23154   20656  1.2%5164.0 -- SANMINA-SCI Sanmina-SCI 
Corporation
 5 - AS102093894  0.2%3894.0 -- SYNOPSYS-AS-JP-AP Japan HUB and 
Data Center
 6 - AS5868 1677  0.1%1677.0 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 7 - AS533621001  0.1%1001.0 -- MIXIT-AS - Mixit, Inc.
 8 - AS16045 830  0.1% 830.0 -- SPEKTAR-AD Spektar AD
 9 - AS27295 670  0.0% 670.0 -- GENICA - Genica Corporation
10 - AS36980 660  0.0% 660.0 -- JOHNHOLT-ASN
11 - AS28683   39445  2.3% 646.6 -- BENINTELECOM
12 - AS532221770  0.1% 590.0 -- 
13 - AS19226 565  0.0% 565.0 -- AURA-SOUTH - A.U.R.A
14 - AS174083247  0.2% 541.2 -- ABOVE-AS-AP AboveNet 
Communications Taiwan
15 - AS28123 527  0.0% 527.0 -- 
16 - AS528611575  0.1% 525.0 -- 
17 - AS20632   20258  1.2% 519.4 -- PETERSTAR-AS PeterStar
18 - AS5863  473  0.0% 473.0 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
19 - AS49047 471  0.0% 471.0 -- PCSI-ASN Pentacomp Systemy 
Informatyczne S.A.
20 - AS27689 465  0.0% 465.0 -- Laboratorio Nacional de 
Informática Avanzada AC


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 148.164.14.0/24   20619  1.1%   AS23154 -- SANMINA-SCI Sanmina-SCI 
Corporation
 2 - 84.204.132.0/24   20117  1.1%   AS20632 -- PETERSTAR-AS PeterStar
 3 - 130.36.34.0/2411529  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/2411529  0.6%   AS32528 -- ABBOTT Abbot Labs
 5 - 122.161.0.0/1610190  0.6%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 6 - 217.170.24.0/219346  0.5%   AS29126 -- DATIQ-AS Datiq B.V.
 7 - 62.36.252.0/22 8037  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 202.92.235.0/246528  0.3%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 9 - 150.225.0.0/16 6247  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
10 - 204.29.239.0/246246  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
11 - 62.36.249.0/24 6087  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
12 - 62.36.241.0/24 5537  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
13 - 194.63.9.0/24  5387  0.3%   AS1273  -- CW Cable and Wireless Worldwide 
plc
14 - 62.36.210.0/24 5289  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
15 - 190.67.172.0/225051  0.3%   AS3816  -- COLOMBIA TELECOMUNICACIONES 
S.A. ESP
16 - 111.125.126.0/24   4975  0.3%   AS17639 -- COMCLARK-AS ComClark Network & 
Technology Corp.
17 - 205.73.118.

Re: IPv6 dual stacking and route tables

[Ryan Rawdon]

On Feb 3, 2012, at 3:25 PM, Philip Dorr wrote:

> You should accept the full v6 table, because some IPs may not,
> currently, be reachable via one of the carriers.

Definitely agreed here, and this is why we take full v6 tables.  Especially 
since one of our upstreams does not peer with at least one other large network; 
if we took just a default from them, we would likely be sending them traffic 
which they in turn do not have a route for whereas the other upstream of ours 
does.

> 
> On Fri, Feb 3, 2012 at 2:10 PM, -Hammer-  wrote:
>> So, we are preparing to add IPv6 to our multi-homed (separate routers and
>> carriers with IBGP) multi-site business. Starting off with a lab of course.
>> Circuits and hardware are a few months away. I'm doing the initial designs
>> and having some delivery questions with the carrier(s). One interesting
>> question came up. There was a thread I found (and have since lost) regarding
>> what routes to accept. Currently, in IPv4, we accept a default route only
>> from both carriers at both sites. Works fine. Optimal? No. Significantly
>> negative impact? No. In IPv6, I have heard some folks say that in a
>> multi-homed environment it is better to get the full IPv6 table fed into
>> both of your edge routers. Ok. Fine. Then, The thread I was referring to
>> said that it is also advisable to have the entire IPv4 table fed in
>> parallel. Ok. I understand we are talking about completely separate
>> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
>> potentially introduce some latency.
>> 
>> "If you have a specific route to a  record but a less specific route to
>> an A record the potential is for the trip to take longer."
>> 
>> That was the premise of the thread. I swear I googled it for 20 minutes to
>> link before giving up. Anyway, can anyone who's been thru this provide any
>> opinions on why or why not it is important to accept the full IPv6 table AND
>> the full IPv4 table? I have the hardware to handle it I'm just not sure long
>> term what the reasoning would be for or against. Again, I'm an end customer.
>> Not a carrier. So my concern is (A) my Internet facing applications and (B)
>> my users who eventually will surf IPv6.
>> 
>> Any guidance would be appreciated. Thanks.
>> 
>> 
>> 
>> 
>> -Hammer-
>> 
>> "I was a normal American nerd"
>> -Jack Herer
>> 
>> 
>> 
> 

Re: IPv6 dual stacking and route tables

[-Hammer-]

OK. Looking forward to getting the lab up. Since I can handle the volume 
I'll take both tables. At least in the lab. Looking forward to doing 
some experiments with DNS just to see what all the fuss is about. Looks 
like I'll need to order a Mac for the lab. No harm there. :)


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/3/2012 2:47 PM, Jeroen Massar wrote:

On 2012-02-03 21:37 , -Hammer- wrote:

Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online
and offline responses. That was fast. The struggle is that I'm having
trouble seeing how/why it would matter other than potential latency on
the IPv4 side. IPv6 conversations usually involve taking the full table
when dealing with multi-homed/multi-site setups. IPv4 I didn't really
consider (taking the full table) until I mentioned this to some of my
vendors technical folks and it caused a lot of reflection. Not on the L3
part. Just on the DNS part. This appears to be a tough subject area when
it comes to V4/V6 deployment strategies. The bottom line is that I'll
take whatever the carrier feeds in V6. Just trying to see where I would
be missing out by not doing the same in V4. Again, I have the hardware
to support it and I really have no reason not to do it. I just want to
be able to justify to myself why I'm doing it.

Why you want non-defaults in both IPv4 and IPv6:
  - more possible paths
  - less chances of blackholes.

And of course, those paths will be more stable and you don't get
hot-potato swapping between two defaults.

And that in turn allows the Happy Eyeballs mechanisms to do their jobs
much better as they keep a history per host or prefix, they assume IPv6
/48's and IPv4 /24's from what I have seen, in some cases.

Greets,
  Jeroen

Re: IPv6 dual stacking and route tables

[Jeroen Massar]

On 2012-02-03 21:37 , -Hammer- wrote:
> Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online
> and offline responses. That was fast. The struggle is that I'm having
> trouble seeing how/why it would matter other than potential latency on
> the IPv4 side. IPv6 conversations usually involve taking the full table
> when dealing with multi-homed/multi-site setups. IPv4 I didn't really
> consider (taking the full table) until I mentioned this to some of my
> vendors technical folks and it caused a lot of reflection. Not on the L3
> part. Just on the DNS part. This appears to be a tough subject area when
> it comes to V4/V6 deployment strategies. The bottom line is that I'll
> take whatever the carrier feeds in V6. Just trying to see where I would
> be missing out by not doing the same in V4. Again, I have the hardware
> to support it and I really have no reason not to do it. I just want to
> be able to justify to myself why I'm doing it.

Why you want non-defaults in both IPv4 and IPv6:
 - more possible paths
 - less chances of blackholes.

And of course, those paths will be more stable and you don't get
hot-potato swapping between two defaults.

And that in turn allows the Happy Eyeballs mechanisms to do their jobs
much better as they keep a history per host or prefix, they assume IPv6
/48's and IPv4 /24's from what I have seen, in some cases.

Greets,
 Jeroen

Re: IPv6 dual stacking and route tables

[-Hammer-]

Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online 
and offline responses. That was fast. The struggle is that I'm having 
trouble seeing how/why it would matter other than potential latency on 
the IPv4 side. IPv6 conversations usually involve taking the full table 
when dealing with multi-homed/multi-site setups. IPv4 I didn't really 
consider (taking the full table) until I mentioned this to some of my 
vendors technical folks and it caused a lot of reflection. Not on the L3 
part. Just on the DNS part. This appears to be a tough subject area when 
it comes to V4/V6 deployment strategies. The bottom line is that I'll 
take whatever the carrier feeds in V6. Just trying to see where I would 
be missing out by not doing the same in V4. Again, I have the hardware 
to support it and I really have no reason not to do it. I just want to 
be able to justify to myself why I'm doing it.


A lot of kinks to work out this year.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/3/2012 2:28 PM, Jeroen Massar wrote:

On 2012-02-03 21:10 , -Hammer- wrote:


So, we are preparing to add IPv6 to our multi-homed (separate routers
and carriers with IBGP) multi-site business. Starting off with a lab of
course.

Dear "Hammer",

Welcome to the 21th century. 2012 is going to "the year" (they claim,
again ;) of IPv6 thus it is better to start before the big launch event
that is this year, (of which there was also one back in in 2004:
http://www.global-ipv6.org/ for the folks who have IPv6 for some time
now ;) Better late than never some would say.


Circuits and hardware are a few months away. I'm doing the
initial designs and having some delivery questions with the carrier(s).
One interesting question came up. There was a thread I found (and have
since lost) regarding what routes to accept. Currently, in IPv4, we
accept a default route only from both carriers at both sites. Works
fine. Optimal? No. Significantly negative impact? No. In IPv6, I have
heard some folks say that in a multi-homed environment it is better to
get the full IPv6 table fed into both of your edge routers. Ok. Fine.
Then, The thread I was referring to said that it is also advisable to
have the entire IPv4 table fed in parallel. Ok. I understand we are
talking about completely separate protocols. So it's not a layer 3
issue.

The only advantage of more routes, in both IPv4 and IPv6 is that the
path selection can be better. An end-host does not make this decision
where packets flow, thus having a full route or not should not matter
much, except that the route might be more optimal. No DNS involvement
here yet.

The trick comes with Happy-Eyeballs alike setups (especially Mac OSX
Lion and up which does not follow that spec and in which it cannot be
turned off either, which is awesome when you are debugging things...)

Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool.

Chrome has it's own HE implementation, thus if you run Chrome on a Mac
you will have sometimes one sometimes another connect depending on if
you are using Safari or Chrome for instance as Safari does use the
system provided things. Ping will pick another again etc. It will be
quite random all the time.

The fun with the Mac OS X implementation is that it keeps a local cache
of per-destination latency/speed information.

If you thus have two default routes, be that IPv4 or IPv6, and your
routers are swapping paths between either and thus don't have a stable
outgoing path those latencies will vary and thus the pretty HE
algorithms will be very confused.

This is likely why your "source" recommended to have a full path, as per
sub-prefix the path will become more stable and established than if you
are doing hot-potato with two defaults.

Greets,
  Jeroen

Re: IPv6 dual stacking and route tables

[Jeroen Massar]

On 2012-02-03 21:10 , -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers
> and carriers with IBGP) multi-site business. Starting off with a lab of
> course.

Dear "Hammer",

Welcome to the 21th century. 2012 is going to "the year" (they claim,
again ;) of IPv6 thus it is better to start before the big launch event
that is this year, (of which there was also one back in in 2004:
http://www.global-ipv6.org/ for the folks who have IPv6 for some time
now ;) Better late than never some would say.

> Circuits and hardware are a few months away. I'm doing the
> initial designs and having some delivery questions with the carrier(s).
> One interesting question came up. There was a thread I found (and have
> since lost) regarding what routes to accept. Currently, in IPv4, we
> accept a default route only from both carriers at both sites. Works
> fine. Optimal? No. Significantly negative impact? No. In IPv6, I have
> heard some folks say that in a multi-homed environment it is better to
> get the full IPv6 table fed into both of your edge routers. Ok. Fine.
> Then, The thread I was referring to said that it is also advisable to
> have the entire IPv4 table fed in parallel. Ok. I understand we are
> talking about completely separate protocols. So it's not a layer 3
> issue.

The only advantage of more routes, in both IPv4 and IPv6 is that the
path selection can be better. An end-host does not make this decision
where packets flow, thus having a full route or not should not matter
much, except that the route might be more optimal. No DNS involvement
here yet.

The trick comes with Happy-Eyeballs alike setups (especially Mac OSX
Lion and up which does not follow that spec and in which it cannot be
turned off either, which is awesome when you are debugging things...)

Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool.

Chrome has it's own HE implementation, thus if you run Chrome on a Mac
you will have sometimes one sometimes another connect depending on if
you are using Safari or Chrome for instance as Safari does use the
system provided things. Ping will pick another again etc. It will be
quite random all the time.

The fun with the Mac OS X implementation is that it keeps a local cache
of per-destination latency/speed information.

If you thus have two default routes, be that IPv4 or IPv6, and your
routers are swapping paths between either and thus don't have a stable
outgoing path those latencies will vary and thus the pretty HE
algorithms will be very confused.

This is likely why your "source" recommended to have a full path, as per
sub-prefix the path will become more stable and established than if you
are doing hot-potato with two defaults.

Greets,
 Jeroen

Re: IPv6 dual stacking and route tables

[Cameron Byrne]

On Fri, Feb 3, 2012 at 12:10 PM, -Hammer-  wrote:
> So, we are preparing to add IPv6 to our multi-homed (separate routers and
> carriers with IBGP) multi-site business. Starting off with a lab of course.
> Circuits and hardware are a few months away. I'm doing the initial designs
> and having some delivery questions with the carrier(s). One interesting
> question came up. There was a thread I found (and have since lost) regarding
> what routes to accept. Currently, in IPv4, we accept a default route only
> from both carriers at both sites. Works fine. Optimal? No. Significantly
> negative impact? No. In IPv6, I have heard some folks say that in a
> multi-homed environment it is better to get the full IPv6 table fed into
> both of your edge routers. Ok. Fine. Then, The thread I was referring to
> said that it is also advisable to have the entire IPv4 table fed in
> parallel. Ok. I understand we are talking about completely separate
> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
> potentially introduce some latency.
>
> "If you have a specific route to a  record but a less specific route to
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to
> link before giving up. Anyway, can anyone who's been thru this provide any
> opinions on why or why not it is important to accept the full IPv6 table AND
> the full IPv4 table? I have the hardware to handle it I'm just not sure long
> term what the reasoning would be for or against. Again, I'm an end customer.
> Not a carrier. So my concern is (A) my Internet facing applications and (B)
> my users who eventually will surf IPv6.
>
> Any guidance would be appreciated. Thanks.
>
>

Well.  I don't really follow the above text.

But, the principle is the same for IPv4 or IPv6.  If you take a full
or partial table, your router can make a better choice than just
getting default  (only maybe, BGP is never guaranteeing anything about
performance).

That said, in v6, it is a little bit more important, IMHO, to take the
ISP routes instead of just a default since the v6 peering is not as
robust out on the Internet.  There are still turf wars going on or
some SPs are still not peering IPv6 in all the places they peer for
IPv4.  Less peering = longer latency. But, this situation has improved
dramatically in the last 12 months.

In the end, my guidance is to take "provider routes" or "customer
route" + default.  This helps your router make an educated guess
without absorbing all the churn and gunk that a full BGP feed hits
your router with.  Make the SP trim those routes on their side so you
don't see it.

CB
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>

Re: IPv6 dual stacking and route tables

[Justin M. Streiner]

On Fri, 3 Feb 2012, -Hammer- wrote:

"If you have a specific route to a  record but a less specific route to 
an A record the potential is for the trip to take longer."


That was the premise of the thread. I swear I googled it for 20 minutes to 
link before giving up. Anyway, can anyone who's been thru this provide any 
opinions on why or why not it is important to accept the full IPv6 table AND 
the full IPv4 table? I have the hardware to handle it I'm just not sure long 
term what the reasoning would be for or against. Again, I'm an end customer. 
Not a carrier. So my concern is (A) my Internet facing applications and (B) 
my users who eventually will surf IPv6.


We currently take full v4 and v6 routes, however we do not yet have 
end-users officially on v6 (users doing their own 6to4 tunnels and stuff 
like Teredo notwithstanding), so I don't have any experience with the 
A/ resolution asymmetry you're describing.


jms

Re: IPv6 dual stacking and route tables

[Philip Dorr]

You should accept the full v6 table, because some IPs may not,
currently, be reachable via one of the carriers.

On Fri, Feb 3, 2012 at 2:10 PM, -Hammer-  wrote:
> So, we are preparing to add IPv6 to our multi-homed (separate routers and
> carriers with IBGP) multi-site business. Starting off with a lab of course.
> Circuits and hardware are a few months away. I'm doing the initial designs
> and having some delivery questions with the carrier(s). One interesting
> question came up. There was a thread I found (and have since lost) regarding
> what routes to accept. Currently, in IPv4, we accept a default route only
> from both carriers at both sites. Works fine. Optimal? No. Significantly
> negative impact? No. In IPv6, I have heard some folks say that in a
> multi-homed environment it is better to get the full IPv6 table fed into
> both of your edge routers. Ok. Fine. Then, The thread I was referring to
> said that it is also advisable to have the entire IPv4 table fed in
> parallel. Ok. I understand we are talking about completely separate
> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
> potentially introduce some latency.
>
> "If you have a specific route to a  record but a less specific route to
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to
> link before giving up. Anyway, can anyone who's been thru this provide any
> opinions on why or why not it is important to accept the full IPv6 table AND
> the full IPv4 table? I have the hardware to handle it I'm just not sure long
> term what the reasoning would be for or against. Again, I'm an end customer.
> Not a carrier. So my concern is (A) my Internet facing applications and (B)
> my users who eventually will surf IPv6.
>
> Any guidance would be appreciated. Thanks.
>
>
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>

Re: IPv6 dual stacking and route tables

[Ryan Rawdon]

On Feb 3, 2012, at 3:10 PM, -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers and 
> carriers with IBGP) multi-site business. Starting off with a lab of course. 
> Circuits and hardware are a few months away. I'm doing the initial designs 
> and having some delivery questions with the carrier(s). One interesting 
> question came up. There was a thread I found (and have since lost) regarding 
> what routes to accept. Currently, in IPv4, we accept a default route only 
> from both carriers at both sites. Works fine. Optimal? No. Significantly 
> negative impact? No. In IPv6, I have heard some folks say that in a 
> multi-homed environment it is better to get the full IPv6 table fed into both 
> of your edge routers. Ok. Fine. Then, The thread I was referring to said that 
> it is also advisable to have the entire IPv4 table fed in parallel. Ok. I 
> understand we are talking about completely separate protocols. So it's not a 
> layer 3 issue. The reasoning was that DNS could potentially introduce some 
> latency.
> 
> "If you have a specific route to a  record but a less specific route to 
> an A record the potential is for the trip to take longer."
> 
> That was the premise of the thread. I swear I googled it for 20 minutes to 
> link before giving up. Anyway, can anyone who's been thru this provide any 
> opinions on why or why not it is important to accept the full IPv6 table AND 
> the full IPv4 table? I have the hardware to handle it I'm just not sure long 
> term what the reasoning would be for or against. Again, I'm an end customer. 
> Not a carrier. So my concern is (A) my Internet facing applications and (B) 
> my users who eventually will surf IPv6.
> 
> Any guidance would be appreciated. Thanks.
> 
> -Hammer-

We have been accepting our upstreams' connected and customer routes only (v4) 
and full routes (v6) without issue.  I can't say that I have previously heard 
of the DNS performance example/concern you provided above

IPv6 dual stacking and route tables

[-Hammer-]

So, we are preparing to add IPv6 to our multi-homed (separate routers 
and carriers with IBGP) multi-site business. Starting off with a lab of 
course. Circuits and hardware are a few months away. I'm doing the 
initial designs and having some delivery questions with the carrier(s). 
One interesting question came up. There was a thread I found (and have 
since lost) regarding what routes to accept. Currently, in IPv4, we 
accept a default route only from both carriers at both sites. Works 
fine. Optimal? No. Significantly negative impact? No. In IPv6, I have 
heard some folks say that in a multi-homed environment it is better to 
get the full IPv6 table fed into both of your edge routers. Ok. Fine. 
Then, The thread I was referring to said that it is also advisable to 
have the entire IPv4 table fed in parallel. Ok. I understand we are 
talking about completely separate protocols. So it's not a layer 3 
issue. The reasoning was that DNS could potentially introduce some latency.


"If you have a specific route to a  record but a less specific route 
to an A record the potential is for the trip to take longer."


That was the premise of the thread. I swear I googled it for 20 minutes 
to link before giving up. Anyway, can anyone who's been thru this 
provide any opinions on why or why not it is important to accept the 
full IPv6 table AND the full IPv4 table? I have the hardware to handle 
it I'm just not sure long term what the reasoning would be for or 
against. Again, I'm an end customer. Not a carrier. So my concern is (A) 
my Internet facing applications and (B) my users who eventually will 
surf IPv6.


Any guidance would be appreciated. Thanks.




-Hammer-

"I was a normal American nerd"
-Jack Herer

bufferbloat videos are up.

[Jim Gettys]

If people have heard of bufferbloat at all, it is usually just an
abstraction despite having had personal experience with it. Bufferbloat
can occur in your operating system, your home router, your broadband
gear, wireless, and almost anywhere in the Internet. Most still think
that if experience poor Internet speed means they must need more
bandwidth, and take vast speed variation for granted. Sometimes, adding
bandwidth can actually hurt rather than help. Most people have no idea
what they can do about bufferbloat.

So I’ve been working to put together several demos to help make
bufferbloat concrete, and demonstrate at least partial mitigation. The
mitigation shown may or may not work in your home router, and you need
to be able to set both upload and download bandwidth. People like Fred
Baker, with fiber to his house and Cisco routers, need not pay attention

Two of four cases we commonly all suffer from at home are:

 1. Broadband bufferbloat (upstream)
 2. Home router bufferbloat (downstream)

Rather than attempt to show worst case bufferbloat which can easily
induce complete failure, I decided to demonstrate these two cases of
“typical” bufferbloat as shown by the ICSI data. As the bufferbloat
varies widely as theICSI data
shows
,
your mileage will also vary widely.
There are two versions of the video:

 1. A short bufferbloat video
, of slightly over 8
minutes, which includes both demonstrations, but elides most of the
explanation. It’s intent is to get people “hooked” so they will want
to know more.
 2. The longer version of the video
clocks in at 21 minutes,
includes both demonstrations, but gives a simplified explanation of
bufferbloat’s cause, to encourage people to dig yet further.

Best regards,
Jim Gettys

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.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

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

If you have any comments please contact Philip Smith .

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

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

Analysis Summary


BGP routing table entries examined:  395820
Prefixes after maximum aggregation:  169388
Deaggregation factor:  2.34
Unique aggregates announced to Internet: 191947
Total ASes present in the Internet Routing Table: 40003
Prefixes per ASN:  9.89
Origin-only ASes present in the Internet Routing Table:   32689
Origin ASes announcing only one prefix:   15521
Transit ASes present in the Internet Routing Table:5393
Transit-only ASes present in the Internet Routing Table:142
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  33
Max AS path prepend of ASN (48687)   24
Prefixes from unregistered ASNs in the Routing Table:   315
Unregistered ASNs in the Routing Table: 120
Number of 32-bit ASNs allocated by the RIRs:   2257
Number of 32-bit ASNs visible in the Routing Table:1921
Prefixes from 32-bit ASNs in the Routing Table:4672
Special use prefixes present in the Routing Table:2
Prefixes being announced from unallocated address space:120
Number of addresses announced to Internet:   2512081104
Equivalent to 149 /8s, 187 /16s and 80 /24s
Percentage of available address space announced:   67.8
Percentage of allocated address space announced:   67.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   92.0
Total number of prefixes smaller than registry allocations:  167934

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:97613
Total APNIC prefixes after maximum aggregation:   31507
APNIC Deaggregation factor:3.10
Prefixes being announced from the APNIC address blocks:   93918
Unique aggregates announced from the APNIC address blocks:39044
APNIC Region origin ASes present in the Internet Routing Table:4648
APNIC Prefixes per ASN:   20.21
APNIC Region origin ASes announcing only one prefix:   1238
APNIC Region transit ASes present in the Internet Routing Table:731
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 18
Number of APNIC region 32-bit ASNs visible in the Routing Table:140
Number of APNIC addresses announced to Internet:  635833440
Equivalent to 37 /8s, 230 /16s and 12 /24s
Percentage of available APNIC address space announced: 80.6

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/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, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:148115
Total ARIN prefixes after maximum aggregation:75385
ARIN Deaggregation factor: 1.96
Prefixes being announced from the ARIN address blocks:   120087
Unique aggregates announced from the ARIN address blocks: 49290
ARIN Region origin ASes present in the Internet Routing Table:14884
ARIN Prefixes per ASN: 8.07
ARIN Region origin ASes announcing only one prefix:5683
ARIN 

Re: [rt-users] External Auth using Active Directory 2008

[james machado]

my apologies - fat fingered the email address

 james

Re: [rt-users] External Auth using Active Directory 2008

[james machado]

I would use ldapsearch on that machine to make sure you can bind to
the AD server using the login credentials in your Site_Config.  Make
sure you are using the proper certificates to connect via the TLS you
have configured.  I've noticed that being one of the biggest problems
with ldap and Windows 2008 and 2008 R2 AD servers.

james

Re: [POLITICS] ICANN elections

[Eric Brunner-Williams]

What Bill said.

Comments to the website
(http://aso.icann.org/people/icann-board-elections/2012-elections/)
are moderated, so any statements of support won't show up (except to
the person who makes the statement) until the moderator has gotten a
round tuit.

The [s]electorate to be persuaded is here:
http://aso.icann.org/people/address-council/address-council-members/

Cheers,
Eric

> There are four really good candidates.  Please consider sending in a 
> statement of
> support for one of them.
> 
> /bill
> 
> - Forwarded message -
> 
> Date: Fri, 03 Feb 2012 09:38:06 +1000
> To: Bill Manning 
> Subject: Comment Period for ICANN Board Seat 9 Election
> 
> Consistent with the ASO Memorandum of Understanding and ICANN Bylaws,
> the Address Supporting Organization Address Council (ASO AC) is
> responsible for the appointment of a representative to serve on Seat
> Number 9 of the ICANN Board.
> 
> The ASO AC is pleased to announce the following four candidates for its
> upcoming appointment.
> 
> The Candidates are:
> 
> - Thomas Eric Brunner-Williams
> - Martin J. Levy
> - William Manning
> - Raymond Alan Plzak
> 
> In accordance with the ASO AC election procedures, a comment period is
> now open. A short biography is available and supporting comment
> facilities for each candidate may be found at:
> 
> http://aso.icann.org/people/icann-board-elections/2012-elections/
> 
> The comment period will close at 23:59 UTC on 19 April 2012. Comments
> will be moderated.
> 
> ASO Secretariat
> secretar...@aso.icann.org
> 
> - End forwarded message -
> 
> 
> 

RE: Thanks & Let's Prevent this in the Future.

[Murphy, Sandra]

Thanks for the reminder, Richard.

Yes, as I announced earlier (see
http://mailman.nanog.org/pipermail/nanog/2012-January/044493.html
- the message with the corrected date), there is an interim sidr meeting on 
Thu *9* Feb in San Diego.

Registration is free.  
Registration is easy (email).  
Registration is open to all.
Registration is open ended.
Registration is encouraged (so we know how many to expect).  

As the message says, see the sidr wiki 
http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209 for agenda 
and a list of attendees.

--Sandy Murphy


From: Richard Barnes [richard.bar...@gmail.com]
Sent: Friday, February 03, 2012 8:09 AM
To: Arturo Servin
Cc: nanog
Subject: Re: Thanks & Let's Prevent this in the Future.

In related news, the IETF working group that is writing standards for
the RPKI is having an interim meeting in San Diego just after NANOG.
They deliberately chose that place/time to make it easy for NANOG
attendees to contribute, so comments from this community are
definitely welcome.

Re: Verisign deep-hacked. For months.

[Rubens Kuhl]

On Thu, Feb 2, 2012 at 10:34 PM, Jeff Wheeler  wrote:
> On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
>  wrote:
>> So what part of VRSN got broken into?  They do a lot more than just DNS.
>
> Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
> Illuminet is also in the business of recording telephone calls, SMS
> messages, etc. for law enforcement.

Wasn't this division acquired by TNS ?
http://www.bizjournals.com/washington/stories/2009/05/04/daily5.html


Rubens

[POLITICS] ICANN elections

[bmanning]

There are four really good candidates.  Please consider sending in a statement 
of
support for one of them.

/bill

- Forwarded message -

Date: Fri, 03 Feb 2012 09:38:06 +1000
To: Bill Manning 
Subject: Comment Period for ICANN Board Seat 9 Election

Consistent with the ASO Memorandum of Understanding and ICANN Bylaws,
the Address Supporting Organization Address Council (ASO AC) is
responsible for the appointment of a representative to serve on Seat
Number 9 of the ICANN Board.

The ASO AC is pleased to announce the following four candidates for its
upcoming appointment.

The Candidates are:

- Thomas Eric Brunner-Williams
- Martin J. Levy
- William Manning
- Raymond Alan Plzak

In accordance with the ASO AC election procedures, a comment period is
now open. A short biography is available and supporting comment
facilities for each candidate may be found at:

http://aso.icann.org/people/icann-board-elections/2012-elections/

The comment period will close at 23:59 UTC on 19 April 2012. Comments
will be moderated.

ASO Secretariat
secretar...@aso.icann.org

- End forwarded message -

Re: Verisign deep-hacked. For months.

[Jay Ashworth]

- Original Message -
> From: "Jeff Wheeler" 

> On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
>  wrote:
> > So what part of VRSN got broken into? They do a lot more than just
> > DNS.
> 
> Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
> Illuminet is also in the business of recording telephone calls, SMS
> messages, etc. for law enforcement.

"Illuminet"?

Shea and Wilson would be proud.

Cheers,
-- jr 'and somewhere, an evil geek is dry-washing his hands' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: [#135346] Unauthorized BGP Announcements (follow up to Hijacked Networks)

[Justin M. Streiner]

On Thu, 2 Feb 2012, Dave Pooser wrote:


...and all we need is for billion-dollar corporations to start putting
moral rectitude ahead of profits.

Well, heck, that should start happening any day now! And then FedEx will
deliver my unicorn!



Your unicorn has been impounded by Customs.

jms

Re: Thanks & Let's Prevent this in the Future.

[Richard Barnes]

In related news, the IETF working group that is writing standards for
the RPKI is having an interim meeting in San Diego just after NANOG.
They deliberately chose that place/time to make it easy for NANOG
attendees to contribute, so comments from this community are
definitely welcome.





On Fri, Feb 3, 2012 at 7:16 AM, Arturo Servin  wrote:
>
>        One option is to use RPKI and origin validation. But it won't help 
> much unless prefix holders create their certificates and ROAs and networks 
> operators use those to validate origins. It won't solve all the issues but at 
> least some fat fingers/un-expierience errors.
>
>        We are running an experiment to detect route-hijacks/missconf using 
> RPKI. So far, not many routes are "signed" but at least we can periodically 
> check our own prefix (or any other with ROAs) to detect some inconsistencies:
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/
>
>
> Regards,
> -as
>
>
> On 1 Feb 2012, at 06:58, Kelvin Williams wrote:
>
>> First off, I'd like to thank everyone on this list who have reached out
>> today and offered us help with our hijacked network space.  It's so
>> refreshing to see that there are still so many who refuse to leave a
>> man/woman down.
>>
>> I'm not going to place any blame, its useless.  There were lies, there were
>> incompetencies, and there was negligence but that is now water under the
>> bridge.
>>
>> However, I think that we as network operators have a duty to each other to
>> make sure we don't allow a downstream customer wreck the operations of
>> another entity who has been rightfully allocated resources.
>>
>> A few months ago, when establishing a new peering relationship I was
>> encouraged (actually required) to utilize one of the IRRs.  I took the time
>> to register all of my routes, ASNs, etc.  However, as I learned today, this
>> was probably done in vain.  Too many people won't spend the extra
>> 30-seconds to verify the information listed there or in ARINs WHOIS.
>>
>> I don't care what a customer tells me, too many times I've found they
>> aren't 100% honest either for malicious/fraudulent reasons or they are
>> unknowing.  So, for our networks or the networks we manage, we want to
>> verify what a customer is saying to prevent what happened to us today.
>>
>> I'd like to get a conversation going and possibly some support of an
>> initiative to spend that extra 30-seconds to verify ownership and
>> authorization of network space to be advertised.  Additionally, if someone
>> rings your NOC's line an industry-standard process of verifying "ownership"
>> and immediately responding by filtering out announcements. There's no sense
>> in allowing a service provider to be impaired because a spammer doesn't
>> want to give up clean IP space.  Do you protect a bad customer or the
>> Internet as a whole?  I pick the Internet as a whole.
>>
>> How can we prevent anyone else from ever enduring this again?  While we may
>> never stop it from ever happening, spammers (that's what we got hit by
>> today) are a dime a dozen and will do everything possible to hit an Inbox,
>> so how can we establish a protocol to immediate mitigate the effects of an
>> traffic-stopping advertisement?
>>
>> I thought registering with IRRs and up-to-date information in ARINs WHOIS
>> was sufficient, apparently I was wrong.  Not everyone respects them, but
>> then again, they aren't very well managed (I've got several networks with
>> antiquated information I've been unable to remove, it doesn't impair us
>> normally, but its still there).
>>
>> What can we do?  Better yet, how do we as a whole respond when we encounter
>> upstream providers who refuse to look at the facts and allow another to
>> stay down?
>>
>> kw
>>
>> --
>> Kelvin Williams
>> Sr. Service Delivery Engineer
>> Broadband & Carrier Services
>> Altus Communications Group, Inc.
>>
>>
>> "If you only have a hammer, you tend to see every problem as a nail." --
>> Abraham Maslow
>

Re: [#135346] Unauthorized BGP Announcements (follow up to Hijacked

[Robert E. Seastrom]

Randy Bush  writes:

> well, not exactly.  to quote myself from the other week in another forum
>
> [ 30 lines deleted ]
>
> Sorry to drone on, but these three really need to be differentiated.

The truly wonderful thing about the evolution of BGP security is its
elegant simplicity.  It is good to know that the barriers to entry for
the IRR system (templates, objects, "Dear Colleague" emails from the
auto-dbm robot, etc) have been eradicated in favor of simple,
easy-to-understand and maintain maintain digital certificate chains.
I predict epic uptake the likes of which we haven't seen since I filed
my last NACR.

-r

Re: Thanks & Let's Prevent this in the Future.

[Arturo Servin]

One option is to use RPKI and origin validation. But it won't help much 
unless prefix holders create their certificates and ROAs and networks operators 
use those to validate origins. It won't solve all the issues but at least some 
fat fingers/un-expierience errors.

We are running an experiment to detect route-hijacks/missconf using 
RPKI. So far, not many routes are "signed" but at least we can periodically 
check our own prefix (or any other with ROAs) to detect some inconsistencies:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/

http://www.labs.lacnic.net/rpkitools/looking_glass/


Regards,
-as


On 1 Feb 2012, at 06:58, Kelvin Williams wrote:

> First off, I'd like to thank everyone on this list who have reached out
> today and offered us help with our hijacked network space.  It's so
> refreshing to see that there are still so many who refuse to leave a
> man/woman down.
> 
> I'm not going to place any blame, its useless.  There were lies, there were
> incompetencies, and there was negligence but that is now water under the
> bridge.
> 
> However, I think that we as network operators have a duty to each other to
> make sure we don't allow a downstream customer wreck the operations of
> another entity who has been rightfully allocated resources.
> 
> A few months ago, when establishing a new peering relationship I was
> encouraged (actually required) to utilize one of the IRRs.  I took the time
> to register all of my routes, ASNs, etc.  However, as I learned today, this
> was probably done in vain.  Too many people won't spend the extra
> 30-seconds to verify the information listed there or in ARINs WHOIS.
> 
> I don't care what a customer tells me, too many times I've found they
> aren't 100% honest either for malicious/fraudulent reasons or they are
> unknowing.  So, for our networks or the networks we manage, we want to
> verify what a customer is saying to prevent what happened to us today.
> 
> I'd like to get a conversation going and possibly some support of an
> initiative to spend that extra 30-seconds to verify ownership and
> authorization of network space to be advertised.  Additionally, if someone
> rings your NOC's line an industry-standard process of verifying "ownership"
> and immediately responding by filtering out announcements. There's no sense
> in allowing a service provider to be impaired because a spammer doesn't
> want to give up clean IP space.  Do you protect a bad customer or the
> Internet as a whole?  I pick the Internet as a whole.
> 
> How can we prevent anyone else from ever enduring this again?  While we may
> never stop it from ever happening, spammers (that's what we got hit by
> today) are a dime a dozen and will do everything possible to hit an Inbox,
> so how can we establish a protocol to immediate mitigate the effects of an
> traffic-stopping advertisement?
> 
> I thought registering with IRRs and up-to-date information in ARINs WHOIS
> was sufficient, apparently I was wrong.  Not everyone respects them, but
> then again, they aren't very well managed (I've got several networks with
> antiquated information I've been unable to remove, it doesn't impair us
> normally, but its still there).
> 
> What can we do?  Better yet, how do we as a whole respond when we encounter
> upstream providers who refuse to look at the facts and allow another to
> stay down?
> 
> kw
> 
> -- 
> Kelvin Williams
> Sr. Service Delivery Engineer
> Broadband & Carrier Services
> Altus Communications Group, Inc.
> 
> 
> "If you only have a hammer, you tend to see every problem as a nail." --
> Abraham Maslow