Re: Any experience with Comcast digital voice for OOB (offlist is fine)

[Jay Ashworth]

- Original Message -
> From: eric-l...@truenet.com

> Subject: Any experience with Comcast digital voice for OOB (offlist is fine)

You're asking if a VoIP link could be used with traditional modems to do OOB 
management?

I'm pretty sure the answer is a flat no: any modems faster than 1200 bps
depend on phase change modulations that VoIP codecs can't begin to deal
with; FoIP is implemented by spoofing: the TA detects CNG tone, and spoofs
a datalink. 

I don't know of any TAs that will do that with regular data modems.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Managing IOS Configuration Snippets

[Keegan Holley]

On Feb 28, 2014, at 9:35 PM, Dale W. Carder  wrote:

> Thus spake Keegan Holley (no.s...@comcast.net) on Fri, Feb 28, 2014 at 
> 09:49:19AM -0500:
>> I wasn’t saying just fix it.  I was saying that router configs don’t lend 
>> well to versioning.  
> 
> Um, what?
> 
> $> rlog r-cssc-b280c-1-core.conf | grep 'total revision'
> total revisions: 2009;selected revisions: 2009

I wish you were here to see my eyes rolling.. 2009 versions of something are no 
more grok-able than one current version.  Congrats, you have a config backup 
system.
> 
>> When it’s a router config chances are someone fat-fingered something.  Most 
>> of the time the best thing to do is to fix or at least alert on the error, 
>> not to record it as a valid config version. 
> 
> We have our operators manually check in revisions (think in rcs terms:
> co -l router, go do work, verify it, ci -u router) rather than
> unsolicited / cron-triggered checkins.  Then the check-in message
> contains the operator's description text of the change and often a
> ticket number.  So there slightly fewer fat-finger configs checked in.

That’s not what the OP was looking for AFAIK.  This is just change management.

> 
> Dale

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Dobbins, Roland]

On Mar 1, 2014, at 9:14 AM, Keegan Holley  wrote:

> +1 in my experience uRPF get’s enabled, breaks something or causes confusion 
> (usually related to multi-homing) and then get’s disabled.

Enabling loose-check - even with allow-default - is useful solely for S/RTBH, 
if nothing else.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Are DomainKeys for e-mail signing dead?

[John Levine]

>If your LISTSERV
>   -- gets mail from somebody with a domain that requires their mail to be
>validly signed (for instance, via DMARC)
>   -- leaves that sender's address in the From: line
>   -- and breaks the DKIM signature

Ah, that problem.

I'd strongly suggest a shim in front of LISTSERV that checks for DMARC
policies other than p=none and rejects the incoming mail, simply to
protect other members of the list.  Otherwise people who follow DMARC
advice will reject list mail and get bounced off the list.  Yes, this
actually happens.

R's,
John

Re: Managing IOS Configuration Snippets

[Dale W. Carder]

Thus spake Keegan Holley (no.s...@comcast.net) on Fri, Feb 28, 2014 at 
09:49:19AM -0500:
> I wasn’t saying just fix it.  I was saying that router configs don’t lend 
> well to versioning.  

Um, what?

$> rlog r-cssc-b280c-1-core.conf | grep 'total revision'
total revisions: 2009;  selected revisions: 2009

> When it’s a router config chances are someone fat-fingered something.  Most 
> of the time the best thing to do is to fix or at least alert on the error, 
> not to record it as a valid config version. 

We have our operators manually check in revisions (think in rcs terms:
co -l router, go do work, verify it, ci -u router) rather than
unsolicited / cron-triggered checkins.  Then the check-in message
contains the operator's description text of the change and often a
ticket number.  So there slightly fewer fat-finger configs checked in.

Dale

Re: Managing IOS Configuration Snippets

[Dale W. Carder]

Thus spake Ryan Shea (ryans...@google.com) on Thu, Feb 27, 2014 at 09:38:33AM 
-0500:
> 
> Now, I hand you the 'show run' output and ask you if version 77 of the vty
> config is on this device. Can you answer the question? Now I hand you the
> 'show run' from 10,000 more device configs - and 100 more configuration
> chunks from revision control. Can you still answer the question? Assume a
> magical revision-history-aware configuration cross reference parser (while
> a noble and lovely goal) is not available.

Hi Ryan,

If I'm understanding what you're trying to do, you could script around 
our rather unsophisticated 'sgrep' (stanza grep) tool combined with 
scripting around rancid & rcs to do what I think you are looking for.

http://net.doit.wisc.edu/~dwcarder/scripts/sgrep

sgrep can dump out a "stanza" of ios-like config, then you can rcsdiff
that to your master, per 'chunk' of config.  

ex:
> sgrep -s "vty" r-cssc-b280c-1-core.conf
Found stanza in r-cssc-b280c-1-core.conf size:9
line vty 0 4
 access-class G-A-AdminAccess in
 exec-timeout 30 0
 ipv6 access-class G-A-v6AdminAccess in
line vty 5 24
 access-class G-A-AdminAccess in
 exec-timeout 30 0
 ipv6 access-class G-A-v6AdminAccess in
!

See the -s and -e options for our sgrep.

Add 'xargs -P' around your glue, and I think you'd be in luck.  If you 
were building configs around this model, you could use m4.

Dale

Re: Are DomainKeys for e-mail signing dead?

[staticsafe]

On 2/28/2014 18:36, Suresh Ramasubramanian wrote:
> On Saturday, March 1, 2014, Matthew Black  wrote:
> 
>> Apologies if I slept through prior discussions on the topic.
>> E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the
>> following error:
> 
> 
> Alive and well after the standard evolved.  Google DKIM and then DMARC.
> 
> I doubt anything as antique as listserv supports either, so route its
> inbound / outbound mail through a gateway running postfix / sendmail etc.
> 
> --srs
> 
> 

opendkim[0] does this job beautifully.

[0] - http://www.opendkim.org/

-- 
staticsafe

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Keegan Holley]

+1 in my experience uRPF get’s enabled, breaks something or causes confusion 
(usually related to multi-homing) and then get’s disabled.

On Feb 28, 2014, at 11:49 AM, Christopher Morrow  
wrote:

> On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy  wrote:
>> If you have uRPF enabled on all your access routers then you can
>> configure routing policy such that advertising a route for a specific
>> host system will trigger uRPF to drop the traffic at the first hop, in
>> hardware.
> 
> note that 'in hardware' is dependent upon the model used...
> note that stuffing 2k (or 5 or 10 or...) extra routes into your edge
> device could make it super unhappy.
> 
> your points are valid for your designed network... they may not work 
> everywhere.
> making the features you point out work better or be more widely known
> seems like a great idea though :)

Re: Are DomainKeys for e-mail signing dead?

[Elizabeth Zwicky]

