Re: Local Peering and Transit - BGP multihoming

2009-05-22 Thread Raymond Dijkxhoorn

Hi!


Yes, i can get sample of configuration via Google search.
but i am looking for best practices and from experience people.


Then post your suggested config and ask for comments.

Bye,
Raymond.



Re: Local Peering and Transit - BGP multihoming

2009-05-22 Thread Mans Nilsson
Subject: Re: Local Peering and Transit - BGP multihoming Date: Fri, May 22, 
2009 at 10:55:14AM +0200 Quoting Raymond Dijkxhoorn (raym...@prolocation.net):
> Hi!
>
>> Yes, i can get sample of configuration via Google search.
>> but i am looking for best practices and from experience people.
>
> Then post your suggested config and ask for comments.

...on a suitable list, dedicated to Cisco gear.. 
-- 
Måns Nilsson





Re: Local Peering and Transit - BGP multihoming

2009-05-22 Thread Raymond Dijkxhoorn

Hi!


Yes, i can get sample of configuration via Google search.
but i am looking for best practices and from experience people.



Then post your suggested config and ask for comments.



...on a suitable list, dedicated to Cisco gear..


Sorry, yes. :-) Plenty of Cisco lists there to answer 'questions' :-)

Bye,
Raymond.



Re: Local Peering and Transit - BGP multihoming

2009-05-22 Thread jamie rishaw
on issues like this :

[1] JFGI
  -> if fail :
[2] man smartnet
  -> if fail :
[3] go back to studying to get that A+ and consider perhaps a yob in redmond



On Fri, May 22, 2009 at 4:01 AM, Raymond Dijkxhoorn  wrote:

> Hi!
>
>  Yes, i can get sample of configuration via Google search.
 but i am looking for best practices and from experience people.

>>>
>  Then post your suggested config and ask for comments.
>>>
>>
>  ...on a suitable list, dedicated to Cisco gear..
>>
>
> Sorry, yes. :-) Plenty of Cisco lists there to answer 'questions' :-)
>
> Bye,
> Raymond.
>
>


-- 
Jamie Rishaw // .com.a...@j <- reverse it. ish.
[Impressive C-level Title Here], arpa / arpa labs


BGP Update Report

