Re: dealing with bogon spam ?
Yes, unallocated (at least according to ARIN's whois db) but not unannounced - obviously our network can get to the space or else I wouldn't be having a spam problem with them! I'm actually seeing this /20 as advertised through Savvis from AS40430 It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) Has anyone seen an IRR's DB's not being updated for more than 30 days after allocations? I always assumed that they are quickly updated. Thanks again, Leslie Jon Lewis wrote: Unallocated doesn't mean non-routed. All a spammer needs is a willing/non-filtering provider doing BGP with them, and they can announce any space they like, send out some spam, and then pull the announcement. Next morning, when you see the spam and try to figure out who to send complaints to, you're either going to complain to the wrong people or find that whois is of no help. On Tue, 27 Oct 2009, Church, Charles wrote: This is puzzling me. If it's from non-announced space, at some point some router should report no route to it. How is the TCP handshake performed to allow a sync to turn into spam? Chuck Chuck Church Network Planning Engineer, CCIE #8776 Harris Information Technology Services DOD Programs 1210 N. Parker Rd. | Greenville, SC 29609 Office: 864-335-9473 | Cell: 864-266-3978 -- Sent using BlackBerry
Re: dealing with bogon spam ?
Ah, colo4jax I see. Jacksonville, Florida. 68.234.16.0/20 shows up as unallocated but as these guys own the previous /20 its probably a stale arin db and a brand new allocation Prefix AS Path Aggregation Suggestion 68.234.0.0/204777 2497 25973 40430 68.234.16.0/20 4608 1221 4637 3561 40430 69.174.96.0/21 4777 2497 25973 40430 173.205.80.0/20 4777 2497 25973 40430 204.237.184.0/21 4777 2497 25973 40430 204.237.192.0/22 4777 2497 25973 40430 208.153.96.0/22 4777 2497 25973 40430 208.169.228.0/22 4777 2497 25973 40430 On Wed, Oct 28, 2009 at 12:14 PM, Leslie les...@craigslist.org wrote: Yes, unallocated (at least according to ARIN's whois db) but not unannounced - obviously our network can get to the space or else I wouldn't be having a spam problem with them! I'm actually seeing this /20 as advertised through Savvis from AS40430 It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) Has anyone seen an IRR's DB's not being updated for more than 30 days after allocations? I always assumed that they are quickly updated. Thanks again, Leslie Jon Lewis wrote: Unallocated doesn't mean non-routed. All a spammer needs is a willing/non-filtering provider doing BGP with them, and they can announce any space they like, send out some spam, and then pull the announcement. Next morning, when you see the spam and try to figure out who to send complaints to, you're either going to complain to the wrong people or find that whois is of no help. On Tue, 27 Oct 2009, Church, Charles wrote: This is puzzling me. If it's from non-announced space, at some point some router should report no route to it. How is the TCP handshake performed to allow a sync to turn into spam? Chuck Chuck Church Network Planning Engineer, CCIE #8776 Harris Information Technology Services DOD Programs 1210 N. Parker Rd. | Greenville, SC 29609 Office: 864-335-9473 | Cell: 864-266-3978 -- Sent using BlackBerry -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: dealing with bogon spam ?
On Tue, 27 Oct 2009 23:44:40 -0700 Leslie les...@craigslist.org wrote: It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) Has anyone seen an IRR's DB's not being updated for more than 30 days after allocations? I always assumed that they are quickly updated. Note, ARIN is an RIR, a regional internet registry, which is what I presume you meant there. Nevertheless, while it might be worth a try from a research perspective, it may be a bit risky in a production environment. In addition, someone may announce a more specific so keep that scenario in mind. The CIDR Report monitors RIR allocation data. This may be of interest to you: http://www.cidr-report.org/bogons/rir-data.html You can get access to that allocation data as noted here: https://www.arin.net/knowledge/statistics/rir.html John
Re: dealing with bogon spam ?
I would suggest to report that netblock to SpamHaus to have it included at their DROP list, and also use that DROP list as extra filter in addition to your bogon filter setup at your border routers. The SpamHaus DROP (Don't Route Or Peer) list was specially designed for this kind of abuse of stolen 'hijacked' netblocks and netblocks controlled entirely by professional spammers. http://www.spamhaus.org/drop/ With kind regards, Michiel Klaver IT Professional
Re: dealing with bogon spam ?
Leslie wrote: [..] It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) What you want to take is: $rirs = array( afrinic = ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest;, apnic = ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest;, arin = ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest;, lacnic= ftp://ftp.ripe.net/pub/stats/lacnic/delegated-lacnic-latest;, ripe = ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest;, brnic = ftp://ftp.registro.br/pub/stats/delegated-ipv6-nicbr-latest;, Avoid broken/slow servers: afrinic = ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest;, apnic = ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest;, lacnic= ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest;, ); Yes, generally the latter three are broken, but as they are mirrored to RIPE anyway, you can just pull them off there. Then you have all IPv4 and IPv6 delegated blocks. If it is not in there, it is a bogon. Yes, those are updated only once in a day or so, thus if some one is going to start using the block before it is published in those files you will get some false-positives, but then ask the question why they get a block up so quickly and start spamming you in the first place. Those /stats/ dirs contain other useful things btw. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: dealing with bogon spam ?
On Tue, 27 Oct 2009 16:57:17 PDT, Leslie said: We're seeing a decent chunk of spam coming from an unallocated block of address space. Fear not, this will end when we run out of IPv4 space not too many months down the road :) I admit to remaining confused as to why we still keep seeing providers who fail to do basic due-diligence like BCP38 filtering of packets, or asking a new BGP peer what they expect to announce and then filter based on that. I mean, come on guys - sure they may be 6 cents a meg cheaper, but do you really want to buy connectivity from a provider that can't run their network in a proper fashion? Don't answer that. ;) pgp54lYixDdIl.pgp Description: PGP signature
Re: dealing with bogon spam ?
On Oct 28, 2009, at 2:44 AM, Leslie wrote: Yes, unallocated (at least according to ARIN's whois db) but not unannounced - obviously our network can get to the space or else I wouldn't be having a spam problem with them! I'm actually seeing this /20 as advertised through Savvis from AS40430 It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) Has anyone seen an IRR's DB's not being updated for more than 30 days after allocations? I always assumed that they are quickly updated. Thanks again, Leslie You may want to take a look at what is going on in the SIDR working group if you want something similar to this. - Jared
Re: dealing with bogon spam ?
On Oct 28, 2009, at 7:14 AM, valdis.kletni...@vt.edu wrote: On Tue, 27 Oct 2009 16:57:17 PDT, Leslie said: We're seeing a decent chunk of spam coming from an unallocated block of address space. Fear not, this will end when we run out of IPv4 space not too many months down the road :) I admit to remaining confused as to why we still keep seeing providers who fail to do basic due-diligence like BCP38 filtering of packets, or asking a new BGP peer what they expect to announce and then filter based on that. I mean, come on guys - sure they may be 6 cents a meg cheaper, but do you really want to buy connectivity from a provider that can't run their network in a proper fashion? Don't answer that. ;) I can answer the above question regarding BCP38: Vendor software defects and architecture limitations make it challenging to deploy a solution whereby BCP38 can be universally deployed. Customers that are unwilling to announce all their space also make uRPF problematic. I'd like to see 'loose-rpf' universally deployed myself. There is no reason for unrouted space to have packets sourced from it. This makes up a fair percentage of traffic that root/gtld nameservers see (based on conversations i've had with operators over the years). If you configure CPE devices and don't utilize anti-spoofing capabilities on the CPE-Lan, please add that to your templates. It is helpful to the internet as a whole, while you may not personally see return on your investment, others will. - Jared
Re: dealing with bogon spam ?
It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) What you want to take is: $rirs = array( afrinic = ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest;, apnic = ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest;, arin = ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest;, lacnic= ftp://ftp.ripe.net/pub/stats/lacnic/delegated-lacnic-latest;, ripe = ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest;, brnic = ftp://ftp.registro.br/pub/stats/delegated-ipv6-nicbr-latest;, Avoid broken/slow servers: afrinic = ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest;, apnic = ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest;, lacnic= ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest;, ); this is brilliant. maybe we should form an org to do this and distribute via bgp? shall we have a contest for the name of the org? my bid is cymru randy
Redundant Data Center Architectures
I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. I imagine VPLS has a big play here, but I'm willing to bet there are all sorts of weirdness that such environments can create, such as the effect it may have on DR elections, etc. Also, what are your experiences in replication of storage over WAN links? Are people tending towards iSCSI or do trends indicate that FCoE or FCoIP may become the preferred mechanism? Any experience with WAN acceleration in such environments? Thanks in advance! -- Stefan Fouant
Re: dealing with bogon spam ?
Randy Bush wrote: It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) What you want to take is: $rirs = array( afrinic = ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest;, [..] this is brilliant. maybe we should form an org to do this and distribute via bgp? shall we have a contest for the name of the org? my bid is cymru Who have it already indeed for a long long time and have a proven track record. I noted the above for the people who want to get their own copy from the IRRs, like what was asked above. For instance for the few who want to build their own setups, want to integrate it in their own systems etc. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Strip AS in BGP peer
Hello Nanog, am not sure if i should have placed this on the cisco-nsp or the juniper-nsp but someone may have a direct answer. well here it goes. we'll soon form a new internet exchange and i would like to suggest a model in the route-server wherein the route-server would strip out it's own AS and give the neighbors/peers the AS's of the members. I have seen this in Any2IX but i have no idea on how to implement it as if i am the Any2 route-server. if you could point me to the right direction or reading, i could take it from there. -Sherwin
Re: Strip AS in BGP peer
Take a read of the quagga documentation. There's a BGP neighbor option for stripping out the local AS when speaking eBGP. Adrian On Wed, Oct 28, 2009, Sherwin Ang wrote: Hello Nanog, am not sure if i should have placed this on the cisco-nsp or the juniper-nsp but someone may have a direct answer. well here it goes. we'll soon form a new internet exchange and i would like to suggest a model in the route-server wherein the route-server would strip out it's own AS and give the neighbors/peers the AS's of the members. I have seen this in Any2IX but i have no idea on how to implement it as if i am the Any2 route-server. if you could point me to the right direction or reading, i could take it from there.
Re: dealing with bogon spam ?
On 29/10/2009, at 2:52 AM, Jeroen Massar wrote: Randy Bush wrote: It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) What you want to take is: $rirs = array( afrinic = ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest;, [..] this is brilliant. maybe we should form an org to do this and distribute via bgp? shall we have a contest for the name of the org? my bid is cymru Who have it already indeed for a long long time and have a proven track record. I noted the above for the people who want to get their own copy from the IRRs, like what was asked above. For instance for the few who want to build their own setups, want to integrate it in their own systems etc. I can't see anything on their site that provides a BGP feed of prefixes allocated by RIRs, which I think is what we're talking about here. -- Nathan Ward
Re: Redundant Data Center Architectures
We are doing: Citrix XenServer environments at both sites with NetApps for the SANs MPLS connections with Riverbeds for WAN op. Let me know if you wanna dig into this deeper. Stefan Fouant wrote: I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. I imagine VPLS has a big play here, but I'm willing to bet there are all sorts of weirdness that such environments can create, such as the effect it may have on DR elections, etc. Also, what are your experiences in replication of storage over WAN links? Are people tending towards iSCSI or do trends indicate that FCoE or FCoIP may become the preferred mechanism? Any experience with WAN acceleration in such environments? Thanks in advance! -- Stefan Fouant No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 10/28/09 09:34:00
ISP with CSC/CoC?
Hello, I am studying for the CCIE Service Provider and ran across a few CSC/CoC scenarios. I am wondering if any major ISP uses/offers this kind of service? Thanks. - Luan Nguyen Chesapeake NetCraftsmen, LLC. http://www.netcraftsmen.net - __ Information from ESET NOD32 Antivirus, version of virus signature database 4551 (20091028) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: dealing with bogon spam ?
On Thu, 29 Oct 2009 03:24:17 +1300 Nathan Ward na...@daork.net wrote: I can't see anything on their site that provides a BGP feed of prefixes allocated by RIRs, which I think is what we're talking about here. We currently provide A BGP bogon route server feed for the asking, which are routes of 'well known' aggregate prefixes published by IANA as well as special and reserved netblocks documented by a IETF that should not be seen on the public net. Providing a feed of allocations would be the opposite approach of course. I suppose if there is interest and a need we could do this. Shoot myself or the team (i...@cymru.com) a note off list if you have thoughts on the matter or simply want to provide some feedback into such a service and how it might best be used. We're always on the look out for things we can do to help. John
Re: dealing with bogon spam ?
Just FYI the colo4jax guys got back to me and it is a stale ARIN db entry - I guess they don't update it as quickly as I thought. So this is now just a normal case of spam. Leslie Leslie wrote: Yes, unallocated (at least according to ARIN's whois db) but not unannounced - obviously our network can get to the space or else I wouldn't be having a spam problem with them! I'm actually seeing this /20 as advertised through Savvis from AS40430 It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?) Has anyone seen an IRR's DB's not being updated for more than 30 days after allocations? I always assumed that they are quickly updated. Thanks again, Leslie Jon Lewis wrote: Unallocated doesn't mean non-routed. All a spammer needs is a willing/non-filtering provider doing BGP with them, and they can announce any space they like, send out some spam, and then pull the announcement. Next morning, when you see the spam and try to figure out who to send complaints to, you're either going to complain to the wrong people or find that whois is of no help. On Tue, 27 Oct 2009, Church, Charles wrote: This is puzzling me. If it's from non-announced space, at some point some router should report no route to it. How is the TCP handshake performed to allow a sync to turn into spam? Chuck Chuck Church Network Planning Engineer, CCIE #8776 Harris Information Technology Services DOD Programs 1210 N. Parker Rd. | Greenville, SC 29609 Office: 864-335-9473 | Cell: 864-266-3978 -- Sent using BlackBerry
Re: dealing with bogon spam ?
On 28/10/09 00:57, Leslie wrote: How have you dealt with this issue? Does anyone publish a more granular listing of unallocated space? Does arin have this information somewhere other than just probing any given ip via whois? You can at least get a list of all the allocated blocks. Presumably anything not allocated is unallocated and is a candidate for blocking. for rir in afrinic apnic arin lacnic ripencc; do wget ftp://ftp.ripe.net/pub/stats/$rir/delegated-$rir-latest; done These are updated daily and include both IPv4 and IPv6 allocations. Now, what I would really like is an arin version of ripe.db.inetnum.gz :-)
Re: IPv6 Deployment for the LAN
Iljitsch van Beijnum wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! A
looking for optonline/cablevision contact
ive been having a mailing issue with optonline/cablevision for several weeks now and normal business tech support is giving me the run around. can someone from optonline/cablevision contact me off thread so i can try to get this simple thing resolved. -- Andrew Young Webair Internet Development, Inc. Phone: 1 866 WEBAIR 1 x143 http://www.webair.com Shift hours: Tues-Friday 12PM-8PM, Sat 9AM-5PM
Re: Redundant Data Center Architectures
On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. 'DR' is an obsolete 40-year-old mainframe concept; it never works, as funding/testing/scaling of the 'backup' systems is never adequate and/ or allowed. Layer-2 between sites is evil, as well. Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
Re: Redundant Data Center Architectures
On Oct 28, 2009, at 10:38 AM, Roland Dobbins wrote: On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. 'DR' is an obsolete 40-year-old mainframe concept; it never works, as funding/testing/scaling of the 'backup' systems is never adequate and/or allowed. Very true. Layer-2 between sites is evil, as well. Indeed. Now VmWare actually supports layer3 for vsphere, maybe we will start to see it go away. :) Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. Yep. That way all your environments get adequate(ish) funding. Vs management saying oh it's just backup/dr, we will fund it next year.
Re: Redundant Data Center Architectures
Roland, Could you elaborate on GSLB (Global Load Balancing?) ? Pardon if that question seems a bit noob-ish Thanks Roland Dobbins wrote: On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. 'DR' is an obsolete 40-year-old mainframe concept; it never works, as funding/testing/scaling of the 'backup' systems is never adequate and/or allowed. Layer-2 between sites is evil, as well. Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 10/28/09 09:34:00 -- -Prediction is very difficult, especially about the future. -Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344
Re: Redundant Data Center Architectures
Roland Dobbins wrote: On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. 'DR' is an obsolete 40-year-old mainframe concept; it never works, as funding/testing/scaling of the 'backup' systems is never adequate and/or allowed. Layer-2 between sites is evil, as well. Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. And that's about all you need to know. Never heard it put so succinctly - thanks, -Ryan Brooks
Re: Redundant Data Center Architectures
Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. Somewhere on video.google.com is a Google I/O talk explaining the hell that is active/active redundancy and how hard it is to achieve at layers 4-7. I don't argue that it's the proper method for Layer 3 though. -brandon On Wed, Oct 28, 2009 at 12:38 PM, Roland Dobbins rdobb...@arbor.net wrote: On Oct 28, 2009, at 8:26 PM, Stefan Fouant wrote: I'm wondering what are the growing trends in connecting Data Centers for redundancy in DR/COOP environments. 'DR' is an obsolete 40-year-old mainframe concept; it never works, as funding/testing/scaling of the 'backup' systems is never adequate and/or allowed. Layer-2 between sites is evil, as well. Layer-3-independence and active/active/etc. is where it's at in terms of high availability in the 21st Century. GSLB, et. al. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Re: Redundant Data Center Architectures
On Oct 29, 2009, at 12:44 AM, Brandon Galbraith wrote: Somewhere on video.google.com is a Google I/O talk explaining the hell that is active/active redundancy and how hard it is to achieve at layers 4-7. Depends upon the type of apps, amount of required concurrency, etc. It's easy on the front-end (which is where most of the drama tends to take place, anyways); it's the middle and back-end tiers which require some work, but it certainly can be and is accomplished daily, for both simple and more complex systems. The smart money makes use of various existing *aaS platforms to accomplish this without having to re-invent the wheel every time. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
Re: Redundant Data Center Architectures
On Oct 29, 2009, at 12:42 AM, Ray Sanders wrote: Could you elaborate on GSLB (Global Load Balancing?) ? Architectural choices, implementation scenarios, DNS tricks to ensure optimal cleaving to and availability of distributed nodes within a given tier: http://www.backhand.org/mod_backhand/ http://www.backhand.org/wackamole/ http://www.spread.org/ http://www.dsn.jhu.edu/research/group/secure_spread/ http://wiki.blitzed.org/DNS_balancing http://www.cisco.com/en/US/products/hw/contnetw/ps4162/ --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
Re: Redundant Data Center Architectures
Props for mentioning mod_backhand. Excellent tool for GSLB. On Wed, Oct 28, 2009 at 12:57 PM, Roland Dobbins rdobb...@arbor.net wrote: On Oct 29, 2009, at 12:42 AM, Ray Sanders wrote: Could you elaborate on GSLB (Global Load Balancing?) ? Architectural choices, implementation scenarios, DNS tricks to ensure optimal cleaving to and availability of distributed nodes within a given tier: http://www.backhand.org/mod_backhand/ http://www.backhand.org/wackamole/ http://www.spread.org/ http://www.dsn.jhu.edu/research/group/secure_spread/ http://wiki.blitzed.org/DNS_balancing http://www.cisco.com/en/US/products/hw/contnetw/ps4162/ --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Re: Strip AS in BGP peer
More specifically: - neighbor *ip or peer-group* attribute-unchanged as-path Cheers, Cody On Wed, 28 Oct 2009 22:19:54 +0800, Adrian Chadd adr...@creative.net.au wrote: Take a read of the quagga documentation. There's a BGP neighbor option for stripping out the local AS when speaking eBGP. Adrian On Wed, Oct 28, 2009, Sherwin Ang wrote: Hello Nanog, am not sure if i should have placed this on the cisco-nsp or the juniper-nsp but someone may have a direct answer. well here it goes. we'll soon form a new internet exchange and i would like to suggest a model in the route-server wherein the route-server would strip out it's own AS and give the neighbors/peers the AS's of the members. I have seen this in Any2IX but i have no idea on how to implement it as if i am the Any2 route-server. if you could point me to the right direction or reading, i could take it from there.
Re: dealing with bogon spam ?
Michiel Klaver wrote: I would suggest to report that netblock to SpamHaus to have it included at their DROP list, and also use that DROP list as extra filter in addition to your bogon filter setup at your border routers. The SpamHaus DROP (Don't Route Or Peer) list was specially designed for this kind of abuse of stolen 'hijacked' netblocks and netblocks controlled entirely by professional spammers. As a brief off-shoot of the original topic, has anyone scripted the use of Spamhaus's DROP list in a RTBH, ACLs, null-routes, etc? I'm not asking if people think it's safe; that's up to the network wanting to deploy it. I'm wondering if anyone has any scripts for pulling down the DROP list, parsing it into whatever you need (static routes on a RTBH trigger router or ACLs on a border router and then deployed the config change(s). I don't want to reinvent the wheel is someone else has already done this. Thanks Justin
Re: dealing with bogon spam ?
Justin Shore wrote: Michiel Klaver wrote: I would suggest to report that netblock to SpamHaus to have it included at their DROP list, and also use that DROP list as extra filter in addition to your bogon filter setup at your border routers. The SpamHaus DROP (Don't Route Or Peer) list was specially designed for this kind of abuse of stolen 'hijacked' netblocks and netblocks controlled entirely by professional spammers. As a brief off-shoot of the original topic, has anyone scripted the use of Spamhaus's DROP list in a RTBH, ACLs, null-routes, etc? I'm not asking if people think it's safe; that's up to the network wanting to deploy it. I'm wondering if anyone has any scripts for pulling down the DROP list, parsing it into whatever you need (static routes on a RTBH trigger router or ACLs on a border router and then deployed the config change(s). I don't want to reinvent the wheel is someone else has already done this. Downloading and parsing is easy. I used to drop it into the config for a small dns server, rbldnsd I believe, that understands CIDR and used it as a local blacklist. It did very little to stop spam and I was never brave enough to script an automatic update to BGP.
Re: dealing with bogon spam ?
Leslie wrote: John Kristoff wrote: I suppose if there is interest and a need we could do this. Shoot myself or the team (i...@cymru.com) a note off list if you have thoughts on the matter or simply want to provide some feedback into such a service and how it might best be used. We're always on the look out for things we can do to help. My big issue isn't the larger blocks, it's the smaller unallocated blocks - which anyone with a not-too-strict transit provider could easily steal and abuse. Getting the allocated space is just another way of finding the smaller unallocated blocks (with a bit of extra work) The problem though with BGP is that when you have say a NonAllocatedFeed containing 10.0.0.0/8 then when somebody else announced 10.1.2.0/24 (or any other more specific) it will perfectly work. Unless you are able to pull of some tricks in hardware based routers (software based ones you can of course modify to do whatever you want but might not be the right thing to run in some scenarios). As such, pulling the delegated files and generating prefix filters yourself, which you most likely have anyway for things like blackholing prefixes you otherwise also don't want to talk too And don't forget to source-filter those prefixes too :) Greets, Jeroen signature.asc Description: OpenPGP digital signature
ip options
Experts, out of the well-known values for ip options: x...@r4# set ip-options ? Possible completions: range Range of values [Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-idStream ID strict-source-route Strict source route timestampTimestamp I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them. Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
RE: ip options
Luca: Check http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/s ec_acl_sel_drop_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1 043334 Not the whole story, but :) Hope it helps, Dario -Original Message- From: Luca Tosolini [mailto:bit.gos...@chello.nl] Sent: Wednesday, October 28, 2009 3:06 PM To: nanog Subject: ip options Experts, out of the well-known values for ip options: x...@r4# set ip-options ? Possible completions: range Range of values [Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-idStream ID strict-source-route Strict source route timestampTimestamp I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them. Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
Re: ip options
On Oct 29, 2009, at 2:05 AM, Luca Tosolini wrote: Considering the security hazard that they imply, I am therefore thinking to drop them. You should certainly consider the impact on traceroute and possibly QoS (i.e., RSVP, if it's relevant) in your environment. Some vendors/platforms also have the option to ignore, rather than drop. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
Re: Redundant Data Center Architectures
Also, commercial solutions from F5 (their GTM product and their old 3-DNS product). Using CDN's is also a way of handling this, but you need to be prepared for all your traffic to come from their source-ip's or do creative things with x-forwarded-for etc. Making an active/active datacenter design work (or preferably one with enough sites such that more than one can be down without seriously impacted service) is a serious challenge. Lots of people will tell you (and sell you solutions for) parts of the puzzle. My experience has been that the best case is when the architecture of the application/infrastructure have been designed with these challenges in mind from the get-go. I have seen that done on the network and server side, but never on the software side- that has always required significant effort when the time came. The drop in solutions for this (active/active database replication, middleware solutions, proxies) are always expensive in one way or another and frequently have major deployment challenges. The network side of this can frequently be the easiest to resolve, in my experience. If you are serving up content that does not require synchronized data on the backend, then that will make your life much easier, and GSLB, a CDN or similar may help a great deal. --D On Wed, Oct 28, 2009 at 10:57 AM, Roland Dobbins rdobb...@arbor.net wrote: On Oct 29, 2009, at 12:42 AM, Ray Sanders wrote: Could you elaborate on GSLB (Global Load Balancing?) ? Architectural choices, implementation scenarios, DNS tricks to ensure optimal cleaving to and availability of distributed nodes within a given tier: http://www.backhand.org/mod_backhand/ http://www.backhand.org/wackamole/ http://www.spread.org/ http://www.dsn.jhu.edu/research/group/secure_spread/ http://wiki.blitzed.org/DNS_balancing http://www.cisco.com/en/US/products/hw/contnetw/ps4162/ --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 -- -- Darren Bolding -- -- dar...@bolding.org --
PPPoE vs. Bridged ADSL
There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? :) ). There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things. Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers. Thanks, John
Re: PPPoE vs. Bridged ADSL
JD wrote: There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things. Call your vendor and demand better radius backend support for dhcp. :) The largest fallback to PPPoE is the CPE needing to terminate the PPPoE or the customer's router/computer/etc needing to do so. This can be a pain especially in business environments. I have one section of my network (maintained by counterpart, not me) that is 90% PPPoE/A. The other 10% is bridge due to customer needs and CPE limitations. I personally run all my stuff as bridge, including all the CPEs. BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers. I have been extremely happy with unnumbered vlans in the cisco work for terminating mass vlans from dslams that support 802.1ad. The fact that it works right next to RBE works great for me. The current IPv6 layouts aren't as pretty for this setup, though. Jack
RE: Redundant Data Center Architectures
-Original Message- From: Darren Bolding [mailto:dar...@bolding.org] Sent: Wednesday, October 28, 2009 4:57 PM To: Roland Dobbins Cc: NANOG list Subject: Re: Redundant Data Center Architectures Also, commercial solutions from F5 (their GTM product and their old 3- DNS product). Using CDN's is also a way of handling this, but you need to be prepared for all your traffic to come from their source-ip's or do creative things with x-forwarded-for etc. Making an active/active datacenter design work (or preferably one with enough sites such that more than one can be down without seriously impacted service) is a serious challenge. Lots of people will tell you (and sell you solutions for) parts of the puzzle. My experience has been that the best case is when the architecture of the application/infrastructure have been designed with these challenges in mind from the get-go. I have seen that done on the network and server side, but never on the software side- that has always required significant effort when the time came. The drop in solutions for this (active/active database replication, middleware solutions, proxies) are always expensive in one way or another and frequently have major deployment challenges. The network side of this can frequently be the easiest to resolve, in my experience. If you are serving up content that does not require synchronized data on the backend, then that will make your life much easier, and GSLB, a CDN or similar may help a great deal. Thanks everyone who has responded so far. I should have clarified my intent a bit in the original email. I am definitely interested in architectures which support synchronized data between data center locations in as close to real-time as possible. More specifically, I am interested in designs which support zero down-time during failures, or as close to zero down-time as possible. GSLB, Anycast, CDNs... those types of approaches certainly have their place especially where the pull-model is employed (DNS, Netflix, etc.). However, what types of solutions are being used for synchronized data and even network I/O on back-end systems? I've been looking at the VMware vSphere 4 Fault Tolerance stuff to synchronize the data storage and network I/O across distributed virtual machines, but still worried about the consequences of doing this stuff across WAN links with high degrees of latency, etc. From the thread I get the feeling that L2 interconnects (VPLS, PWs) are generally considered a bad thing, I gathered as much as I figured there would be lots of unintended consequences with regards to designated router elections and other weirdness. Besides connecting sites via L3 VPNs, what other approaches are others using? Also, would appreciate any comments to the synchronization items above. Thanks, -- Stefan Fouant
Re: PPPoE vs. Bridged ADSL
On Cisco hardware PPPoE was cleaner if you have other ISPs' customers on your network and you want to put them in their own VRF's. I've been out of that world for a while now, so maybe it's changed. -saxon 2009/10/28 JD jdupuy-l...@socket.net There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? :) ). There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things. Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers. Thanks, John
Re: PPPoE vs. Bridged ADSL
Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. I can't speak to which would be better on copper specifically, but in general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net
Re: PPPoE vs. Bridged ADSL
Most aDSL modems if set to PPPoE (I think Actiontec's come this way by default) will send the mac as the pppoe un/pw. David E. Smith wrote: Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. I can't speak to which would be better on copper specifically, but in general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194
Re: ALTDB Problems
On Tue, Oct 27, 2009 at 11:21 AM, Steve Rubin s...@tch.org wrote: ALTDB is free and you get what you pay for. However. Donations to http://www.nanog.org/scholarships/abha.php would probably get requests done a lot faster. -- Steve Rubin/ AE6CH / http://www.altdb.net/ Email: s...@tch.org / N6441C / http://www.tch.org/~ser/ so, each time someone wants to update they need to donate to make sure it gets processed in a timely matter? or do you track who donates and give priority to their updates? dont get me wrong - its a great cause, and people should donate if they can if the project is short of volunteers - i'm sure there are people in the community who would not mind helping out -ck
Re: PPPoE vs. Bridged ADSL
We like PPPoE on the edge because we can use RADIUS to apply policy to the subscribers for bandwidth management, class-of-service, SNPs, etc. You probably have some of these features via your DSLAM, but we found it easier to do via RADIUS with a web based GUI for our provisioning folks. So if we need to snip someone's Internet and leave voice or VPN packets alone due to an abuse issue for example, we can apply the policy that references the appropriate ACL. George smime.p7s Description: S/MIME cryptographic signature
Re: PPPoE vs. Bridged ADSL
On Wed, 28 Oct 2009 15:33:58 -0700 Walter Keen walter.k...@rainierconnect.net wrote: Most aDSL modems if set to PPPoE (I think Actiontec's come this way by default) will send the mac as the pppoe un/pw. David E. Smith wrote: Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. DOCSIS cable networks use DHCP and have for a long time. If you have Ethernet based DSLAMs, they can usually do the a number of tricks (e.g. Option 82 insertion into the DHCP request) that would make a DHCP ADSL deployment no harder (or easier) than a DOCSIS cable network. It seems to me that the fundamental purpose of PPPoE is to be able to uniquely identify the customer for billing/provisioning purposes. Even though you only need to be able to do that at the start of their session, with PPPoE you pay an 8 byte per packet overhead, on _every_ packet sent and received by the customer. Other methods of distinguishing the customer, e.g. Option 82, static DHCP mapped to a customer MAC address, or possibly 802.1x if it were available, have much, much lower overhead. I think PPPoE really only exists to make ADSL look like high speed dial-up, so that ISPs dial up backend systems didn't need to be changed when ADSL was introduced. That was a valid concern in the past, but with existing solutions or models such as the DOCSIS Cable methods, and Ethernet based DSLAMS, I'd suggest avoiding PPPoE if you can. I can't speak to which would be better on copper specifically, but in general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194
Re: IPv6 Deployment for the LAN
This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy
Re: PPPoE vs. Bridged ADSL
Apologies if this message is brief, it is sent from my cellphone. On 29/10/2009, at 11:33, Walter Keen walter.k...@rainierconnect.net wrote: Most aDSL modems if set to PPPoE (I think Actiontec's come this way by default) will send the mac as the pppoe un/pw. David E. Smith wrote: Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. I can't speak to which would be better on copper specifically, but in general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194 !DSPAM:22,4ae8c6fe233691194411224!
Re: ALTDB Problems
On Oct 28, 2009, at 3:53 PM, christian koch wrote: On Tue, Oct 27, 2009 at 11:21 AM, Steve Rubin s...@tch.org wrote: ALTDB is free and you get what you pay for. However. Donations to http://www.nanog.org/scholarships/abha.php would probably get requests done a lot faster. -- Steve Rubin/ AE6CH / http://www.altdb.net/ Email: s...@tch.org / N6441C / http://www.tch.org/~ser/ so, each time someone wants to update they need to donate to make sure it gets processed in a timely matter? or do you track who donates and give priority to their updates? dont get me wrong - its a great cause, and people should donate if they can if the project is short of volunteers - i'm sure there are people in the community who would not mind helping out -ck No, every update does not require a donation. In fact, very little of what goes on on the database requires my intervention at all. Only new maintainers and a few other bits of administrivia require that. Right now I am very busy and do not have time to deal with things at the speed required by some people. As I have always said, if you require immediate support I recommend the very fine RADB service run by Merit. -- Steve Rubin/ AE6CH / http://www.altdb.net/ Email: s...@tch.org / N6441C / http://www.tch.org/~ser/
Re: IPv6 Deployment for the LAN
Amen to that Randy. MMC Randy Bush wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy
Re: dealing with bogon spam ?
You are using it the wrong way .. most of the drop list is directly spammer controlled space used as, for example, CC for botnets. You'd see tons of abuse and little or no smtp traffic from a lot of those hosts. On Thu, Oct 29, 2009 at 12:26 AM, Jason Bertoch ja...@i6ix.com wrote: Justin Shore wrote: As a brief off-shoot of the original topic, has anyone scripted the use of Spamhaus's DROP list in a RTBH, ACLs, null-routes, etc? I'm not asking if people think it's safe; that's up to the network wanting to deploy it. I'm Downloading and parsing is easy. I used to drop it into the config for a small dns server, rbldnsd I believe, that understands CIDR and used it as a local blacklist. It did very little to stop spam and I was never brave enough to script an automatic update to BGP.
Re: IPv6 Deployment for the LAN
This is unusual, but, I have to agree with Randy here. Owen On Oct 28, 2009, at 5:09 PM, Matthew Moyle-Croft wrote: Amen to that Randy. MMC Randy Bush wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy
Re: Redundant Data Center Architectures
On 29/10/2009, at 8:39 AM, Stefan Fouant wrote: -Original Message- From: Darren Bolding [mailto:dar...@bolding.org] Sent: Wednesday, October 28, 2009 4:57 PM To: Roland Dobbins Cc: NANOG list Subject: Re: Redundant Data Center Architectures Also, commercial solutions from F5 (their GTM product and their old 3- DNS product). Using CDN's is also a way of handling this, but you need to be prepared for all your traffic to come from their source-ip's or do creative things with x-forwarded-for etc. Making an active/active datacenter design work (or preferably one with enough sites such that more than one can be down without seriously impacted service) is a serious challenge. Lots of people will tell you (and sell you solutions for) parts of the puzzle. My experience has been that the best case is when the architecture of the application/infrastructure have been designed with these challenges in mind from the get-go. I have seen that done on the network and server side, but never on the software side- that has always required significant effort when the time came. The drop in solutions for this (active/active database replication, middleware solutions, proxies) are always expensive in one way or another and frequently have major deployment challenges. The network side of this can frequently be the easiest to resolve, in my experience. If you are serving up content that does not require synchronized data on the backend, then that will make your life much easier, and GSLB, a CDN or similar may help a great deal. Thanks everyone who has responded so far. I should have clarified my intent a bit in the original email. I am definitely interested in architectures which support synchronized data between data center locations in as close to real-time as possible. More specifically, I am interested in designs which support zero down-time during failures, or as close to zero down- time as possible. GSLB, Anycast, CDNs... those types of approaches certainly have their place especially where the pull-model is employed (DNS, Netflix, etc.). However, what types of solutions are being used for synchronized data and even network I/O on back-end systems? I've been looking at the VMware vSphere 4 Fault Tolerance stuff to synchronize the data storage and network I/O across distributed virtual machines, but still worried about the consequences of doing this stuff across WAN links with high degrees of latency, etc. From the thread I get the feeling that L2 interconnects (VPLS, PWs) are generally considered a bad thing, I gathered as much as I figured there would be lots of unintended consequences with regards to designated router elections and other weirdness. Besides connecting sites via L3 VPNs, what other approaches are others using? Also, would appreciate any comments to the synchronization items above. Thanks, -- Stefan Fouant Layer 2 interconnects (whether they are VPLS / PWE3 / or other CCC- based models) are not bad in their own right, but I think it's important to realize that extending a (sub)network across large geographical regions because applications are not building intelligence about locality or presence is a move without intelligent engineering. I hear it all the time: just extend layer 2 between these two data centers so that we can have either (1) disaster recovery or (2) vmotion / heart beats / etc ... The truth is we can do things better and smarter than just extending bridging domains across disparate geographical locations. Real time storage should ideally be local .. but there is no reason why it can't be available over the cloud to other networks. The key is to have a single namespace for all storage, to not be tied to a particular storage technology, but to simply be able to present the storage/disk/ mount point to virtual machines. Extending layer 2 for iSCSI / SAN / and even FCoE is feasible. But, lets think about the technology in detail .. FCoE uses pause frames, and when there is significant geographical delay between sites, then FCoE is not the right technology. It works great locally .. and this should be just one technology to deliver storage locally in DCs. Internally I would explore DNS (GSLB / anycast / etc) .. and even ideas like mobile IPv4 / IPv6 mobility before I started extending layer 2 domains across the world. Kind regards, Truman