5.7.4 means "you told us not to accept your mail unless it was validly
signed and it is not".
The solution for this is to make sure that mail with a From: in a domain
that requires this is validly signed.
Yahoo does not care whether you use DKIM or DomainKeys for this purpose;
other people may well like DKIM better, making it more fun.
I note that the help page you reference mentions DKIM and DomainKeys
together every time.

If your LISTSERV
-- gets mail from somebody with a domain that requires their mail to be
validly signed (for instance, via DMARC)
-- leaves that sender's address in the From: line
-- and breaks the DKIM signature

then the mail will not deliver to recipients at Yahoo. Your choices are:
-- ask (or force) the sender to join the LISTSERV from a sending domain
that does not do this
-- modify the From: to not be in the sender's domain
-- avoid breaking the DKIM signature
-- let the mail fail

Elizabeth


On 2/28/14 2:51 PM, "Matthew Black"  wrote:

>Apologies if I slept through prior discussions on the topic.
>
>
>
>E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the
>following error:
>
>
>
>#@YAHOO.COM
>
>Last error: 5.7.9 554 5.7.9 Message not accepted for policy reasons.
>See http://postmaster.yahoo.com/errors/postmaster-28.html
>
>
>
>I note:
>
>
>
>1.   The e-mail error (5.7.9) references the link
>http://postmaster.yahoo.com/errors/postmaster-28.html.
>
>2.   That Yahoo page does not mention error 5.7.9, but references a
>similar error 5.7.4 "Message not accepted for policy reasons."
>
>3.   It appears that Yahoo wants inbound messages signed using
>DomainKeys technology.
>
>4.   Yahoo is the lead inventor of DomainKeys, along with Cicso, PGP,
>and Sendmail.
>
>5.   L-Soft LISTSERV manuals and Yahoo both refer to the website
>http://domainkeys.sourceforge.net/.
>
>6.   When I click on the Documentation and DomainKeys Implementors
>Mailing List links on that page, I get page not found.
>
>7.   A 2007 USA Today Article
>(http://usatoday30.usatoday.com/tech/products/cnet/2007-05-23-domainkeys-a
>nti-spam_N.htm) mentions that DomainKeys have not been widely adopted.
>
>8.   A basic Google search for DomainKeys comes up with no recent
>articles. One website
>(http://blog.wordtothewise.com/2011/09/dkim-is-done/) says that
>DKIM/DomainKeys are dead.
>
>
>
>
>
>Are the rumors of the death of DomainKeys premature? If not, is anyone
>from Yahoo listening?
>
>
>
>matthew black
>
>california state university, long beach
>
>
>
>

IANA AS Numbers registry update

[Selina Harrington]

The IANA AS Numbers registry has been updated to reflect the allocation of 2 
blocks to the RIPE NCC in 2014-02-28:

200192-201215
201216-202239

You can find the IANA AS Numbers registry at:

http://www.iana.org/assignments/as-numbers/as-numbers.xml

Regards,

Selina Harrington

***
Internet Assigned Numbers Authority (IANA)
Internet Corporation for Assigned Names & Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
Phone: +1 310 301 5800
Fax: +1-310-823-8649
***

Re: Are DomainKeys for e-mail signing dead?

[John Levine]

In article 
 you 
write:
>Apologies if I slept through prior discussions on the topic.

Regardless of what various aging web pages and un-upgraded mail
software might say, Domainkeys is as dead as a doornail, even at
Yahoo.  Use DKIM, you'll be happier, even at Yahoo.

R's,
John

Re: Are DomainKeys for e-mail signing dead?

[Suresh Ramasubramanian]

On Saturday, March 1, 2014, Matthew Black  wrote:

> Apologies if I slept through prior discussions on the topic.
> E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the
> following error:


Alive and well after the standard evolved.  Google DKIM and then DMARC.

I doubt anything as antique as listserv supports either, so route its
inbound / outbound mail through a gateway running postfix / sendmail etc.

--srs


-- 
--srs (iPad)

Are DomainKeys for e-mail signing dead?

[Matthew Black]

Apologies if I slept through prior discussions on the topic.



E-mail from our L-Soft LISTSERV was recently rejected by Yahoo with the 
following error:



#@YAHOO.COM

Last error: 5.7.9 554 5.7.9 Message not accepted for policy reasons. See 
http://postmaster.yahoo.com/errors/postmaster-28.html



I note:



1.   The e-mail error (5.7.9) references the link  
http://postmaster.yahoo.com/errors/postmaster-28.html.

2.   That Yahoo page does not mention error 5.7.9, but references a similar 
error 5.7.4 "Message not accepted for policy reasons."

3.   It appears that Yahoo wants inbound messages signed using DomainKeys 
technology.

4.   Yahoo is the lead inventor of DomainKeys, along with Cicso, PGP, and 
Sendmail.

5.   L-Soft LISTSERV manuals and Yahoo both refer to the website 
http://domainkeys.sourceforge.net/.

6.   When I click on the Documentation and DomainKeys Implementors Mailing 
List links on that page, I get page not found.

7.   A 2007 USA Today Article 
(http://usatoday30.usatoday.com/tech/products/cnet/2007-05-23-domainkeys-anti-spam_N.htm)
 mentions that DomainKeys have not been widely adopted.

8.   A basic Google search for DomainKeys comes up with no recent articles. 
One website (http://blog.wordtothewise.com/2011/09/dkim-is-done/) says that 
DKIM/DomainKeys are dead.





Are the rumors of the death of DomainKeys premature? If not, is anyone from 
Yahoo listening?



matthew black

california state university, long beach

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 20-Feb-14 -to- 27-Feb-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS982941608  1.8%  41.4 -- BSNL-NIB National Internet 
Backbone
 2 - AS840234531  1.5%  39.3 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS28573   25671  1.1%  14.0 -- NET Serviços de Comunicação S.A.
 4 - AS755223689  1.0%  18.6 -- VIETEL-AS-AP Viettel Corporation
 5 - AS453823548  1.0%  42.4 -- ERX-CERNET-BKB China Education 
and Research Network Center
 6 - AS10620   23159  1.0%   9.1 -- Telmex Colombia S.A.
 7 - AS60349   22167  1.0% 335.9 -- PBL-KIEV-AS Partners. Business 
& Law Ltd.
 8 - AS13118   20859  0.9% 496.6 -- ASN-YARTELECOM OJSC Rostelecom
 9 - AS45169   19710  0.9%1314.0 -- GLOBAL-DESCON-AS-AP Descon 
Limited
10 - AS41691   19286  0.8% 964.3 -- SUMTEL-AS-RIPE Summa Telecom LLC
11 - AS477519115  0.8% 490.1 -- GLOBE-TELECOM-AS Globe Telecoms
12 - AS29571   16738  0.7%  91.5 -- CITelecom-AS
13 - AS11976   15440  0.7%1403.6 -- FIDN - Fidelity Communication 
International Inc.
14 - AS815114745  0.6%  14.1 -- Uninet S.A. de C.V.
15 - AS17974   14283  0.6%   5.2 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
16 - AS36998   13986  0.6%   8.6 -- SDN-MOBITEL
17 - AS50710   13831  0.6%  61.5 -- EARTHLINK-AS EarthLink Ltd. 
Communications&Internet Services
18 - AS28024   13013  0.6%  41.6 -- Nuevatel PCS de Bolivia S.A.
19 - AS23893   12031  0.5% 308.5 -- BPL-BD House No:03, Road no: 
23/A
20 - AS27738   12012  0.5%  20.8 -- Ecuadortelecom S.A.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS6459 7758  0.3%7758.0 -- TRANSBEAM - I-2000, Inc.
 2 - AS6629 8669  0.4%4334.5 -- NOAA-AS - NOAA
 3 - AS165613354  0.1%3354.0 -- ARIBANETWORK Ariba Inc. 
Autonomous System
 4 - AS395752583  0.1%2583.0 -- SIBINTEK-SAMARA-AS Siberian 
Internet Company
 5 - AS544657439  0.3%2479.7 -- QPM-AS-1 - QuickPlay Media Inc.
 6 - AS2899 2169  0.1%2169.0 -- SPRO-NET - SOLUTION PRO
 7 - AS14287   10364  0.5%1727.3 -- TRIAD-TELECOM - Triad Telecom, 
Inc.
 8 - AS11976   15440  0.7%1403.6 -- FIDN - Fidelity Communication 
International Inc.
 9 - AS45169   19710  0.9%1314.0 -- GLOBAL-DESCON-AS-AP Descon 
Limited
10 - AS564881075  0.1%1075.0 -- E-GROUP-AS OOO E-GROUP
11 - AS41691   19286  0.8% 964.3 -- SUMTEL-AS-RIPE Summa Telecom LLC
12 - AS62431 816  0.0% 816.0 -- NCSC-IE-AS National Cyber 
Security Centre
13 - AS11054   11515  0.5% 719.7 -- LIVEPERSON LivePerson, Inc
14 - AS249331371  0.1% 685.5 -- MINXS-AS MILLENNIUMS.NET GmbH
15 - AS22688 644  0.0% 644.0 -- DOLGENCORP - Dollar General 
Corporation
16 - AS603451204  0.1% 602.0 -- NBITI-AS Nahjol Balagheh 
International Research Institution
17 - AS37367 582  0.0% 582.0 -- CALLKEY
18 - AS52069 581  0.0% 581.0 -- VCT-AS Vladivostok Container 
Terminal Ltd.
19 - AS498472839  0.1% 567.8 -- RAYAZMA-AS Pardazeshgar Rayazma 
Ltd.
20 - AS114863371  0.1% 561.8 -- COLO-PREM-VZB - Verizon Online 
LLC


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 109.161.64.0/20   20547  0.8%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 89.221.206.0/24   19175  0.8%   AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC
 5 - 192.58.232.0/248667  0.3%   AS6629  -- NOAA-AS - NOAA
 6 - 67.210.190.0/238261  0.3%   AS11976 -- FIDN - Fidelity Communication 
International Inc.
 7 - 205.247.12.0/247758  0.3%   AS6459  -- TRANSBEAM - I-2000, Inc.
 8 - 206.152.15.0/247437  0.3%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
 9 - 67.210.188.0/237166  0.3%   AS11976 -- FIDN - Fidelity Communication 
International Inc.
10 - 78.109.192.0/207011  0.3%   AS25184 -- AFRANET AFRANET Co. Tehran, Iran
11 - 103.11.61.0/24 6741  0.3%   AS9387  -- AUGERE-PK AUGERE-Pakistan
12 - 216.109.107.0/24   6707  0.3%   AS11486 -- COLO-PREM-VZB - Verizon Online 
LLC
 AS16561 -- ARIBANETWORK Ariba Inc. 
Autonomous System
13 - 200.23.126.0/246339  0.3%   AS8151  -- Uninet S.A. de C.V.
14 - 199.187.118.0/24   5361  0.2%   AS11054 -- LIVEPERSON LivePerson, Inc
15 - 113.11.132.0/244538  0.2%   AS17658 -- PRIMANET-AS PrimaNet - PT. 
Khasanah Timur Indonesia
16 - 216.57.5.0/24  4263  0.2%   AS12006 -- BROADVIEWNET-AS-12006 - 
Broadview Networks, Inc.
17 - 69.38.178.0/24 3898  0.2%   AS19406 -- TWRS-MA - Towerstream I, Inc.
18 

The Cidr Report

[cidr-report]

This report has been generated at Fri Feb 28 21:13:43 2014 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/2.0 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
21-02-14490117  276717
22-02-14490278  276399
23-02-14490404  276168
24-02-14490498  276712
25-02-14491489  276513
26-02-14491118  276545
27-02-14491390  276447
28-02-14491597  276393


AS Summary
 46405  Number of ASes in routing system
 19025  Number of ASes announcing only one prefix
  3500  Largest number of prefixes announced by an AS
AS28573: NET Serviços de Comunicação S.A.
  119657728  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').

 --- 28Feb14 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 491516   276325   21519143.8%   All ASes

AS28573 3500  108 339296.9%   NET Serviços de Comunicação
   S.A.
AS6389  3021   56 296598.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS17974 2755  190 256593.1%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS4766  2988  904 208469.7%   KIXS-AS-KR Korea Telecom
AS18881 1907   25 188298.7%   Global Village Telecom
AS1785  2164  411 175381.0%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS10620 2772 1200 157256.7%   Telmex Colombia S.A.
AS36998 1638   99 153994.0%   SDN-MOBITEL
AS18566 2048  565 148372.4%   MEGAPATH5-US - MegaPath
   Corporation
AS4323  2932 1513 141948.4%   TWTC - tw telecom holdings,
   inc.
AS7303  1751  450 130174.3%   Telecom Argentina S.A.
AS4755  1839  624 121566.1%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS7545  2189 1037 115252.6%   TPG-INTERNET-AP TPG Telecom
   Limited
AS7552  1260  158 110287.5%   VIETEL-AS-AP Viettel
   Corporation
AS22561 1287  227 106082.4%   AS22561 - CenturyTel Internet
   Holdings, Inc.
AS9829  1593  663  93058.4%   BSNL-NIB National Internet
   Backbone
AS22773 2324 1394  93040.0%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS4808  1181  398  78366.3%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS35908  871  104  76788.1%   VPLSNET - Krypt Technologies
AS18101  917  163  75482.2%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS24560 1108  375  73366.2%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS701   1492  763  72948.9%   UUNET - MCI Communications
   Services, Inc. d/b/a Verizon
   Business
AS4788   978  259  71973.5%   TMNET-AS-AP TM Net, Internet
   Service Provider
AS6983  1301  582  71955.3%   ITCDELTA - ITC^Deltacom
AS8151  1384  666  71851.9%   Uninet S.A. de C.V.
AS7738   846  148  69882.5%   Telemar Norte Leste S.A.
AS855754   57  69792.4%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS4780  1028  361  66764.9%   SEEDNET Digital United Inc.
AS9808   941  286  65569.6%   CMNET-GD Guangdong Mobile
   Communication Co.Ltd.
AS6147   

Any experience with Comcast digital voice for OOB (offlist is fine)

[eric-list]

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300
F: 610-429-3222

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 01 Mar, 2014

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

Analysis Summary


BGP routing table entries examined:  484203
Prefixes after maximum aggregation:  191504
Deaggregation factor:  2.53
Unique aggregates announced to Internet: 239504
Total ASes present in the Internet Routing Table: 46226
Prefixes per ASN: 10.47
Origin-only ASes present in the Internet Routing Table:   35597
Origin ASes announcing only one prefix:   16401
Transit ASes present in the Internet Routing Table:6037
Transit-only ASes present in the Internet Routing Table:168
Average AS path length visible in the Internet Routing Table:   4.6
Max AS path length visible:  53
Max AS path prepend of ASN ( 50404)  51
Prefixes from unregistered ASNs in the Routing Table:  1858
Unregistered ASNs in the Routing Table: 487
Number of 32-bit ASNs allocated by the RIRs:   6020
Number of 32-bit ASNs visible in the Routing Table:4592
Prefixes from 32-bit ASNs in the Routing Table:   14841
Number of bogon 32-bit ASNs visible in the Routing Table: 4
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:397
Number of addresses announced to Internet:   2656597764
Equivalent to 158 /8s, 88 /16s and 119 /24s
Percentage of available address space announced:   71.8
Percentage of allocated address space announced:   71.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   95.8
Total number of prefixes smaller than registry allocations:  169116

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   114986
Total APNIC prefixes after maximum aggregation:   34485
APNIC Deaggregation factor:3.33
Prefixes being announced from the APNIC address blocks:  117592
Unique aggregates announced from the APNIC address blocks:49413
APNIC Region origin ASes present in the Internet Routing Table:4895
APNIC Prefixes per ASN:   24.02
APNIC Region origin ASes announcing only one prefix:   1226
APNIC Region transit ASes present in the Internet Routing Table:855
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:848
Number of APNIC addresses announced to Internet:  731200640
Equivalent to 43 /8s, 149 /16s and 60 /24s
Percentage of available APNIC address space announced: 85.5

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-63999, 131072-133631
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, 150/8, 153/8,
   163/8, 171/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:165723
Total ARIN prefixes after maximum aggregation:82909
ARIN Deaggregation factor: 2.00
Prefixes being announced from the ARIN address blocks:   167138
Unique aggregates announced from the ARIN address blocks: 77636
ARIN Region origin ASes present in the Internet Routing Table:16149
ARIN Prefixes per ASN:  

Re: Peering issue - Possible Juniper to Cisco issue

[Michael Loftis]

On Fri, Feb 28, 2014 at 8:58 AM, Philip Lavine  wrote:
> To all,
>
> I (ASR1001) had an experience recently where the Telco (Juniper) told me that 
> I was sending them 1000+ routes when I attempted to re-establish a BGP 
> session; subsequently they would not allow this and they refused the session.
>
> I had no sync on and a prefix list so I was advertising only one route. Even 
> though I hard reset the session on my end the Telco for some reason kept 
> seeing me send the routes. I finally called them and had them reset their end 
> and the session came up right away.
>
> What the ...

If you leaked once and they have a teardown setup on the Juniper end
w/o a timeout, it won't let the neighbor reconnect until the session
is cleared.  I've seen in IOS 15.x just a few days ago where it had
stuck advertising routes that it shouldn't be, though that was between
two Sup720 based pieces of gear, so probably unrelated (just a data
point that it can/does happen in IOS in general where it's advertising
routes that it insists it isn't)


>
> thx
>
> Philip
>



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: Peering issue - Possible Juniper to Cisco issue

[Simon Lockhart]

On Fri Feb 28, 2014 at 08:58:02AM -0800, Philip Lavine wrote:
> I had no sync on and a prefix list so I was advertising only one route. Even
> though I hard reset the session on my end the Telco for some reason kept
> seeing me send the routes. I finally called them and had them reset their end
> and the session came up right away.

This sounds like you tripped a Max-Prefix limit by advertising too many 
prefixes at some point (maybe when you first configured the session, when
it's easy for the session to come up before you've configured the prefix list).

Once you've tripped Max-Prefix, you won't be able to establish a new connection
to them until they reset their end.

Simon

Re: Filter on IXP

[Jérôme Nicolle]

Le 28/02/2014 17:52, Nick Hilliard a écrit :
> this will break horribly as soon as you have an IXP member which provides
> transit to other multihomed networks.

It could break if filters are based on announced prefixes. That's
preciselly why uRPF is often useless.

On the other hand, if a member provides transit, he will add its
customer prefixes to RaDB / RIPEdb with appropriate route objects and
the ACL will be updated accordingly. Shouldn't break there.

-- 
Jérôme Nicolle
+33 6 19 31 27 14

Peering issue - Possible Juniper to Cisco issue

[Philip Lavine]

To all,

I (ASR1001) had an experience recently where the Telco (Juniper) told me that I 
was sending them 1000+ routes when I attempted to re-establish a BGP session; 
subsequently they would not allow this and they refused the session.

I had no sync on and a prefix list so I was advertising only one route. Even 
though I hard reset the session on my end the Telco for some reason kept seeing 
me send the routes. I finally called them and had them reset their end and the 
session came up right away.

What the ...

thx

Philip

Re: Filter on IXP

[Patrick W. Gilmore]

On Feb 28, 2014, at 11:52 , Nick Hilliard  wrote:
> On 28/02/2014 15:42, Jérôme Nicolle wrote:

>> Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's
>> received routes to ingress _and_ egress ACLs on IXP ports would mitigate
>> the role of BCP38 offenders within member ports. It's almost like uRPF
>> in an intelligent and useable form.
> 
> this will break horribly as soon as you have an IXP member which provides
> transit to other multihomed networks.

Or to anyone who doesn't announce their full downstream table to the route 
servers. Or to people who don't use route servers. Or to someone who does 
traffic engineering. Or 

-- 
TTFN,
patrick

Re: Filter on IXP

[Nick Hilliard]

On 28/02/2014 15:42, Jérôme Nicolle wrote:
> Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's
> received routes to ingress _and_ egress ACLs on IXP ports would mitigate
> the role of BCP38 offenders within member ports. It's almost like uRPF
> in an intelligent and useable form.

this will break horribly as soon as you have an IXP member which provides
transit to other multihomed networks.

Nick

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Christopher Morrow]

On Fri, Feb 28, 2014 at 9:02 AM, Ray Soucy  wrote:
> If you have uRPF enabled on all your access routers then you can
> configure routing policy such that advertising a route for a specific
> host system will trigger uRPF to drop the traffic at the first hop, in
> hardware.

note that 'in hardware' is dependent upon the model used...
note that stuffing 2k (or 5 or 10 or...) extra routes into your edge
device could make it super unhappy.

your points are valid for your designed network... they may not work everywhere.
making the features you point out work better or be more widely known
seems like a great idea though :)

Re: Filter NTP traffic by packet size?

[Niels Bakker]

is there any modern utility in chargen?
Who knows, when CGNs become commonplace we'll start to run out of 
ephemeral ports and we'll have to start using ports < 1024 too. 
Would be a shame if their use were impeded by old ACLs lying 
around.


* ra...@psg.com (Randy Bush) [Fri 28 Feb 2014, 17:23 CET]:
woah!  i did not suggest acls.  i was assuming that one just 
disables the 'service'.


Oh, I'm sorry!  I honestly thought this thread was about filtering 
as a way of mitigating abuse.


Yes, of course one should not run the service, especially not UDP.


-- Niels.

Re: Filter on IXP

[Jérôme Nicolle]

Hi Randy,

Le 28/02/2014 17:15, Randy Bush a écrit :
> clearly you have not been reading this list for very long

Well... Busted. All things considered, there surelly has been more
stupid proposals.

-- 
Jérôme Nicolle
+33 6 19 31 27 14

Re: Filter on IXP

[Jérôme Nicolle]

Le 28/02/2014 17:00, Jay Ashworth a écrit :
>> From: "Jérôme Nicolle" 
>> Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's
>> received routes to ingress _and_ egress ACLs on IXP ports would mitigate
>> the role of BCP38 offenders within member ports. It's almost like uRPF
>> in an intelligent and useable form.
> 
> Interesting.  Are you doing this?  Planning it?  Or at least researching
> how well it would work?

Juste seriously considering it on TOUIX. I'd propose it to Lyonix and
France-IX too.

>> A noticeable side-effect is that members would be encouraged to announce
>> their entire customer-cones to ensure egress trafic from a non-exchanged
>> prefix would not be dropped on the IX's port.
> 
> Don't they do this already?

Not to my knowledge. Some members are only announcing regional prefixes
on smaller IXs. They could however exchange trafic originaing from any
region of their networks.

Best would be to differentiate announced prefixes from legitimately
announcable prefixes, as registered to RIPEdb (as far as we're concerned).

In a more global perspective, the extended best-practice could be to set
ACLs as we generate prefix-lists, route-maps and route-filters for BGP
downlinks and PNIs too.

> If you get something practical implemented on this topic, we'd be more
> than pleased to see it show up on bcp38.info; exchange points are the
> one major construct I hadn't included there, cause I didn't think it was
> actually practical to do it there.  But then, I don't run one.

I think the idea worth investigating, but I run a very small IXP and
will most certainly be unable to fully investigate every potential
side-effects on my own. I'll be reaching out to bigger ones in my next
email.

-- 
Jérôme Nicolle
+33 6 19 31 27 14

Re: Filter NTP traffic by packet size?

[Randy Bush]

>> is there any modern utility in chargen?
> Who knows, when CGNs become commonplace we'll start to run out of 
> ephemeral ports and we'll have to start using ports < 1024 too.  
> Would be a shame if their use were impeded by old ACLs lying around.

woah!  i did not suggest acls.  i was assuming that one just disables
the 'service'.

randy

Re: Filter on IXP

[Randy Bush]

>> It would be really cool if peering exchanges could police ntp on
>> their connected members.
> Well, THIS looks like the worst idea ever.

while i agree that this is an extremely stupid idea, clearly you have
not been reading this list for very long

randy

Re: Managing IOS Configuration Snippets

[Erik Muller]

On 2/28/14, 10:24 , Leo Bicknell wrote:

What I have always wanted is a way to group configuration, in particular by 
customer.  Ideally with the ability to see it both as a unified view, and also 
as a per-customer view.

For instance:

customer A
   interface GigabitEthernet1/2/3.10
 description A
 ip address 10.0.1.1 255.255.255.0
   router bgp 1
 neighbor 10.0.1.2 prefix-list A-in in
   ip prefix-list A-in 10.1.0.0/24
end

...


Basically this follows the two modes in which engineers look at a device.  Most of the time is 
configuring a specific customer, and wanting to be sure they are configured right; including the 
hard case of "no customer A", that is making sure all configuration for a specific 
customer is removed.  The rest of the time is typically troubleshooting a network level problem 
where you want the device view we have today, I see interface Gig1/2/3 is dropping packets, 
"show run" to see who's configure on it sort of operations.

I don't know of any platform that has implemented this sort of config framework 
though.


It's not the cleanest, but in junos you can pretty much get this by 
defining a configuration group per customer and applying them all.  Your RE 
may hate you at commit time, but I've seen this approach work quite well.


-e

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Jay Ashworth]

- Original Message -
> From: "Ray Soucy" 

> When I was looking at the website before I didn't really see any
> mention of uRPF, just the use of ACLs, maybe I missed it, but it's not
> encouraging if I can't spot it quickly. I just tried a search and the
> only thing that popped up was a how-to for a Cisco 7600 VXR.

Well, I do mention it, right there on the home page:

"""
BCP38 filtering to block these packets is most easily handled right at the very 
edge of the Internet: where customer links terminate in the first piece of 
provider 'aggregation' gear, like a router, DSLAM, or CMTS. Much to most of 
this gear already has a 'knob' which can be turned on, which simply drops these 
packets on the floor as they come in from the customer's PC. 
"""

I simply didn't *name* the knob, cause the detail seemed out-of-scope for 
that context.  Where it would get named would be on the "information for 
Audience" pages relevant to access providers, which I have not written 
because -- not being a provider -- I have insufficient background to be
accurate.

We welcome contributions from people in those positions... you, perhaps?

Be bold!  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Filter NTP traffic by packet size?

[Niels Bakker]

* ra...@psg.com (Randy Bush) [Thu 27 Feb 2014, 06:10 CET]:

is there any modern utility in chargen?


No.  But as we're not Apple, we don't get to decide what's good for 
the end user.


Who knows, when CGNs become commonplace we'll start to run out of 
ephemeral ports and we'll have to start using ports < 1024 too.  
Would be a shame if their use were impeded by old ACLs lying around.



-- Niels.

--
"It's amazing what people will do to get their name on the internet, 
 which is odd, because all you really need is a Blogspot account."

-- roy edroso, alicublog.blogspot.com

Re: Filter on IXP

[Jay Ashworth]

- Original Message -
> From: "Jérôme Nicolle" 

> Le 23/02/2014 01:43, Chris Laffin a écrit :
> > It would be really cool if peering exchanges could police ntp on
> > their connected members.
> 
> Well, THIS looks like the worst idea ever. Wasting ASIC ressources on
> IXP's dataplanes is a wet-dream for anyone willing to kill the network.
> IXP's neutrality is a key factor to maintain reasonable interconnexion
> density.
> 
> Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's
> received routes to ingress _and_ egress ACLs on IXP ports would mitigate
> the role of BCP38 offenders within member ports. It's almost like uRPF
> in an intelligent and useable form.

Interesting.  Are you doing this?  Planning it?  Or at least researching
how well it would work?

> A noticeable side-effect is that members would be encouraged to announce
> their entire customer-cones to ensure egress trafic from a non-exchanged
> prefix would not be dropped on the IX's port.

Don't they do this already?

If you get something practical implemented on this topic, we'd be more
than pleased to see it show up on bcp38.info; exchange points are the
one major construct I hadn't included there, cause I didn't think it was
actually practical to do it there.  But then, I don't run one.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Filter NTP traffic by packet size?

[Jérôme Nicolle]

Hi Royce,

Le 23/02/2014 20:48, Royce Williams a écrit :
> Newb question ... other than retrofitting, what stands in the way of
> making BCP38 a condition of peering?

Good point ! And simple answer : most peers wouldn't support the hassle
yet, thus reducing peering density and interest.

I operate a small IXP in southern France and none of my members is
currently BCP38 compliant. Of 16 members only one is known to work on
the issue.

Funny thing beeing that most active members are also switching to
Juniper routers and all had been contributing as NTP reflectors because
of JunOS bugs.

I'd rather consider implementing ACLs on member ports to filter-out
illegitimate prefixes (cannot do OpenFlow on cheap L2 switches :( )
rather than making BCP38 compliance mandatory.

Best regards,
-- 
Jérôme Nicolle
+33 6 19 31 27 14

Re: Filter on IXP

[Jérôme Nicolle]

Hi Chris,

Le 23/02/2014 01:43, Chris Laffin a écrit :
> It would be really cool if peering exchanges could police ntp on their 
> connected members.

Well, THIS looks like the worst idea ever. Wasting ASIC ressources on
IXP's dataplanes is a wet-dream for anyone willing to kill the network.
IXP's neutrality is a key factor to maintain reasonable interconnexion
density.

Instead, IXPs _could_ enforce BCP38 too. Mapping the route-server's
received routes to ingress _and_ egress ACLs on IXP ports would mitigate
the role of BCP38 offenders within member ports. It's almost like uRPF
in an intelligent and useable form.

A noticeable side-effect is that members would be encouraged to announce
their entire customer-cones to ensure egress trafic from a non-exchanged
prefix would not be dropped on the IX's port.

By the way, would anyone know how to generate OpenFlow messages to push
such filters to member ports ? Would there be any smat way to do that on
non-OpenFlow enabled dataplanes (C6k...) ?

Best regards,

-- 
Jérôme Nicolle
+33 6 19 31 27 14

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Ray Soucy]

When I was looking at the website before I didn't really see any
mention of uRPF, just the use of ACLs, maybe I missed it, but it's not
encouraging if I can't spot it quickly.  I just tried a search and the
only thing that popped up was a how-to for a Cisco 7600 VXR.

http://www.bcp38.info/index.php/HOWTO:CISCO:7200VXR

On Fri, Feb 28, 2014 at 9:04 AM, Jay Ashworth  wrote:
> You mean, like Bcp38(.info)?
>
>
> On February 28, 2014 9:02:03 AM EST, Ray Soucy  wrote:
>>
>> I'm wondering how many operators don't have systems in place to
>> quickly and efficiently filter problem host systems.
>> I see a lot of talk of ACL usage, but not much about uRPF and black
>> hole filtering.
>>
>> There are a few white papers that are worth a read:
>>
>>
>> http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf
>>
>> http://www.cisco.com/web/about/security/intelligence/urpf.pdf
>>
>> If you have uRPF enabled on all your access routers then you can
>> configure routing policy such that advertising a route for a specific
>> host system will trigger uRPF to drop the traffic at the first hop, in
>> hardware.
>> This prevents you from having to maintain ACLs or even give out access
>> to routers.  Instead, you can use a small router or daemon that
>> disables hosts by advertising them as a route (for example, we just
>> use a pair of small ISR 1841 routers for this); this in turn can be
>> tied into IPS or a web UI allowing your NOC to disable a problem host
>> at the first hop and prevent its traffic from propagating throughout
>> the network without having to know the overall architecture of the
>> network or determine the best place to apply an ACL.
>>
>> I've seen a lot of talk on trying to filter specific protocols, or
>> rate-limit, etc. but I really feel that isn't the appropriate action
>> to take.  I think disabling a system that is a problem and notifying
>> its maintainer that they need to correct the issue is much more
>> sustainable.  There are also limitations on how much can be done
>> through the use of ACLs.  uRPF and black hole routing
>>   scale
>> much
>> better, especially in response to a denial of service attack.
>>
>> When the NTP problems first started popping up, we saw incoming NTP of
>> several Gb, without the ability to quickly identify and filter this
>> traffic a lot of our users would have been dead in the water because
>> the firewalls they use just can't handle that much traffic; our
>> routers, on the other hand, have no problem throwing those packets
>> out.
>>
>> I only comment on this because one of the comments made to me was
>> "Can't we just use a firewall to block it?".  It took me over an hour
>> to explain that the firewalls in use didn't have the capacity to
>> handle this level of traffic -- and when I tried to discuss hardware
>> vs. software filtering, I got a deer-in-the-headlights look. :-)
>>
>>
>> On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley 
>> wrote:
>>>
>>>  It depends on how many customers you have and what sort of contract you
>>> have with them if any.  A significant amount of attack traffic comes from
>>> residential networks where a "one-size-fits-all" policy is definitely best.
>>>
>>>  On Feb 26, 2014, at 4:01 PM, Jay Ashworth  wrote:
>>>
  - Original Message -
>
>  From: "Brandon Galbraith" 


>  On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley 
>  wrote:
>>
>>  More politely stated, it's not the responsibility of the operator to
>>  decide what belongs on the network and what doesn't. Users can run
>> any
>>  services that's not illegal or even reuse ports for other
>>  applications.


>  Blocking chargen at the edge doesn't seem to be outside of the realm
>  of possibilities.


  All of these conversations are variants of "how easy is it to set up a
  default ACL for loops, and then manage exceptions to it?".

  Assuming your gear permits it, I don't personally see all that much
  Bad Actorliness in setting a relatively tight bidirectional ACL for
  Random Edge Customers, and opening up -- either specific ports, or
  just "to a less-/un-filtered ACL" on specific request
  .

  The question is -- as it is with BCP38 -- *can the edge gear handle
 it*?

  And if not: why not?  (Protip: because buyers of that gear aren't
  agitating for it)

  Cheers,
  -- jra
  --
  Jay R. Ashworth  Baylink
 j...@baylink.com
  Designer The Things I Think
 RFC 2100
  Ashworth & Associates   http://www.bcp38.info  2000 Land
 Rover DII
  St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727
 647 1274
>>>
>>>
>>
>>
>>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.



-- 
Ray Patrick Soucy
Network Engineer
University of Maine Syste

Re: Managing IOS Configuration Snippets

[Leo Bicknell]

On Feb 27, 2014, at 7:38 PM, Keegan Holley  wrote:

> Putting aside the fact that snippets aren’t a good way to conceptualize 
> deployed router code, my gut still tells me to question the question here.

What I have always wanted is a way to group configuration, in particular by 
customer.  Ideally with the ability to see it both as a unified view, and also 
as a per-customer view.

For instance:

customer A
  interface GigabitEthernet1/2/3.10
description A
ip address 10.0.1.1 255.255.255.0
  router bgp 1
neighbor 10.0.1.2 prefix-list A-in in
  ip prefix-list A-in 10.1.0.0/24
end

customer B
  interface GigabitEthernet1/2/3.11
description B
ip address 10.0.2.1 255.255.255.0
  router bgp 1
neighbor 10.0.2.2 prefix-list B-in in
  ip prefix-list B-in 10.2.0.0/24
end

Then I should be able to do:

show run - Normal output like we see today, the "device" view.
customer A show run - Same format as I have above, just config relevant to 
customer A.

I can even see extending the tag to work with some other commands:

customer A show int
customer A show bgp ipv4 uni sum
customer A show ip prefix-list

The same functionality would work for snippets:

customer ntp-servers-v1.0
 ntp server 1.2.3.4
 ntp server 1.2.3.5
 ntp server 1.2.3.6
end

Basically this follows the two modes in which engineers look at a device.  Most 
of the time is configuring a specific customer, and wanting to be sure they are 
configured right; including the hard case of "no customer A", that is 
making sure all configuration for a specific customer is removed.  The rest of 
the time is typically troubleshooting a network level problem where you want 
the device view we have today, I see interface Gig1/2/3 is dropping packets, 
"show run" to see who's configure on it sort of operations.

I don't know of any platform that has implemented this sort of config framework 
though.

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







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Managing IOS Configuration Snippets

[Keegan Holley]

On Feb 28, 2014, at 9:11 AM, Ryan Shea  wrote:

> Keegan, don't get me wrong, I am not suggesting that even if version numbers 
> were happily encoded in robust comments that this would be the same as 
> actually digesting the configuration. If the function of checking using 
> 'fancy versioning' is not an operational best practice, what do you suggest 
> (all-knowing/singing/dancing tool which understands the configuration and 
> your intent aside)? You say IF NTP or CPP were configured differently - with 
> a large enough network there will always be configurations which have 
> differences. With that as an operational constant, how do you determine which 
> devices have the latest iteration of your line vty configuration.

That’s what I mean.  The things that lend well to to version tracking don’t 
tend to change much.  How many ways are there to configure VTY lines, or NTP, 
or CPP, or even OSPF and if we’re talking about an access ACL why not just 
audit the configs to make sure that all the entries are there.  Am I really 
going to care that one router has version 1.0 versus another router that has 
version 2.2.12 build9?  It’s not source code..  
> 
> How often will a change not be rolled out to every router. This is again 
> related to the size and churn of the network, but my practical estimation is 
> that once you get into thousands of routers there will almost always be some 
> that get missed.

Again, a router that was missed is a reason for audit and remediation not 
versioning.  If you find a router with config missing does it really matter 
what version it’s on and when that version was valid?  Not in my experience.

> Comprehensive auditing is very important, and arguably more useful than 
> version checking - but it requires that you make knowledgeable and complete 
> assertions. I assert the my snmp config should look like the snmp snippet 
> version 77 is easier to grok than "make sure our community string is not set 
> to public" (and repeat hand-crafted audit logic for every segment of the 
> config).

