Re: We hit half-million: The Cidr Report
Well, I was just a suit drone into one of their 100 little IT firm around the world. The nearest I got to an actual AA associate was during a 1 month project in Chicago (: Wasted my time really... They billed 3 months to their clients, for a project that took 1 month, and I was asked to fill the cubicle for 2 month doing nothing. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 05/01/14 18:43, Owen DeLong wrote: Care to comment on how you feel about the COI that developed between AA Consulting business at Enron and AA auditing Enron? Not asking you to disclose anything confidential, but if you have wisdom to impart about any sort of generic lessons learned, etc. that might be relevant to this discussion, I think that could be useful. Owen On May 1, 2014, at 12:56 PM, Alain Hebert aheb...@pubnix.net wrote: Hey, I worked for them (AA) in the early 90's =D - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 05/01/14 14:07, John Souter wrote: On 01/05/14 17:41, Owen DeLong wrote: The problem with this theory is that if auditors can be so easily put to the street, you run into the risk of auditors altering behavior to increase customer satisfaction in ways that prevent them from providing the controls that are the reason auditors exist in the first place. I disagree. And the power balance is generally tilted way in favour of the auditors, as many people on this thread have already commented. In my experience, most companies are afraid/inhibited to raise issues or challenge their auditors in any way. Nobody is asking auditors to roll over, but if their behaviour is unprofessional/illogical, then a short sharp shock should do the trick. If you don’t believe me, examine the history of Arthur Anderson and their relationship with a certain Houston-based company which failed spectacularly. Can't really comment, but it was financial auditing, and ISTR that many things failed in that situation - not just financial auditing. John
oss netflow collector/trending/analysis
Hey There, I was just wondering, for people who are doing netflow analysis with open source tools and who are doing at least 10k or more flows per second, what are you using? I know of three tool sets: - The classic osu flow-tools and the modern continuation/fork. - ntop - nfdump/nfsen Is there anything else I've missed? A few folks here really seem to like nfsen/nfdump. Thanks, Matt -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 -- “Whatever you do will be insignificant, but it is very important that you do it.” -- Mahatma Gandhi
Re: oss netflow collector/trending/analysis
On May 2, 2014, at 9:36 PM, Matthew Galgoci mgalg...@redhat.com wrote: A few folks here really seem to like nfsen/nfdump. The good thing about nfdump/nfsen is that you can customize it and do a lot with it, and it's easy to get set up and running. This is the canonical list of open-source NetFlow tools: http://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: oss netflow collector/trending/analysis
On 2014-05-02 16:36, Matthew Galgoci wrote: [..] Is there anything else I've missed? A few folks here really seem to like nfsen/nfdump. For OSS that is pretty much it that really matters (maybe you could add Argus if you really want though). For a long long list, check out Simon Leinen's site: https://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html Not all of that is OSS though. Lots of these netflow-analyzer tools are in-house / a bunch-of-scripts-upon-scripts that are to scary to let out in the open and/or do not scale... IMHO your best bet is to use nfsen/nfdump as that is the best thing publicly available. Greets, Jeroen
Re: oss netflow collector/trending/analysis
There's also SiLK from CMU. It's powerful but has a learning curve. I also see pmacct being used both by some end networks and by some vendors as part of systems. Avi Hey There, I was just wondering, for people who are doing netflow analysis with open source tools and who are doing at least 10k or more flows per second, what are you using? I know of three tool sets: - The classic osu flow-tools and the modern continuation/fork. - ntop - nfdump/nfsen Is there anything else I've missed? A few folks here really seem to like nfsen/nfdump. Thanks, Matt
Re: oss netflow collector/trending/analysis
pmacct (http://www.pmacct.net/) is another pretty awesome open source tool. Leslie On Fri, May 2, 2014 at 8:00 AM, Avi Freedman freed...@freedman.net wrote: There's also SiLK from CMU. It's powerful but has a learning curve. I also see pmacct being used both by some end networks and by some vendors as part of systems. Avi Hey There, I was just wondering, for people who are doing netflow analysis with open source tools and who are doing at least 10k or more flows per second, what are you using? I know of three tool sets: - The classic osu flow-tools and the modern continuation/fork. - ntop - nfdump/nfsen Is there anything else I've missed? A few folks here really seem to like nfsen/nfdump. Thanks, Matt
Re: oss netflow collector/trending/analysis
NANOG nanog-bounces+jloiacon=csc@nanog.org wrote on 05/02/2014 11:00:15 AM: From: freed...@freedman.net (Avi Freedman) There's also SiLK from CMU. It's powerful but has a learning curve. SiLK is very good. See FlowViewer for a powerful front-end to the tool. http://sourceforge.net/projects/flowviewer/ Also supports flow-tools. Joe
Weekly Routing Table Report
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 pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 03 May, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 493507 Prefixes after maximum aggregation: 193714 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 244007 Total ASes present in the Internet Routing Table: 46734 Prefixes per ASN: 10.56 Origin-only ASes present in the Internet Routing Table: 35795 Origin ASes announcing only one prefix: 16388 Transit ASes present in the Internet Routing Table:6056 Transit-only ASes present in the Internet Routing Table:170 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: 1837 Unregistered ASNs in the Routing Table: 459 Number of 32-bit ASNs allocated by the RIRs: 6508 Number of 32-bit ASNs visible in the Routing Table:4883 Prefixes from 32-bit ASNs in the Routing Table: 16259 Number of bogon 32-bit ASNs visible in the Routing Table: 133 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:441 Number of addresses announced to Internet: 2678216965 Equivalent to 159 /8s, 162 /16s and 89 /24s Percentage of available address space announced: 72.3 Percentage of allocated address space announced: 72.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.3 Total number of prefixes smaller than registry allocations: 171214 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 117313 Total APNIC prefixes after maximum aggregation: 34942 APNIC Deaggregation factor:3.36 Prefixes being announced from the APNIC address blocks: 120226 Unique aggregates announced from the APNIC address blocks:50108 APNIC Region origin ASes present in the Internet Routing Table:4923 APNIC Prefixes per ASN: 24.42 APNIC Region origin ASes announcing only one prefix: 1231 APNIC Region transit ASes present in the Internet Routing Table:860 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table:931 Number of APNIC addresses announced to Internet: 732419201 Equivalent to 43 /8s, 167 /16s and 212 /24s Percentage of available APNIC address space announced: 85.6 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:168115 Total ARIN prefixes after maximum aggregation:83465 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 169561 Unique aggregates announced from the ARIN address blocks: 79577 ARIN Region origin ASes present in the Internet Routing Table:16243 ARIN
Best practices IPv4/IPv6 BGP (dual stack)
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? Thanks in advance, DJ
Re: Best practices IPv4/IPv6 BGP (dual stack)
On May 2, 2014, at 3:44 PM, Deepak Jain dee...@ai.net wrote: Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? We use v4 transport for v4 routes and v6 transport for v6 routes only. This way if one plane is unstable the other is unaffected. - Jared
Re: Best practices IPv4/IPv6 BGP (dual stack)
Two different sessions using two different transport protocols. The v4 BGP session should have address family v6 disabled and vice versa. Exchange v4 routes over a v4 TCP connection, exchange v6 routes over a v6 TCP connection. Just treat them as independent protocols. -Laszlo On May 2, 2014, at 7:44 PM, Deepak Jain dee...@ai.net wrote: Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? Thanks in advance, DJ
Re: Best practices IPv4/IPv6 BGP (dual stack)
Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? Thanks in advance, DJ For what it’s worth, my AboveNet and Cogent BGP peerings are v4 for v4 routes and v6 for v6 routes. Two separate sessions to each carrier. While I don’t have any BGP speaking IPv6 customers yet, I would set up this same way to keep the two protocols apart from each other. Best, Ryan Wilkins
Re: Best practices IPv4/IPv6 BGP (dual stack)
Subject: Best practices IPv4/IPv6 BGP (dual stack) Date: Fri, May 02, 2014 at 07:44:33PM + Quoting Deepak Jain (dee...@ai.net): Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? Like others, yes, two sessions, v6 over v6 and v4 over v4. only the native AF is active. According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. It works, but might produce interesting side effects. I've had to resort to it when peering between different IOS versions; but that might have been the result of fat-fingering as well. Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? If having MPLS bgp peers over v6 carrying vpnv4 routes all sorts of strange things can happen. There is no standard for it; so one should not expect it to work. But the failure modes are interesting; I've had the next-hop for a v6-carried vpnv4 peering be the first 32 bits of the v6 next-hop, interpreted as a v4 address.. It only works if there is a v4 route to that made-up address. This is a field where v4 next-hops are essential to make things work. rantIn that context, allocating 100.64.0.0/10 to CGN was especially un-clever... /rant -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Xerox your lunch and file it under sex offenders! signature.asc Description: Digital signature
Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]
Hi Mans, On Fri, May 2, 2014 at 2:35 PM, Måns Nilsson mansa...@besserwisser.orgwrote: This is a field where v4 next-hops are essential to make things work. rantIn that context, allocating 100.64.0.0/10 to CGN was especially un-clever... /rant Would you expound a bit on what you mean here? I don't quite follow but I am very interested to understand the issue. Thanks! ~Chris -- @ChrisGrundemann http://chrisgrundemann.com
The Cidr Report
This report has been generated at Fri May 2 21:13:55 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
25-04-14500177 282897
26-04-14500200 282955
27-04-14500300 283004
28-04-14500709 283246
29-04-14501078 282694
30-04-14501121 282538
01-05-14500741 282901
02-05-14500388 283120
AS Summary
46968 Number of ASes in routing system
19152 Number of ASes announcing only one prefix
3690 Largest number of prefixes announced by an AS
AS28573: NET Serviços de Comunicação S.A.,BR
119976960 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
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').
--- 02May14 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 500620 283088 21753243.5% All ASes
AS28573 3690 174 351695.3% NET Serviços de Comunicação
S.A.,BR
AS6389 2970 56 291498.1% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS17974 2800 252 254891.0% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS4766 2947 931 201668.4% KIXS-AS-KR Korea Telecom,KR
AS18881 1967 37 193098.1% Global Village Telecom,BR
AS1785 2201 494 170777.6% AS-PAETEC-NET - PaeTec
Communications, Inc.,US
AS10620 2850 1352 149852.6% Telmex Colombia S.A.,CO
AS18566 2047 565 148272.4% MEGAPATH5-US - MegaPath
Corporation,US
AS4323 2934 1512 142248.5% TWTC - tw telecom holdings,
inc.,US
AS7303 1758 457 130174.0% Telecom Argentina S.A.,AR
AS4755 1852 582 127068.6% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS7545 2232 1070 116252.1% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS7552 1243 142 110188.6% VIETEL-AS-AP Viettel
Corporation,VN
AS22561 1302 241 106181.5% AS22561 - CenturyTel Internet
Holdings, Inc.,US
AS6983 1327 314 101376.3% ITCDELTA - Earthlink, Inc.,US
AS36998 1114 161 95385.5% SDN-MOBITEL,SD
AS9829 1622 726 89655.2% BSNL-NIB National Internet
Backbone,IN
AS22773 2411 1564 84735.1% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS24560 1126 295 83173.8% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services,IN
AS4808 1214 394 82067.5% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network,CN
AS4788 1036 251 78575.8% TMNET-AS-AP TM Net, Internet
Service Provider,MY
AS18101 944 186 75880.3% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI,IN
AS8151 1410 655 75553.5% Uninet S.A. de C.V.,MX
AS701 1482 751 73149.3% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business,US
AS7738 914 184 73079.9% Telemar Norte Leste S.A.,BR
AS26615 842 113 72986.6% Tim Celular S.A.,BR
AS855760 57 70392.5% CANET-ASN-4 - Bell Aliant
Regional Communications,
Inc.,CA
AS6147 785 113 67285.6% Telefonica del Peru S.A.A.,PE
AS4780 1038 370
BGP Update Report
BGP Update Report Interval: 24-Apr-14 -to- 01-May-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS7029 179743 8.1% 788.3 -- WINDSTREAM - Windstream Communications Inc,US 2 - AS982991957 4.1% 69.3 -- BSNL-NIB National Internet Backbone,IN 3 - AS453834300 1.5% 90.5 -- ERX-CERNET-BKB China Education and Research Network Center,CN 4 - AS840229550 1.3% 41.9 -- CORBINA-AS OJSC Vimpelcom,RU 5 - AS29571 24924 1.1% 102.1 -- CITelecom-AS,CI 6 - AS41691 21703 1.0%1085.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 7 - AS23752 21375 1.0% 164.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 8 - AS381620610 0.9% 36.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 9 - AS17557 19397 0.9% 323.3 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 10 - AS14259 15209 0.7% 760.5 -- Gtd Internet S.A.,CL 11 - AS28573 14291 0.6% 9.1 -- NET Serviços de Comunicação S.A.,BR 12 - AS477514187 0.6% 262.7 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - AS671313895 0.6% 25.6 -- IAM-AS,MA 14 - AS10620 12372 0.6% 7.2 -- Telmex Colombia S.A.,CO 15 - AS35567 11996 0.5% 81.1 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 16 - AS347511732 0.5% 120.9 -- DNIC-AS-03475 - Navy Network Information Center (NNIC),US 17 - AS48159 10346 0.5% 46.2 -- TIC-AS Telecommunication Infrastructure Company,IR 18 - AS662910142 0.5% 10142.0 -- NOAA-AS - NOAA,US 19 - AS647 8725 0.4% 74.6 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 20 - AS525928708 0.4%1741.6 -- CELINO RIBEIRO SERVICOS DE TELECOMUNICACOES LTDA -,BR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS662910142 0.5% 10142.0 -- NOAA-AS - NOAA,US 2 - AS181358062 0.4%8062.0 -- BTV BTV Cable television,JP 3 - AS46846 0.3% 824.0 -- ISI-AS - University of Southern California,US 4 - AS346353997 0.2%3997.0 -- LIBERTY-AS Liberty Poland S.A.,PL 5 - AS8039 2532 0.1%2532.0 -- CCC-ASN-1 - Cinergy Communications,US 6 - AS544657083 0.3%2361.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 7 - AS525928708 0.4%1741.6 -- CELINO RIBEIRO SERVICOS DE TELECOMUNICACOES LTDA -,BR 8 - AS31494 0.1%1213.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS31477 0.1%1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 10 - AS336431388 0.1%1388.0 -- JELLYBELLY - Jelly Belly Candy Company,US 11 - AS455901349 0.1%1349.0 -- HGCINTNET-AS-AP Hutch Connect,HK 12 - AS7453 2595 0.1%1297.5 -- ACCELERATION - ACCELERATED DATA WORKS, INC.,US 13 - AS603451282 0.1%1282.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 14 - AS41691 21703 1.0%1085.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 15 - AS37681 972 0.0% 972.0 -- Sunmail-AS,NG 16 - AS350931884 0.1% 942.0 -- RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 17 - AS1358 874 0.0% 874.0 -- HNSNET-AS - Hughes Network Systems, Inc.,US 18 - AS7029 179743 8.1% 788.3 -- WINDSTREAM - Windstream Communications Inc,US 19 - AS591371553 0.1% 776.5 -- IDNIC-KEMHAN-AS-ID PUSDATIN KEMHAN RI,ID 20 - AS14259 15209 0.7% 760.5 -- Gtd Internet S.A.,CL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 21563 0.9% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 121.52.144.0/24 19623 0.8% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 3 - 87.250.97.0/2411199 0.5% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 4 - 192.58.232.0/24 10142 0.4% AS6629 -- NOAA-AS - NOAA,US 5 - 50.96.132.0/24 9207 0.4% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 6 - 205.247.12.0/248276 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 7 - 42.83.48.0/20 8062 0.3% AS18135 -- BTV BTV Cable television,JP 8 - 120.28.62.0/24 7348 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 206.152.15.0/247081 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 10 - 186.237.56.0/226846 0.3% AS4 -- ISI-AS - University of Southern California,US 11 - 222.127.0.0/24 6355
Re: Best practices IPv4/IPv6 BGP (dual stack)
On Fri, May 2, 2014 at 1:47 PM, Jared Mauch ja...@puck.nether.net wrote: On May 2, 2014, at 3:44 PM, Deepak Jain dee...@ai.net wrote: Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? We use v4 transport for v4 routes and v6 transport for v6 routes only. +1 This way if one plane is unstable the other is unaffected. This is the key point I believe: No protocol fate sharing! From the draft BCOP on this topic[1]: 8 Establish new, IPv6-Only peering sessions parallel to existing IPv4 peering. Individual IPv4 and IPv6 BGP peering sessions should be established between all BGP neighbors, particularly eBGP peers. While it is possible to use Multiprotocol BGP (MP-BGP)[2] to carry IPv6 Network Layer Reachability Information (NLRI) over existing (or new) IPv4 BGP peering sessions, this is not recommended. Both BGP sessions MAY use the same logical circuit, or, a new port MAY be used for IPv6 (separate physical or logical connections is NOT a requirement). [removed image] This maintains independent IPv6 and IPv4 topologies, rather than tying the two together unnecessarily. It prevents black holing of IPv6 traffic in the event of a protocol outage because the IPv6 session goes down when IPv6 reachability is lost. When an IPv4 BGP session carries IPv6 NLRI, IPv6 routes are only withdrawn if IPv4 connectivity is lost. Independent BGP sessions also facilitate protocol specific maintenance because the IPv4 and IPv6 sessions don’t affect each other (e.g. IPv6 can be “bounced” without effecting IPv4 and vice verse). Finally, establishing new, IPv6-only peering creates better operational clarity. It allows IPv4 and IPv6 configuration stanzas to be independent and easily recognizable. 8 Cheers, ~Chris [1] - http://bcop.nanog.org/index.php/IPv6_Peering_Transit_BCOP_v0-6 [2] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 4760, January 2007 - Jared -- @ChrisGrundemann http://chrisgrundemann.com
Re: oss netflow collector/trending/analysis
2014-05-02 16:36 GMT+02:00 Matthew Galgoci mgalg...@redhat.com: Hey There, I was just wondering, for people who are doing netflow analysis with open source tools and who are doing at least 10k or more flows per second, what are you using? I know of three tool sets: - The classic osu flow-tools and the modern continuation/fork. - ntop - nfdump/nfsen Is there anything else I've missed? A few folks here really seem to like nfsen/nfdump. Thanks, Matt Hi Matt, I've been using pmacct for quite some time now and I'm more than happy with the results. Being able to store all infos in a *SQL db is a killer feature for me. Also it can speak BGP with your routers so it can grab the AS Path information which allow us for example to make traffic graphs for a destination AS aggregated by AS Path (one of my favorites feature I had with the Arbor peakflow in my previous company). Pierre-Yves
Re: Best practices IPv4/IPv6 BGP (dual stack)
On May 2, 2014, at 12:44 PM, Deepak Jain dee...@ai.net wrote: Between peering routers on a dual-stacked network, is it considered best practices to have two BGP sessions (one for v4 and one for v6) between them? Or is it better to put v4 in the v6 session or v6 in the v4 session? Separate v4 and v6 sessions are the best practice. It is possible to have a single-protocol outage in which case you either take out the other protocol unnecessarily or you black-hole traffic. According to docs, obviously all of these are supported and if both sides are dual stacked, even the next-hops don't need to be overwritten. Mostly true, but implementations vary and YMMV vendor to vendor and in some cases, model and/or software version to model and/or software version. Two sessions always works and unless you are somehow resource-constrained on sessions is really the simplest, easiest to manage, cleanest way to do things. Is there any community-approach to best practices here? Any FIB weirdness (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc) that results with one solution over the other? See above for BCP. As to the rest, in my experience, the answers vary (see above). Owen
CLEC and FTTP H.248/Megaco
I need a sanity check. An incumbent in Canada has revealed that its voice service on FTTP deployments is based on H.248 MEGACO (Media Gateway Controller). Are there any examples of CLEC access to such FTTP deployments ? (for instance, an area where the copper was removed, leaving only fibre to homes, do CLECs retain competitive access via fibre to homes, or is it going out of business or going with pure SIP/VoIP over the regular internet connection, instead of using the quality voice link in the GPON with garanteed bandwidth ? Can this protocol support the programming of one OLT/MG connecting to the Telco's MGC, while the OLT/MG next door connects to the CLEC's MGC ? Or does the protocol result in MG's discovering the nearest MGC and connecting to it (making it hard to have multiple MGCs from competing telcos). I have been lead to believe that most OLTs came with a SIP based ATA. It appears that H.248 is more telco friendly and scales better. Does this mean that H.248 is more widely deployed in FTTH ?