2009-05-22 Thread cidr-report
BGP Update Report
Interval: 19-Apr-09 -to- 20-May-09 (32 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS3130   135278  2.3% 526.4 -- RGNET-3130 RGnet/PSGnet
 2 - AS638954635  0.9%  12.6 -- BELLSOUTH-NET-BLK - 
BellSouth.net Inc.
 3 - AS21491   54546  0.9%1818.2 -- UTL-ON-LINE UTL On-line is RF 
broadband ISP in Uganda - Africa
 4 - AS845246129  0.8%  35.6 -- TEDATA TEDATA
 5 - AS35805   44098  0.8% 124.6 -- UTG-AS United Telecom AS
 6 - AS432343945  0.8%  10.1 -- TWTC - tw telecom holdings, inc.
 7 - AS17488   40990  0.7%  25.7 -- HATHWAY-NET-AP Hathway IP Over 
Cable Internet
 8 - AS33776   39232  0.7% 335.3 -- STARCOMMS-ASN
 9 - AS815137150  0.6%  25.3 -- Uninet S.A. de C.V.
10 - AS10834   35002  0.6%  13.8 -- Telefonica Data Argentina S.A.
11 - AS17974   32954  0.6%  30.3 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
12 - AS505631911  0.6% 270.4 -- INS-NET-2 - Iowa Network 
Services
13 - AS20115   30284  0.5%  17.9 -- CHARTER-NET-HKY-NC - Charter 
Communications
14 - AS22773   30145  0.5%  28.0 -- ASN-CXA-ALL-CCI-22773-RDC - Cox 
Communications Inc.
15 - AS424926865  0.5% 148.4 -- LILLY-AS - Eli Lilly and Company
16 - AS292026393  0.5% 321.9 -- LACOE - Los Angeles County 
Office of Education
17 - AS18566   25689  0.4%  24.1 -- COVAD - Covad Communications Co.
18 - AS15045   25633  0.4%6408.2 -- KITTELSON - KITTELSON AND 
ASSOCIATES, INC.
19 - AS505025385  0.4%1813.2 -- PSC-EXT - Pittsburgh 
Supercomputing Center
20 - AS29049   25109  0.4%  77.7 -- DELTA-TELECOM-AS Delta Telecom 
LTD.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS15045   25633  0.4%6408.2 -- KITTELSON - KITTELSON AND 
ASSOCIATES, INC.
 2 - AS409674159  0.1%4159.0 -- CSF-AS CSF Computersoftware 
fuer Fachanwendungen GmbH
 3 - AS169318223  0.1%4111.5 -- GLOBAL-PAYMENTS-1 - Global 
Payments, Inc.
 4 - AS32398   21297  0.4%3549.5 -- REALNET-ASN-1
 5 - AS13325   24488  0.4%3061.0 -- STOMI - State of Michigan, 
DMB-CNOC
 6 - AS131532546  0.0%2546.0 -- ONEWORLD OneWorld S.A.
 7 - AS292292447  0.0%2447.0 -- ASDA-AS Assotiation for the 
Development of West Athens
 8 - AS8499 2221  0.0%2221.0 -- Space Hellas Network Operation 
Center (NOC)
 9 - AS304234086  0.1%2043.0 -- AMEDI-3-ASN1 - Amedisys, Inc.
10 - AS21901  0.0%   4.0 -- NAVITAIRE-AS-AU-AP Accenture - 
Navitaire,
11 - AS476405605  0.1%1868.3 -- TRICOMPAS Tricomp Sp. z. o. o.
12 - AS21491   54546  0.9%1818.2 -- UTL-ON-LINE UTL On-line is RF 
broadband ISP in Uganda - Africa
13 - AS398033635  0.1%1817.5 -- UTI-AS SC UTI COMMUNICATIONS 
SYSTEMS SRL
14 - AS505025385  0.4%1813.2 -- PSC-EXT - Pittsburgh 
Supercomputing Center
15 - AS466534901  0.1%1633.7 -- FREDRIKSON---BYRON - Fredrikson 
& Byron, P.A.
16 - AS46328   10722  0.2%1191.3 -- PTCNEBRASKA - PIERCE TELEPHONE 
COMPANY, INCORPORATED
17 - AS289532324  0.0%1162.0 -- PIRAEUSBANK Greek banking 
institution
18 - AS472991084  0.0%1084.0 -- DRSA-AS Dlugie Rozmowy S.A.
19 - AS282561075  0.0%1075.0 -- 
20 - AS249942143  0.0%1071.5 -- GENESYS-AS GENESYS Informatica 
AS for announcing own prefixes


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 72.23.246.0/2424946  0.4%   AS5050  -- PSC-EXT - Pittsburgh 
Supercomputing Center
 2 - 41.204.2.0/24 21249  0.3%   AS32398 -- REALNET-ASN-1
 3 - 192.12.120.0/24   10320  0.2%   AS5691  -- MITRE-AS-5 - The MITRE 
Corporation
 4 - 63.103.104.0/228912  0.1%   AS15045 -- KITTELSON - KITTELSON AND 
ASSOCIATES, INC.
 5 - 63.103.108.0/238912  0.1%   AS15045 -- KITTELSON - KITTELSON AND 
ASSOCIATES, INC.
 6 - 64.69.192.0/20 8217  0.1%   AS16931 -- GLOBAL-PAYMENTS-1 - Global 
Payments, Inc.
 7 - 63.103.110.0/247795  0.1%   AS15045 -- KITTELSON - KITTELSON AND 
ASSOCIATES, INC.
 8 - 123.49.152.0/247511  0.1%   AS18118 -- CITICNET-AP CITIC Networks 
Management Co.,Ltd.
 9 - 123.49.144.0/216866  0.1%   AS18118 -- CITICNET-AP CITIC Networks 
Management Co.,Ltd.
10 - 195.96.69.0/24 6840  0.1%   AS8225  -- ASTELIT-MSK-AS Astelit 
Autonomous System
11 - 90.150.0.0/24  6121  0.1%   AS35400 -- MFIST Interregoinal 
Organization Network Technologies
12 - 193.201.184.0/21   5789  0.1%   AS25546 -- BROOKLANDCOMP-AS Brookland 
Computer Services
13 - 81.199.18.0/24 5628  0.1%   AS21491 -- UTL-ON-LINE UTL On-line i

The Cidr Report

2009-05-22 Thread cidr-report
This report has been generated at Fri May 22 21:21:01 2009 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
15-05-09294616  184074
16-05-09294623  184165
17-05-09294181  184536
18-05-09294340  184423
19-05-09294392  184113
20-05-09294351  184487
21-05-09294523  184151
22-05-09294690  184776


AS Summary
 31384  Number of ASes in routing system
 13350  Number of ASes announcing only one prefix
  4296  Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
  89741568  Largest address span announced by an AS (/32s)
AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center


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').

 --- 22May09 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 295607   184781   11082637.5%   All ASes

AS6389  4296  338 395892.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  4272 1777 249558.4%   TWTC - tw telecom holdings,
   inc.
AS209   2537 1159 137854.3%   ASN-QWEST - Qwest
   Communications Corporation
AS4766  1811  520 129171.3%   KIXS-AS-KR Korea Telecom
AS17488 1586  302 128481.0%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS4755  1251  149 110288.1%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS22773 1065   84  98192.1%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS1785  1766  835  93152.7%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS8452  1203  307  89674.5%   TEDATA TEDATA
AS8151  1445  575  87060.2%   Uninet S.A. de C.V.
AS19262  999  238  76176.2%   VZGNI-TRANSIT - Verizon
   Internet Services Inc.
AS18566 1062  424  63860.1%   COVAD - Covad Communications
   Co.
AS6478  1411  817  59442.1%   ATT-INTERNET3 - AT&T WorldNet
   Services
AS18101  752  171  58177.3%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS11492 1100  551  54949.9%   CABLEONE - CABLE ONE, INC.
AS855623  101  52283.8%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS22047  610   98  51283.9%   VTR BANDA ANCHA S.A.
AS577   1226  724  50240.9%   BACOM - Bell Canada
AS2706   536   44  49291.8%   HKSUPER-HK-AP Pacific Internet
   (Hong Kong) Limited
AS17676  565   81  48485.7%   GIGAINFRA Softbank BB Corp.
AS7018  1500 1035  46531.0%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS4808   629  169  46073.1%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS24560  692  258  43462.7%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS9443   526  102  42480.6%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS6517   661  241  42063.5%   RELIANCEGLOBALCOM - Reliance
   Globalcom Services, Inc
AS7011   968  556  41242.6%   FRONTIER-AND-CITIZENS -
   Frontier Communications of
   America, Inc.
AS4668   691  283  40859.0%   LGNET-AS-KR LG CNS
AS10620  914  514  40043.8%   TV Cable S.A.
AS5668   775  377  39851.4%   AS-5668 - CenturyTel Internet
 

Pseudowire Problem

2009-05-22 Thread Shivlu Jain
I have seen a weird behaviour in case of pseudo wire termination, it keeps
on polling the destination ip even if the interface mapped to pseudo wire is
down.
Is it the normal behaviour?

-- 
Thanks & Regards
shivlu jain
http://shivlu.blogspot.com/


in urgent need of router w/T3 interface

2009-05-22 Thread Adam Goodman
I have an urgent need for a router to replace the one that crocked last
night. If you have a router to sell or lend please contact me off list

It could be the following or equivalent of  a Cisco 7000 with the following
interfaces:
1x T3 clear channel (like a PA-T3)
1x FastEthernet

(Alternatively I can also use a wanPMC-C1T3 card with a PCI adapter.)

Thank you,
-Adam

Adam Goodman
E: a...@wispring.com
C: 801.971.1856


QWEST outage in the Southeast

2009-05-22 Thread Bobby Kuzma
Does anybody have any information on this? I've had 4 customers on Qwest for 
Internet connectivity in Florida drop off the net within a few minutes of each 
other.

Thanks,
Bobby Kuzma, CISSP
VP, Professional Services
ElectroNerdz, Inc.
Office: 863-709-0204x1911
Fax: 863-709-0506


Re: QWEST outage in the Southeast

2009-05-22 Thread Chris Adams
Once upon a time, Bobby Kuzma  said:
> Does anybody have any information on this? I've had 4 customers on Qwest for 
> Internet connectivity in Florida drop off the net within a few minutes of 
> each other.

I'm have Qwest via Atlanta and I'm not seeing any issues.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



Re: in urgent need of router w/T3 interface

2009-05-22 Thread Warren Kumari
I suspect that you might have more luck if you mentioned where you  
are, how far you would be willing to drive to pick one up and how long  
you would need to use it for...


For example, I could probably loan you an old 7200 that would fit the  
bill, but I'm in VA which probably wouldn't work out for you...


Feel free to mail me privately if you don't have any luck elsewhere  
and I'll pull it out of storage, make sure it is still a happy camper,  
etc...


W
On May 22, 2009, at 8:58 AM, Adam Goodman wrote:

I have an urgent need for a router to replace the one that crocked  
last

night. If you have a router to sell or lend please contact me off list

It could be the following or equivalent of  a Cisco 7000 with the  
following

interfaces:
1x T3 clear channel (like a PA-T3)
1x FastEthernet

(Alternatively I can also use a wanPMC-C1T3 card with a PCI adapter.)

Thank you,
-Adam

Adam Goodman
E: a...@wispring.com
C: 801.971.1856





AH or ESP

2009-05-22 Thread Glen Kent
Hi,

It is well known in the community that AH is NAT unfriendly while ESP cannot
be filtered, and most firewalls would not let such packets pass. I am NOT
interested in encrypting the data, but i do want origination authentication
(Integrity Protection). Do folks in such cases use AH or ESP-NULL, given
that both have some issues?

Thanks,
Glen


Re: AH or ESP

2009-05-22 Thread Christopher Morrow
On Fri, May 22, 2009 at 1:04 PM, Glen Kent  wrote:
> Hi,
>
> It is well known in the community that AH is NAT unfriendly while ESP cannot
> be filtered, and most firewalls would not let such packets pass. I am NOT

'the content of the esp packet can't be filtered in transit' I think
you mean... right?

> interested in encrypting the data, but i do want origination authentication
> (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given
> that both have some issues?
>
> Thanks,
> Glen
>



Weekly Routing Table Report

2009-05-22 Thread 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 23 May, 2009

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

Analysis Summary


BGP routing table entries examined:  288626
Prefixes after maximum aggregation:  136367
Deaggregation factor:  2.12
Unique aggregates announced to Internet: 141749
Total ASes present in the Internet Routing Table: 31322
Prefixes per ASN:  9.21
Origin-only ASes present in the Internet Routing Table:   27217
Origin ASes announcing only one prefix:   13291
Transit ASes present in the Internet Routing Table:4105
Transit-only ASes present in the Internet Routing Table: 95
Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  28
Max AS path prepend of ASN (12026)   22
Prefixes from unregistered ASNs in the Routing Table:   455
Unregistered ASNs in the Routing Table: 148
Number of 32-bit ASNs allocated by the RIRs:158
Prefixes from 32-bit ASNs in the Routing Table:  33
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:829
Number of addresses announced to Internet:   2044649600
Equivalent to 121 /8s, 222 /16s and 224 /24s
Percentage of available address space announced:   55.2
Percentage of allocated address space announced:   63.8
Percentage of available address space allocated:   86.4
Percentage of address space in use by end-sites:   77.1
Total number of prefixes smaller than registry allocations:  142558

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:67841
Total APNIC prefixes after maximum aggregation:   24339
APNIC Deaggregation factor:2.79
Prefixes being announced from the APNIC address blocks:   67272
Unique aggregates announced from the APNIC address blocks:30496
APNIC Region origin ASes present in the Internet Routing Table:3637
APNIC Prefixes per ASN:   18.50
APNIC Region origin ASes announcing only one prefix:991
APNIC Region transit ASes present in the Internet Routing Table:561
Average APNIC Region AS path length visible:3.5
Max APNIC Region AS path length visible: 18
Number of APNIC addresses announced to Internet:  450591072
Equivalent to 26 /8s, 219 /16s and 121 /24s
Percentage of available APNIC address space announced: 83.9

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
APNIC Address Blocks58/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,
   180/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:124887
Total ARIN prefixes after maximum aggregation:65697
ARIN Deaggregation factor: 1.90
Prefixes being announced from the ARIN address blocks:   125608
Unique aggregates announced from the ARIN address blocks: 51567
ARIN Region origin ASes present in the Internet Routing Table:13007
ARIN Prefixes per ASN: 9.66
ARIN Region origin ASes announcing only one prefix:4999
ARIN Region transit ASes present in the Internet Routing Table:1272
Average ARIN Region AS path length visible: 3.3
Max ARIN Region AS path length visible:  24
Number of ARIN addresses announced to Internet:  1008669056
Equivalent to 60 /8s, 31 /16s and 17 /24s
Percentage of available ARIN address space announced: 193.9

ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2

Re: in urgent need of router w/T3 interface

2009-05-22 Thread Adam Goodman
I must have forgotten to not my location. I am in Western Massachusetts.


On Fri, May 22, 2009 at 12:57 PM, Warren Kumari  wrote:

> I suspect that you might have more luck if you mentioned where you are, how
> far you would be willing to drive to pick one up and how long you would need
> to use it for...
>
> For example, I could probably loan you an old 7200 that would fit the bill,
> but I'm in VA which probably wouldn't work out for you...
>
> Feel free to mail me privately if you don't have any luck elsewhere and
> I'll pull it out of storage, make sure it is still a happy camper, etc...
>
> W
>
> On May 22, 2009, at 8:58 AM, Adam Goodman wrote:
>
>  I have an urgent need for a router to replace the one that crocked last
>> night. If you have a router to sell or lend please contact me off list
>>
>> It could be the following or equivalent of  a Cisco 7000 with the
>> following
>> interfaces:
>> 1x T3 clear channel (like a PA-T3)
>> 1x FastEthernet
>>
>> (Alternatively I can also use a wanPMC-C1T3 card with a PCI adapter.)
>>
>> Thank you,
>> -Adam
>>
>> Adam Goodman
>> E: a...@wispring.com
>> C: 801.971.1856
>>
>
>


Global pricing disparity -> Somali piracy

2009-05-22 Thread Martin Hannigan
FYI, I thought this was interesting reading for the workaholics among us as
we head into the holiday weekend in the United States. I'd also like to
follow it with an (hopefully) interesting question.


http://www.circleid.com/posts/20090520_bandwidth_buyers_price_differences_global_market/

The costs of wholesale bandwidth are significantly disparate by region, duh,
but this article demonstrates how disparate.

I was also recently discussing why some of these costs are disparate with a
colleague in the African region and he had an interesting question that I
thought would be operational enough to ask here.

Are any African or Middle East costs being influenced by the Somali piracy
problem? Is the deployment of Eassy being impacted by the piracy issue? The
cable ships are sitting ducks for pirate attacks during lay and repair
operations. There's one cable lay operation being guarded by the French
Navy, likely an Alcatel operation.

I'm interested to hear from anyone with direct knowledge (offline, I'll
summarize back if it's worth it, maybe even a lightning talk for Philly?) on
the impact. I suspect that it's possible that it could add cost to
maintenance agreements with any security caveats, but since most cable
operations taking place now were negotiated before the problem heightened,
perhaps not. I'd like to know if you know.

Best,

Martin Hannigan


-- 
Martin Hannigan   mar...@theicelandguy.com
p: +16178216079
Power, Network, and Costs Consulting for Iceland Datacenters and Occupants


Re: Global pricing disparity -> Somali piracy

2009-05-22 Thread Jeffrey Lyon
I can only imagine that costs are indeed affected. Companies
requesting combatant ship escorts are required to reimburse the
escorting nation.

-- 
Jeffrey Lyon, Leadership Team
jeffrey.l...@blacklotus.net | http://www.blacklotus.net
Black Lotus Communications of The IRC Company, Inc.

Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th
at Booth #401.



On Fri, May 22, 2009 at 3:41 PM, Martin Hannigan
 wrote:
> FYI, I thought this was interesting reading for the workaholics among us as
> we head into the holiday weekend in the United States. I'd also like to
> follow it with an (hopefully) interesting question.
>
>
> http://www.circleid.com/posts/20090520_bandwidth_buyers_price_differences_global_market/
>
> The costs of wholesale bandwidth are significantly disparate by region, duh,
> but this article demonstrates how disparate.
>
> I was also recently discussing why some of these costs are disparate with a
> colleague in the African region and he had an interesting question that I
> thought would be operational enough to ask here.
>
> Are any African or Middle East costs being influenced by the Somali piracy
> problem? Is the deployment of Eassy being impacted by the piracy issue? The
> cable ships are sitting ducks for pirate attacks during lay and repair
> operations. There's one cable lay operation being guarded by the French
> Navy, likely an Alcatel operation.
>
> I'm interested to hear from anyone with direct knowledge (offline, I'll
> summarize back if it's worth it, maybe even a lightning talk for Philly?) on
> the impact. I suspect that it's possible that it could add cost to
> maintenance agreements with any security caveats, but since most cable
> operations taking place now were negotiated before the problem heightened,
> perhaps not. I'd like to know if you know.
>
> Best,
>
> Martin Hannigan
>
>
> --
> Martin Hannigan                               mar...@theicelandguy.com
> p: +16178216079
> Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
>



Re: Pseudowire Problem

2009-05-22 Thread Danny McPherson


On May 22, 2009, at 6:20 AM, Shivlu Jain wrote:

I have seen a weird behaviour in case of pseudo wire termination, it  
keeps
on polling the destination ip even if the interface mapped to pseudo  
wire is

down.
Is it the normal behaviour?


Shivula,
You probably need to address your query to either your
vendor-specific mailing list, e.g.:




Or if you believe it's some protocol or specification
issue, the IETF's PWE3 WG mailing list:



HTH,

-danny



Multi-homed clients and BGP timers

2009-05-22 Thread Steve Bertrand
Hi all,

I've got numerous single-site 100Mb fibre clients who have backup SDSL
links to my PoP. The two services terminate on separate
distribution/access routers.

The CPE that peers to my fibre router sets a community, and my end sets
the pref to 150 based on it. The CPE also sets a higher pref for
prefixes from the fibre router. The SDSL router to CPE leaves the
default preference in place. Both of my PE gear sends default-originate
to the CPE. There is (generally) no traffic that should ever be on the
SDSL link while the fibre is up.

Both of the PE routers then advertise the learnt client route up into
the core:

*>i208.70.107.128/28
172.16.104.22 0150  0 64762 i
* i 172.16.104.23 0100  0 64762 i

My problem is the noticeable delay for switchover when the fibre happens
to go down (God forbid).

I would like to know if BGP timer adjustment is the way to adjust this,
or if there is a better/different way. It's fair to say that the fibre
doesn't 'flap'. Based on operational experience, if there is a problem
with the fibre network, it's down for the count.

While I'm at it, I've got another couple of questions:

- whatever technique you might recommend to reduce the convergence
throughout the network, can the same principles be applied to iBGP as well?

- if I need to down core2, what is the quickest and easiest way to
ensure that all gear connected to the cores will *quickly* switch to
preferring core1?

Steve



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Multi-homed clients and BGP timers

2009-05-22 Thread Zaid Ali
>From experience I found that you need to keep all the timers in sync with all 
>your peers. Something like this for every peer in your bgp config.

neighbor xxx.xx.xx.x timers 30 60

Make sure that this is communicated to your peer as well so that their timer 
setting are reflected the same.

Zaid
- Original Message -
From: "Steve Bertrand" 
To: "nanog list" 
Sent: Friday, May 22, 2009 3:45:20 PM GMT -08:00 US/Canada Pacific
Subject: Multi-homed clients and BGP timers

Hi all,

I've got numerous single-site 100Mb fibre clients who have backup SDSL
links to my PoP. The two services terminate on separate
distribution/access routers.

The CPE that peers to my fibre router sets a community, and my end sets
the pref to 150 based on it. The CPE also sets a higher pref for
prefixes from the fibre router. The SDSL router to CPE leaves the
default preference in place. Both of my PE gear sends default-originate
to the CPE. There is (generally) no traffic that should ever be on the
SDSL link while the fibre is up.

Both of the PE routers then advertise the learnt client route up into
the core:

*>i208.70.107.128/28
172.16.104.22 0150  0 64762 i
* i 172.16.104.23 0100  0 64762 i

My problem is the noticeable delay for switchover when the fibre happens
to go down (God forbid).

I would like to know if BGP timer adjustment is the way to adjust this,
or if there is a better/different way. It's fair to say that the fibre
doesn't 'flap'. Based on operational experience, if there is a problem
with the fibre network, it's down for the count.

While I'm at it, I've got another couple of questions:

- whatever technique you might recommend to reduce the convergence
throughout the network, can the same principles be applied to iBGP as well?

- if I need to down core2, what is the quickest and easiest way to
ensure that all gear connected to the cores will *quickly* switch to
preferring core1?

Steve




Re: Multi-homed clients and BGP timers

2009-05-22 Thread Steve Bertrand
Zaid Ali wrote:
> From experience I found that you need to keep all the timers in sync with all 
> your peers. Something like this for every peer in your bgp config.
> 
> neighbor xxx.xx.xx.x timers 30 60
> 
> Make sure that this is communicated to your peer as well so that their timer 
> setting are reflected the same.

Thankfully at this point, we manage all CPE of any clients who peer with
us, and so far, the clients advertise our own space back to us. I'll go
back to looking at adequate timer settings for my environment.

All it takes is a quick phone call to the client IT people to inform
them that a change will be made, and when they prefer I do it (in the
event something goes south). Also thankfully, I'm within a quick
walk/drive to these sites, which I've found to be a comfort during the
last year while I've walked the BGP learning curve (one of my clients in
particular leaves me with quite a few resources (fibre connections,
hardware) for me to *test* with between site-and-PoP ;)

Cheers, and thanks!

Steve


smime.p7s
Description: S/MIME Cryptographic Signature


Re: AH or ESP

2009-05-22 Thread Glen Kent
Yes, thats what i had meant !

On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:

> On Fri, May 22, 2009 at 1:04 PM, Glen Kent  wrote:
> > Hi,
> >
> > It is well known in the community that AH is NAT unfriendly while ESP
> cannot
> > be filtered, and most firewalls would not let such packets pass. I am NOT
>
> 'the content of the esp packet can't be filtered in transit' I think
> you mean... right?
>
> > interested in encrypting the data, but i do want origination
> authentication
> > (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given
> > that both have some issues?
> >
> > Thanks,
> > Glen
> >
>


Re: Multi-homed clients and BGP timers

2009-05-22 Thread Danny McPherson


On May 22, 2009, at 5:15 PM, Steve Bertrand wrote:



neighbor xxx.xx.xx.x timers 30 60

Make sure that this is communicated to your peer as well so that  
their timer setting are reflected the same.


Thankfully at this point, we manage all CPE of any clients who peer  
with
us, and so far, the clients advertise our own space back to us. I'll  
go

back to looking at adequate timer settings for my environment.

All it takes is a quick phone call to the client IT people to inform
them that a change will be made, and when they prefer I do it (in the
event something goes south). Also thankfully, I'm within a quick
walk/drive to these sites, which I've found to be a comfort during the
last year while I've walked the BGP learning curve (one of my  
clients in

particular leaves me with quite a few resources (fibre connections,
hardware) for me to *test* with between site-and-PoP ;)


Of course, given that the lowest BGP holdtime is selected
when the session is being established, you don't really need
to change the CPE side, all you need to do is make the
change on the network side and reset the session.  And it's
typically a good idea to set the keepalive interval to a
higher frequency when employing lower holdtimes such that
transient keepalive loss (or updates, which act as implicit
keepalives) don't cause any unnecessary instability.

Also, there are usually global values you can set for all
BGP neighbors in most implementations, as well as the per-peer
configuration illustrated above.  The former requires less
configuration bits if you're comfortable with setting the
values globally.

If you want to converge a little fast than BGP holdtimes here
and the fiber link is directly between the routers, you might
look at something akin to Cisco's "bgp fast-external-fallover",
which immediately resets the session if the link layer is
reset or lost.


While I'm at it, I've got another couple of questions:

- whatever technique you might recommend to reduce the convergence
throughout the network, can the same principles be applied to iBGP  
as well?


Depending on your definition of convergence, yes.  If you're
referring to update advertisements as opposed to session or
router failures, though, MRAI tweaks and/or less iBGP hierarchy
might be the way to go.  Then again, there are lots of side
effects with these as well..


- if I need to down core2, what is the quickest and easiest way to
ensure that all gear connected to the cores will *quickly* switch to
preferring core1?


Use your IGP mechanisms akin to IS-IS overload bit or OSPF
stub router (max metric) advertisement.

-danny



RE: Multi-homed clients and BGP timers

2009-05-22 Thread Deepak Jain
> If you want to converge a little fast than BGP holdtimes here
> and the fiber link is directly between the routers, you might
> look at something akin to Cisco's "bgp fast-external-fallover",
> which immediately resets the session if the link layer is
> reset or lost.
> 

Also things to consider: BFD for BGP and UDLD will help identify link failures 
faster. (If all of your equipment supports it, YMMV, etc).

Deepak



Re: Multi-homed clients and BGP timers

2009-05-22 Thread Steve Bertrand
Danny McPherson wrote:
> 
> On May 22, 2009, at 5:15 PM, Steve Bertrand wrote:
>>>
>>> neighbor xxx.xx.xx.x timers 30 60
>>>
>>> Make sure that this is communicated to your peer as well so that
>>> their timer setting are reflected the same.
>>
>> Thankfully at this point, we manage all CPE of any clients who peer with
>> us, and so far, the clients advertise our own space back to us. I'll go
>> back to looking at adequate timer settings for my environment.

> Of course, given that the lowest BGP holdtime is selected
> when the session is being established, you don't really need
> to change the CPE side, all you need to do is make the
> change on the network side and reset the session.  And it's
> typically a good idea to set the keepalive interval to a
> higher frequency when employing lower holdtimes such that
> transient keepalive loss (or updates, which act as implicit
> keepalives) don't cause any unnecessary instability.
> 
> Also, there are usually global values you can set for all
> BGP neighbors in most implementations, as well as the per-peer
> configuration illustrated above.  The former requires less
> configuration bits if you're comfortable with setting the
> values globally.

I remember reading that the lowest value is implemented, but thanks for
the reminder. In this case, since I *can* change it at the CPE, I may as
well. That way, in the event that I move on (or get hit by a bus) and
the next person moves the connection to a new router, the CPE will win.

Also... the global setting is a great idea. Unfortunately, connected to
this router that handles these fibre connections are a couple of local
peers that I don't want to change the 'defaults' for.

I can't remember if timers can be set at a peer-group level, so I'll
look that up and go from there. That will be my best option given what
is connected to this router.

> If you want to converge a little fast than BGP holdtimes here
> and the fiber link is directly between the routers, you might
> look at something akin to Cisco's "bgp fast-external-fallover",
> which immediately resets the session if the link layer is
> reset or lost.

Well, unfortunately, the local PUC owns the fibre, and they have a
switch aggregating all of their fibre in a star pattern. They then trunk
the VLANs to me across two redundant pair. I'm in the process of
persuading them to allow me to put my own gear in their location so I
can manage it myself (no risk of port-monitor, no risk of their ops
fscking up my clients etc). This way, they connect from their
client-facing converter into whatever port in my switch I tell them.

With that said, and as I said before, L3 and below rarely fails. I'll
look into fast-external-fallover. It may be worth it here.

> 
>> While I'm at it, I've got another couple of questions:
>>
>> - whatever technique you might recommend to reduce the convergence
>> throughout the network, can the same principles be applied to iBGP as
>> well?
> 
> Depending on your definition of convergence, yes.  If you're
> referring to update advertisements as opposed to session or
> router failures, though, MRAI tweaks and/or less iBGP hierarchy
> might be the way to go.  Then again, there are lots of side
> effects with these as well..

I suppose I might not completely understand what I am asking.

- pe1 has iBGP peering with p1 and p2, and pe1 has p2 as it's next hop
in FIB for prefix X (both cores have prefix X in routing table through a
different edge device)
- p2 suddenly falls off the network

Perhaps it's late enough on Friday night after a long day for me to not
be thinking correctly, but I can't figure out exactly what the delay
time would be for a client connected to pe1 to re-reach prefix X if p2
goes down hard.

>> - if I need to down core2, what is the quickest and easiest way to
>> ensure that all gear connected to the cores will *quickly* switch to
>> preferring core1?
> 
> Use your IGP mechanisms akin to IS-IS overload bit or OSPF
> stub router (max metric) advertisement.

I will certainly look into your suggestions. I have only a backbone area
in OSPF carrying loopbacks and infrastructure, but don't quite
understand the entire OSPF protocol yet.

Thanks Danny,

Steve


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Multi-homed clients and BGP timers

2009-05-22 Thread Jack Bates

Steve Bertrand wrote:

Well, unfortunately, the local PUC owns the fibre, and they have a
switch aggregating all of their fibre in a star pattern. They then trunk
the VLANs to me across two redundant pair. I'm in the process of
persuading them to allow me to put my own gear in their location so I
can manage it myself (no risk of port-monitor, no risk of their ops
fscking up my clients etc). This way, they connect from their
client-facing converter into whatever port in my switch I tell them.



Correct me if I'm wrong, but wasn't this exactly the type of situation 
that BFD was designed to detect and help with?



Jack



Re: Multi-homed clients and BGP timers

2009-05-22 Thread Steve Bertrand
Jack Bates wrote:
> Steve Bertrand wrote:
>> Well, unfortunately, the local PUC owns the fibre, and they have a
>> switch aggregating all of their fibre in a star pattern. They then trunk
>> the VLANs to me across two redundant pair. I'm in the process of
>> persuading them to allow me to put my own gear in their location so I
>> can manage it myself (no risk of port-monitor, no risk of their ops
>> fscking up my clients etc). This way, they connect from their
>> client-facing converter into whatever port in my switch I tell them.
>>
> 
> Correct me if I'm wrong, but wasn't this exactly the type of situation
> that BFD was designed to detect and help with?

I don't know, but I'm printing it[1] anyway to take home and read. It's
been mentioned a few times, and clearly worth learning about.

Thanks,

Steve

[1] http://bgp.potaroo.net/ietf/all-ids/draft-ietf-bfd-v4v6-1hop-09.txt


smime.p7s
Description: S/MIME Cryptographic Signature