There may be some differences, but those are normally due to equipment 
lifecycle, mergers/consolidations and such.  It’s easy to refer to something as 
the config for a particular platform or company than a version number.  This 
can be tracked in GIT or SVN.  Even then there will not be constant changes.  
I’d lean towards standardization.  So the equipment that cannot adhere to the 
defined standards probably won’t evolve much on it’s own.
> 
> What if some of the configs don't match the defined versions? This is why it 
> may make sense to break snippets into functional areas. "Just fix it" might 
> be sane for a banner, but squashing an interface mtu change that was put 
> there for a reason could end in tears. I consider this bit out of the scope 
> of the question, but yes it is another important problem.

I wasn’t saying just fix it.  I was saying that router configs don’t lend well 
to versioning.  With software for example, if something is different it might 
be a different version of that application with compatibility issues, 
dependencies, library issues, etc.  When it’s a router config chances are 
someone fat-fingered something.  Most of the time the best thing to do is to 
fix or at least alert on the error, not to record it as a valid config version. 
 Again, this is for things that lend themselves to snippets.  ACL’s, NTP, SNMP, 
CPP, even Spanning-tree.  Not for things like interface IP’s or static routes 
that may be different across different boxes or location.  If you’re referring 
to the latter I may have misunderstood your question..

> 
> 
> On Thu, Feb 27, 2014 at 10:03 PM, Christopher Morrow 
>  wrote:
> On Thu, Feb 27, 2014 at 8:38 PM, Keegan Holley  wrote:
> > Putting aside the fact that snippets aren't a good way to conceptualize 
> > deployed router code, my gut still tells me to question the question here.  
> > The first is does this stuff change often enough to warrant a fancy 
> > versioning solution?  I have yet to see NTP deployed in a different way 
> > than when I first learned to configure it.  Next, when it does change how 
> > often is it not rolled out to every router.  If NTP or CPP or SNMP or some 
> > other administrative option were configured differently across my
> 
> sure, so you're saying that a large bit (maybe) of the router config
> is 'one size fits all' and 'never changes' where 'never' is really
> 'very infrequently'.
> 
> sure, agreed... but there are parts of the config that do change more
> frequently (depending on the network perhaps)... how do you go about
> seeing which version / setup is deployed EXCEPT by building a
> home-grown 'config parser' and seeing that 'what is deployed matches
> mostly what I have in my config store for this
> router/class-of-router/network' ?
> 
> It's a shame that vendors of network equipment don't have to manage
> large networks of their own equipment under constrained opex
> environments (no 

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Jay Ashworth]

