Juniper M120 Alternatives
Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers? I'm asking as the prices to upgrade to 10Gbit capable Juniper units (ie. an M120) seem prohibitively high so I'm looking to get a feel for the alternatives. The other obvious platform would appear to be a Cisco XR 12404 (or similar depending on line card requirements) but is anything else in common use as a peering platform? Cheers for any input. Rgds Gary
On Mon, Nov 16, 2009 at 09:04, Dale W. Carder <dwcarder@wisc.edu> wrote:
On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote:
Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers?
have you looked at the MX series?
+1 ~Chris
Dale
-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org
On Mon, Nov 16, 2009 at 09:04, Dale W. Carder <dwcarder@wisc.edu> wrote:
On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote:
Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers?
have you looked at the MX series?
+1 ~Chris
Dale
I had looked briefly, does anybody here actually use them as peering routers? I've seen a few implementations using them in the MPLS P and PE router roles but never as border routers. If there is some precedent for using them in this role that's good to hear and I'll take another look, I was loath to move away from Juniper as our current boxes are been the model of reliability. Cheers Gary
* Gary Mackenzie
I had looked briefly, does anybody here actually use them as peering routers? I've seen a few implementations using them in the MPLS P and PE router roles but never as border routers.
We've been using the MX-es as border routers for some time now. It's a role that suits them very well in my opinion, no problems at all so far. I'll be very surprised if we don't end up using MX-es in our next PoP as well. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
Tore Anderson wrote:
* Gary Mackenzie
I had looked briefly, does anybody here actually use them as peering routers? I've seen a few implementations using them in the MPLS P and PE router roles but never as border routers.
We've been using the MX-es as border routers for some time now. It's a role that suits them very well in my opinion, no problems at all so far. I'll be very surprised if we don't end up using MX-es in our next PoP as well.
Best regards,
We're using them as border routers and love them. As long as you don't need sonet, i think it's a great choice. Leslie
On Mon, Nov 16, 2009 at 06:04:46PM +0100, Tore Anderson wrote:
We've been using the MX-es as border routers for some time now. It's a role that suits them very well in my opinion, no problems at all so far.
Caveat: no MAC accounting on LAGs (IEEE speak) / Aggregated Ethernet (Juniper speak) / Etherchannels (Cisco speak). Might or might not be important when using bundled links to public peering fabrics. Best regards, Daniel PS: and of course JUNOS still undeterministically resetting unrelated BGP sessions for no good reason when modifying BGP configuration - so one is well-advised to do ANY configuration changes in the area of BGP within a maint window as it might happen that you configure a peering session and whoops there goes your IBGP mesh... or all your other peerings, or, ... </rant> -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Tue, Nov 17, 2009 at 01:28:06AM +0100, Daniel Roesen wrote:
PS: and of course JUNOS still undeterministically resetting unrelated BGP sessions for no good reason when modifying BGP configuration - so one is well-advised to do ANY configuration changes in the area of BGP within a maint window as it might happen that you configure a peering session and whoops there goes your IBGP mesh... or all your other peerings, or, ...
Well to be fair, the session resetting on config change behavior is actually quite deterministic (being EASY to determine is not part of the requirements, technically speaking :P), and most of the resets really do have perfectly good reasons. I'll certainly go with "really annoying and often a giant pain in the @#$%^&*" though. They've definitely been improving it over the years though, so much that I almost never trigger a session reset on me unintentionally any more. The things to watch out for are: a) any time you change the update replication by moving a neighbor between groups, renaming groups, or significantly changing the export policy chain. b) any time you change a major part of the underlying interface configuration for an eBGP session, such as mtu or vlan tagging config. c) any time you change something about the bgp session which really does require a session reset to take effect, such as a new ASN, new endpoint address, new mbgp family configuration, new md5 password, new tcp mss, etc. You can actually safeguard yourself from a lot of the accidental reset behaviors while implementing other features at the same time by using commit scripts (i.e. as a side-effect of my scripts which exist for other reasons, I automatically protect myself against changes to the policy chain or family configuration which might cause unintended session flaps), though I'll certainly admit this is well into the category of "power user" and not appropriate for most people. They are making some progress though, you can actually turn NSR on and off now without flapping your sessions, which is certainly an improvement over the serious logic flaws in earlier versions (where you couldn't turn off NSR without flapping every session, but you also couldn't commit w/NSR enabled and the backup RE offline, effectively locking you out of config changes without a total box flap if you didn't have both RE's running). It would certainly be a lot more user friendly if they could tell you what sessions would be reset as part of a "commit check" process though. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Richard A Steenbergen wrote:
They've definitely been improving it over the years though, so much that I almost never trigger a session reset on me unintentionally any more.
They must have. This was new to me and came as a shock. I don't think I've ever seen my m120 behave any different than my cisco when it comes to flapping BGP. Things have just worked as I expected them to. Not that I go screwing with underlying interface configs or changing a peer from one group to another or changing the asn; at least not on a live session. These things would seem to indicate that the session might be subject to reset. Perhaps it just behaves for normal users and not power users. :) Jack
On Tue, Nov 17, 2009 at 09:24:24AM -0600, Jack Bates wrote:
Richard A Steenbergen wrote:
They've definitely been improving it over the years though, so much that I almost never trigger a session reset on me unintentionally any more.
They must have. This was new to me and came as a shock. I don't think I've ever seen my m120 behave any different than my cisco when it comes to flapping BGP. Things have just worked as I expected them to. Not that I go screwing with underlying interface configs or changing a peer from one group to another or changing the asn; at least not on a live session. These things would seem to indicate that the session might be subject to reset.
Perhaps it just behaves for normal users and not power users. :)
But those things won't trigger session resets on Cisco, so it often comes as a shock. Also, one might very well expect that changing the peer-as on a neighbor is going to cause a reset, but if you didn't know from experience you might not expect that renaming a group or changing an underlying interface MTU would do it too. The issue is that there is a fundamental design difference between Cisco and Juniper. Cisco lets you configure anything you want in a line by line basis, but it doesn't immediately apply those changes until you command it to do so. Juniper's philosophy is that you make a bunch of changes to a candiate configuration, "commit" to apply those changes, and then you can expect those changes to take effect (or at least begin trying to take effect) immediately. Personally I think the Juniper design philosophy is "better". Besides the obvious stuff like being able to rollback your config, think about how non-deterministic it is when you update a route-map but forget to soft clear the BGP session. The routes that have been exchanged so far will retain their old policy, while any new updates you receive after the route-map change will receive the new policy, leaving the session in an inconsistent state that will slowly and unpredictably change over time as routing updates come in. The trade-off is that you lose the ability to do non-impacting changes, where you make a change but know that it hasn't actually taken effect yet, and won't until the next time the session bounces. What Juniper is trying to do really is a good thing, I just wish it could tell me before I commit what is and isn't going to flap. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Tue, Nov 17, 2009 at 5:32 PM, Richard A Steenbergen <ras@e-gerbil.net>wrote:
On Tue, Nov 17, 2009 at 09:24:24AM -0600, Jack Bates wrote:
Richard A Steenbergen wrote:
They've definitely been improving it over the years though, so much that I almost never trigger a session reset on me unintentionally any more.
They must have. This was new to me and came as a shock. I don't think I've ever seen my m120 behave any different than my cisco when it comes to flapping BGP. Things have just worked as I expected them to. Not that I go screwing with underlying interface configs or changing a peer from one group to another or changing the asn; at least not on a live session. These things would seem to indicate that the session might be subject to reset.
Perhaps it just behaves for normal users and not power users. :)
But those things won't trigger session resets on Cisco, so it often comes as a shock. Also, one might very well expect that changing the peer-as on a neighbor is going to cause a reset, but if you didn't know from experience you might not expect that renaming a group or changing an underlying interface MTU would do it too.
The issue is that there is a fundamental design difference between Cisco and Juniper. Cisco lets you configure anything you want in a line by line basis, but it doesn't immediately apply those changes until you command it to do so. Juniper's philosophy is that you make a bunch of changes to a candiate configuration, "commit" to apply those changes, and then you can expect those changes to take effect (or at least begin trying to take effect) immediately.
Personally I think the Juniper design philosophy is "better". Besides the obvious stuff like being able to rollback your config, think about how non-deterministic it is when you update a route-map but forget to soft clear the BGP session. The routes that have been exchanged so far will retain their old policy, while any new updates you receive after the route-map change will receive the new policy, leaving the session in an inconsistent state that will slowly and unpredictably change over time as routing updates come in. The trade-off is that you lose the ability to do non-impacting changes, where you make a change but know that it hasn't actually taken effect yet, and won't until the next time the session bounces. What Juniper is trying to do really is a good thing, I just wish it could tell me before I commit what is and isn't going to flap. :)
The design differences you describe there relate more to traditional IOS vs JUNOS, rather than IOS XR vs JUNOS. IOS XR uses candidate configurations, commit, rollback etc. Paul.
That's excellent news - any word on when Cisco will be back-porting these truly useful features from XR to that platform which so many of us are still running on (ie "traditional IOS")? Phil P On Thu, Nov 19, 2009 at 1:04 AM, Paul Cosgrove < paul.cosgrove.nanog@gmail.com> wrote:
On Tue, Nov 17, 2009 at 5:32 PM, Richard A Steenbergen <ras@e-gerbil.net
wrote: The design differences you describe there relate more to traditional IOS vs JUNOS, rather than IOS XR vs JUNOS. IOS XR uses candidate configurations, commit, rollback etc.
Paul.
That's excellent news - any word on when Cisco will be back-porting these truly useful features from XR to that platform which so many of us are still running on (ie "traditional IOS")?
Obviously not speaking for Cisco here - but as a significant customer we have had no indication that this will happen, ever. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Phil Pierotti wrote:
That's excellent news - any word on when Cisco will be back-porting these truly useful features from XR to that platform which so many of us are still running on (ie "traditional IOS")?
The general feeling is that XR won't be ported to a lot of existing hardware, and traditional IOS is just royally screwed (see 12.3T EOL'd and 12.4 bloated and full of bugs, and everything older missing critical PE functionality for unnumbered vlans). Jack (disliking all vendors when it comes to the edge right now)
As a side note that many may be aware of, there are other Cisco products/code bases that have these nice features. tv ----- Original Message ----- From: "Paul Cosgrove" <paul.cosgrove.nanog@gmail.com> To: "Richard A Steenbergen" <ras@e-gerbil.net> Cc: <nanog@nanog.org> Sent: Wednesday, November 18, 2009 8:04 AM Subject: Re: Juniper M120 Alternatives
The design differences you describe there relate more to traditional IOS vs JUNOS, rather than IOS XR vs JUNOS. IOS XR uses candidate configurations, commit, rollback etc.
Paul.
On Tue, Nov 17, 2009 at 01:28:06AM +0100, Daniel Roesen wrote:
Caveat: no MAC accounting on LAGs (IEEE speak) / Aggregated Ethernet (Juniper speak) / Etherchannels (Cisco speak).
Might or might not be important when using bundled links to public peering fabrics.
Or for the very same goal, vendors can maybe think at making support for L2 primitives via NetFlow v9 exports somewhat more implemented. Cheers, Paolo
Date: Mon, 16 Nov 2009 16:14:52 -0000 (GMT) From: "Gary Mackenzie" <net-ops@monolith-networks.net>
On Mon, Nov 16, 2009 at 09:04, Dale W. Carder <dwcarder@wisc.edu> wrote:
On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote:
Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers?
have you looked at the MX series?
+1 ~Chris
Dale
I had looked briefly, does anybody here actually use them as peering routers? I've seen a few implementations using them in the MPLS P and PE router roles but never as border routers.
If there is some precedent for using them in this role that's good to hear and I'll take another look, I was loath to move away from Juniper as our current boxes are been the model of reliability.
We use them as peering routers and are in the process of upgrading all of our peering routers to MX boxes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers?
Juniper MX series? Works great for us. Much nicer 10G prices than M120. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
I'd think the Juniper MX series might fit, as well as the Brocade NetIron XMR. And of course the Cisco you already mentioned. -brad On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote:
Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers?
I'm asking as the prices to upgrade to 10Gbit capable Juniper units (ie. an M120) seem prohibitively high so I'm looking to get a feel for the alternatives. The other obvious platform would appear to be a Cisco XR 12404 (or similar depending on line card requirements) but is anything else in common use as a peering platform?
Cheers for any input.
Rgds
Gary
Cisco's ASR9000 is supposed to be in-line with the Juniper MX offering (price-wise and feature-wise); more so than as 124xx, I hear. On 2009-11-16, at 10:54 AM, "Gary Mackenzie" <net-ops@monolith-networks.net
wrote:
Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers?
I'm asking as the prices to upgrade to 10Gbit capable Juniper units (ie. an M120) seem prohibitively high so I'm looking to get a feel for the alternatives. The other obvious platform would appear to be a Cisco XR 12404 (or similar depending on line card requirements) but is anything else in common use as a peering platform?
Cheers for any input.
Rgds
Gary
Hi, It seems that there is a major fiber cut in Italy (not really near nanog, so just in case...) I was just wondering if anybody has heard of any possible recovery time - as there is none official one yet. Thank you, Jean-Christophe VARAILLON ------------------------- Data Network Engineer Cosmoline - www.cosmoline.com 40th km Attiki Odos Rest Area Mesogea 190 02 Peania, Greece my: phone +30 212 212 2211 my: cell +30 694 556 4826 my: fax2mail +30 212 212 9905 my: e-mail j.varaillon@cosmoline.com ΕΙΔΟΠΟΙΗΣΗ ΑΠΟΡΡΗΤΟΥ: Οι πληροφορίες που περιλαμβάνονται στο παρόν είναι εμπιστευτικές και απευθύνονται αποκλειστικά προς τον παραλήπτη που αναφέρεται παραπάνω. Εάν το μήνυμα που ακολουθεί δεν προορίζεται για σας, σας γνωρίζουμε ότι δεν δικαιούσθε και είναι παράνομο να το αναγνώσετε, αντιγράψετε, διανείμετε ή χρησιμοποιήσετε με οποιοδήποτε τρόπο. Σας παρακαλούμε ακόμη να ειδοποιήσετε αμέσως τον αποστολέα στην τηλεφωνική σύνδεση που αναφέρεται ή με απαντητικό e-mail και να καταστρέψετε το πρωτότυπο. IMPORTANT NOTICE: This email and any of its attachments are intended only for the recipient(s) named above and are confidential and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons,is prohibited and may constitute a criminal offence. If you have received this email in error, please notify the sender immediately and delete the original message. __________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com
On Mon, 16 Nov 2009, Varaillon Jean Christophe wrote: Yup - even Israel is affected. Started at 16:35 (gmt+2) and the cut is inside Telecom Italia. No ETA. -Hank
Hi,
It seems that there is a major fiber cut in Italy (not really near nanog, so just in case...)
I was just wondering if anybody has heard of any possible recovery time - as there is none official one yet.
Thank you,
Jean-Christophe VARAILLON ------------------------- Data Network Engineer Cosmoline - www.cosmoline.com 40th km Attiki Odos Rest Area Mesogea 190 02 Peania, Greece my: phone +30 212 212 2211 my: cell +30 694 556 4826 my: fax2mail +30 212 212 9905 my: e-mail j.varaillon@cosmoline.com
ΕΙΔΟΠΟΙΗΣΗ ΑΠΟΡΡΗΤΟΥ: Οι πληροφορίες που περιλαμβάνονται στο παρόν είναι εμπιστευτικές και απευθύνονται αποκλειστικά προς τον παραλήπτη που αναφέρεται παραπάνω. Εάν το μήνυμα που ακολουθεί δεν προορίζεται για σας, σας γνωρίζουμε ότι δεν δικαιούσθε και είναι παράνομο να το αναγνώσετε, αντιγράψετε, διανείμετε ή χρησιμοποιήσετε με οποιοδήποτε τρόπο. Σας παρακαλούμε ακόμη να ειδοποιήσετε αμέσως τον αποστολέα στην τηλεφωνική σύνδεση που αναφέρεται ή με απαντητικό e-mail και να καταστρέψετε το πρωτότυπο.
IMPORTANT NOTICE: This email and any of its attachments are intended only for the recipient(s) named above and are confidential and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons,is prohibited and may constitute a criminal offence. If you have received this email in error, please notify the sender immediately and delete the original message.
__________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________
The message was checked by ESET Smart Security.
This is still ongoing (more than 6 hours now...), and nobody can give any ETA. So if someone hear about something... Thank you Jean-Christophe -----Original Message----- From: Varaillon Jean Christophe [mailto:varaillon@cosmoline.com] Sent: Monday, November 16, 2009 7:05 PM To: nanog@nanog.org Subject: Fiber Cut in Italy Hi, It seems that there is a major fiber cut in Italy (not really near nanog, so just in case...) I was just wondering if anybody has heard of any possible recovery time - as there is none official one yet. Thank you, Jean-Christophe VARAILLON ------------------------- Data Network Engineer Cosmoline - www.cosmoline.com 40th km Attiki Odos Rest Area Mesogea 190 02 Peania, Greece my: phone +30 212 212 2211 my: cell +30 694 556 4826 my: fax2mail +30 212 212 9905 my: e-mail j.varaillon@cosmoline.com ΕΙΔΟΠΟΙΗΣΗ ΑΠΟΡΡΗΤΟΥ: Οι πληροφορίες που περιλαμβάνονται στο παρόν είναι εμπιστευτικές και απευθύνονται αποκλειστικά προς τον παραλήπτη που αναφέρεται παραπάνω. Εάν το μήνυμα που ακολουθεί δεν προορίζεται για σας, σας γνωρίζουμε ότι δεν δικαιούσθε και είναι παράνομο να το αναγνώσετε, αντιγράψετε, διανείμετε ή χρησιμοποιήσετε με οποιοδήποτε τρόπο. Σας παρακαλούμε ακόμη να ειδοποιήσετε αμέσως τον αποστολέα στην τηλεφωνική σύνδεση που αναφέρεται ή με απαντητικό e-mail και να καταστρέψετε το πρωτότυπο. IMPORTANT NOTICE: This email and any of its attachments are intended only for the recipient(s) named above and are confidential and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons,is prohibited and may constitute a criminal offence. If you have received this email in error, please notify the sender immediately and delete the original message. __________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4613 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com
TI Sparkle just confirmed they are having a fault. Email from Telecom Italia Sparkle - Seabone NOC: Dear We have a big fault ( fiber cut) in france 2 cuts and one in milan. We are working to solve it asap. Regards ———————————————- Telecom Italia Sparkle SpA Customer Assistance/Assurance I° t Se@bone Network Operations Center Via M. Palocco, 223 – Rome, IT Varaillon Jean Christophe wrote:
This is still ongoing (more than 6 hours now...), and nobody can give any ETA.
So if someone hear about something...
Thank you Jean-Christophe -----Original Message----- From: Varaillon Jean Christophe [mailto:varaillon@cosmoline.com] Sent: Monday, November 16, 2009 7:05 PM To: nanog@nanog.org Subject: Fiber Cut in Italy
Hi,
It seems that there is a major fiber cut in Italy (not really near nanog, so just in case...)
I was just wondering if anybody has heard of any possible recovery time - as there is none official one yet.
Thank you,
Jean-Christophe VARAILLON ------------------------- Data Network Engineer Cosmoline - www.cosmoline.com 40th km Attiki Odos Rest Area Mesogea 190 02 Peania, Greece my: phone +30 212 212 2211 my: cell +30 694 556 4826 my: fax2mail +30 212 212 9905 my: e-mail j.varaillon@cosmoline.com
ΕΙΔΟΠΟΙΗΣΗ ΑΠΟΡΡΗΤΟΥ: Οι πληροφορίες που περιλαμβάνονται στο παρόν είναι εμπιστευτικές και απευθύνονται αποκλειστικά προς τον παραλήπτη που αναφέρεται παραπάνω. Εάν το μήνυμα που ακολουθεί δεν προορίζεται για σας, σας γνωρίζουμε ότι δεν δικαιούσθε και είναι παράνομο να το αναγνώσετε, αντιγράψετε, διανείμετε ή χρησιμοποιήσετε με οποιοδήποτε τρόπο. Σας παρακαλούμε ακόμη να ειδοποιήσετε αμέσως τον αποστολέα στην τηλεφωνική σύνδεση που αναφέρεται ή με απαντητικό e-mail και να καταστρέψετε το πρωτότυπο.
IMPORTANT NOTICE: This email and any of its attachments are intended only for the recipient(s) named above and are confidential and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons,is prohibited and may constitute a criminal offence. If you have received this email in error, please notify the sender immediately and delete the original message.
__________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature database 4613 (20091116) __________
The message was checked by ESET Smart Security.
On Mon, 16 Nov 2009, Varaillon Jean Christophe wrote: We have observed restoration around 1:30am (gmt+2). About 9 hours of outage. -Hank
This is still ongoing (more than 6 hours now...), and nobody can give any ETA.
So if someone hear about something...
Thank you Jean-Christophe -----Original Message----- From: Varaillon Jean Christophe [mailto:varaillon@cosmoline.com] Sent: Monday, November 16, 2009 7:05 PM To: nanog@nanog.org Subject: Fiber Cut in Italy
Hi,
It seems that there is a major fiber cut in Italy (not really near nanog, so just in case...)
I was just wondering if anybody has heard of any possible recovery time - as there is none official one yet.
Thank you,
Jean-Christophe VARAILLON ------------------------- Data Network Engineer Cosmoline - www.cosmoline.com 40th km Attiki Odos Rest Area Mesogea 190 02 Peania, Greece my: phone +30 212 212 2211 my: cell +30 694 556 4826 my: fax2mail +30 212 212 9905 my: e-mail j.varaillon@cosmoline.com
ΕΙΔΟΠΟΙΗΣΗ ΑΠΟΡΡΗΤΟΥ: Οι πληροφορίες που περιλαμβάνονται στο παρόν είναι εμπιστευτικές και απευθύνονται αποκλειστικά προς τον παραλήπτη που αναφέρεται παραπάνω. Εάν το μήνυμα που ακολουθεί δεν προορίζεται για σας, σας γνωρίζουμε ότι δεν δικαιούσθε και είναι παράνομο να το αναγνώσετε, αντιγράψετε, διανείμετε ή χρησιμοποιήσετε με οποιοδήποτε τρόπο. Σας παρακαλούμε ακόμη να ειδοποιήσετε αμέσως τον αποστολέα στην τηλεφωνική σύνδεση που αναφέρεται ή με απαντητικό e-mail και να καταστρέψετε το πρωτότυπο.
IMPORTANT NOTICE: This email and any of its attachments are intended only for the recipient(s) named above and are confidential and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons,is prohibited and may constitute a criminal offence. If you have received this email in error, please notify the sender immediately and delete the original message.
__________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature database 4613 (20091116) __________
The message was checked by ESET Smart Security.
participants (20)
-
Brad Fleming -
Chris Grundemann -
Dale W. Carder -
Daniel Roesen -
Gary Mackenzie -
Hank Nussbacher -
Jack Bates -
Jason Lixfeld -
Kevin Oberman -
Leonardo Rizzi -
Leslie -
Paolo Lucente -
Paul Cosgrove -
Phil Pierotti -
Randy Bush -
Richard A Steenbergen -
sthaug＠nethelp.no -
Tony Varriale -
Tore Anderson -
Varaillon Jean Christophe