You mean, like Bcp38(.info)?

On February 28, 2014 9:02:03 AM EST, Ray Soucy  wrote:
>I'm wondering how many operators don't have systems in place to
>quickly and efficiently filter problem host systems.
>I see a lot of talk of ACL usage, but not much about uRPF and black
>hole filtering.
>
>There are a few white papers that are worth a read:
>
>http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf
>
>http://www.cisco.com/web/about/security/intelligence/urpf.pdf
>
>If you have uRPF enabled on all your access routers then you can
>configure routing policy such that advertising a route for a specific
>host system will trigger uRPF to drop the traffic at the first hop, in
>hardware.
>
>This prevents you from having to maintain ACLs or even give out access
>to routers.  Instead, you can use a small router or daemon that
>disables hosts by advertising them as a route (for example, we just
>use a pair of small ISR 1841 routers for this); this in turn can be
>tied into IPS or a web UI allowing your NOC to disable a problem host
>at the first hop and prevent its traffic from propagating throughout
>the network without having to know the overall architecture of the
>network or determine the best place to apply an ACL.
>
>I've seen a lot of talk on trying to filter specific protocols, or
>rate-limit, etc. but I really feel that isn't the appropriate action
>to take.  I think disabling a system that is a problem and notifying
>its maintainer that they need to correct the issue is much more
>sustainable.  There are also limitations on how much can be done
>through the use of ACLs.  uRPF and black hole routing scale much
>better, especially in response to a denial of service attack.
>
>When the NTP problems first started popping up, we saw incoming NTP of
>several Gb, without the ability to quickly identify and filter this
>traffic a lot of our users would have been dead in the water because
>the firewalls they use just can't handle that much traffic; our
>routers, on the other hand, have no problem throwing those packets
>out.
>
>I only comment on this because one of the comments made to me was
>"Can't we just use a firewall to block it?".  It took me over an hour
>to explain that the firewalls in use didn't have the capacity to
>handle this level of traffic -- and when I tried to discuss hardware
>vs. software filtering, I got a deer-in-the-headlights look. :-)
>
>
>On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley 
>wrote:
>> It depends on how many customers you have and what sort of contract
>you have with them if any.  A significant amount of attack traffic
>comes from residential networks where a "one-size-fits-all" policy is
>definitely best.
>>
>> On Feb 26, 2014, at 4:01 PM, Jay Ashworth  wrote:
>>
>>> - Original Message -
 From: "Brandon Galbraith" 
>>>
 On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley
>
 wrote:
> More politely stated, it's not the responsibility of the operator
>to
> decide what belongs on the network and what doesn't. Users can run
>any
> services that's not illegal or even reuse ports for other
> applications.
>>>
 Blocking chargen at the edge doesn't seem to be outside of the
>realm
 of possibilities.
>>>
>>> All of these conversations are variants of "how easy is it to set up
>a
>>> default ACL for loops, and then manage exceptions to it?".
>>>
>>> Assuming your gear permits it, I don't personally see all that much
>>> Bad Actorliness in setting a relatively tight bidirectional ACL for
>>> Random Edge Customers, and opening up -- either specific ports, or
>>> just "to a less-/un-filtered ACL" on specific request.
>>>
>>> The question is -- as it is with BCP38 -- *can the edge gear handle
>it*?
>>>
>>> And if not: why not?  (Protip: because buyers of that gear aren't
>>> agitating for it)
>>>
>>> Cheers,
>>> -- jra
>>> --
>>> Jay R. Ashworth  Baylink  
>j...@baylink.com
>>> Designer The Things I Think 
> RFC 2100
>>> Ashworth & Associates   http://www.bcp38.info  2000 Land
>Rover DII
>>> St Petersburg FL USA  BCP38: Ask For It By Name!   +1
>727 647 1274
>>>
>>
>>
>
>
>
>-- 
>Ray Patrick Soucy
>Network Engineer
>University of Maine System
>
>T: 207-561-3526
>F: 207-561-3531
>
>MaineREN, Maine's Research and Education Network
>www.maineren.net

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

[Ray Soucy]

I'm wondering how many operators don't have systems in place to
quickly and efficiently filter problem host systems.
I see a lot of talk of ACL usage, but not much about uRPF and black
hole filtering.

There are a few white papers that are worth a read:

http://www.cisco.com/c/dam/en/us/products/collateral/security/ios-network-foundation-protection-nfp/prod_white_paper0900aecd80313fac.pdf

http://www.cisco.com/web/about/security/intelligence/urpf.pdf

If you have uRPF enabled on all your access routers then you can
configure routing policy such that advertising a route for a specific
host system will trigger uRPF to drop the traffic at the first hop, in
hardware.

This prevents you from having to maintain ACLs or even give out access
to routers.  Instead, you can use a small router or daemon that
disables hosts by advertising them as a route (for example, we just
use a pair of small ISR 1841 routers for this); this in turn can be
tied into IPS or a web UI allowing your NOC to disable a problem host
at the first hop and prevent its traffic from propagating throughout
the network without having to know the overall architecture of the
network or determine the best place to apply an ACL.

I've seen a lot of talk on trying to filter specific protocols, or
rate-limit, etc. but I really feel that isn't the appropriate action
to take.  I think disabling a system that is a problem and notifying
its maintainer that they need to correct the issue is much more
sustainable.  There are also limitations on how much can be done
through the use of ACLs.  uRPF and black hole routing scale much
better, especially in response to a denial of service attack.

When the NTP problems first started popping up, we saw incoming NTP of
several Gb, without the ability to quickly identify and filter this
traffic a lot of our users would have been dead in the water because
the firewalls they use just can't handle that much traffic; our
routers, on the other hand, have no problem throwing those packets
out.

I only comment on this because one of the comments made to me was
"Can't we just use a firewall to block it?".  It took me over an hour
to explain that the firewalls in use didn't have the capacity to
handle this level of traffic -- and when I tried to discuss hardware
vs. software filtering, I got a deer-in-the-headlights look. :-)


On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley  wrote:
> It depends on how many customers you have and what sort of contract you have 
> with them if any.  A significant amount of attack traffic comes from 
> residential networks where a "one-size-fits-all" policy is definitely best.
>
> On Feb 26, 2014, at 4:01 PM, Jay Ashworth  wrote:
>
>> - Original Message -
>>> From: "Brandon Galbraith" 
>>
>>> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley 
>>> wrote:
 More politely stated, it's not the responsibility of the operator to
 decide what belongs on the network and what doesn't. Users can run any
 services that's not illegal or even reuse ports for other
 applications.
>>
>>> Blocking chargen at the edge doesn't seem to be outside of the realm
>>> of possibilities.
>>
>> All of these conversations are variants of "how easy is it to set up a
>> default ACL for loops, and then manage exceptions to it?".
>>
>> Assuming your gear permits it, I don't personally see all that much
>> Bad Actorliness in setting a relatively tight bidirectional ACL for
>> Random Edge Customers, and opening up -- either specific ports, or
>> just "to a less-/un-filtered ACL" on specific request.
>>
>> The question is -- as it is with BCP38 -- *can the edge gear handle it*?
>>
>> And if not: why not?  (Protip: because buyers of that gear aren't
>> agitating for it)
>>
>> Cheers,
>> -- jra
>> --
>> Jay R. Ashworth  Baylink   
>> j...@baylink.com
>> Designer The Things I Think   RFC 
>> 2100
>> Ashworth & Associates   http://www.bcp38.info  2000 Land Rover 
>> DII
>> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 
>> 1274
>>
>
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net