Re: Overflow circuit
> > At this time, it looks like using H.323 gatekeeper as suggested by Patrick > Murphy maybe the most likely way to go. Yes, use gatekeeper to balance calls between terrestrial link (for first NN calls) and satellite link (for other calls). Be sure that reverse traffic uses the same path (it can be done by simple routing).
Re: CCO goes down the tubes
having a major provider like Cisco require that field technical people have significant computing resources to view potentialy critical information is very very bad. Many times in the field you are working in a situation where you don't have many of the normal resources a desk jockey would have. Cisco, please get the eye candy people out of the technical groups. On Sun, Mar 28, 2004 at 10:59:22PM -0800, michael wrote: > > Hello, > > On Mon, 29 Mar 2004 [EMAIL PROTECTED] wrote: > > > > > Maybe I'm the only one left who sees a need to be able to > > check on things from a vt100 at a remote site. > > You are not alone. > Would be nice if there was a "view as text" option. > > Michael...
Re: CCO goes down the tubes
Hello, On Mon, 29 Mar 2004 [EMAIL PROTECTED] wrote: > > Maybe I'm the only one left who sees a need to be able to > check on things from a vt100 at a remote site. You are not alone. Would be nice if there was a "view as text" option. Michael...
CCO goes down the tubes
Anyone else notice that you now need javascript in order to even view TAC Cases? Anyone else annoyed by this crippling of something Cisco actually did reasonably well? Anyone not care what cisco does to CCO because you're still mourning the loss of CIO? What's next, requirement for flash to view vendor documentation? (Equinix already has this inane requirement.) Maybe I'm the only one left who sees a need to be able to check on things from a vt100 at a remote site. Welcome to the web, the technology that was supposed to remove technological incompatibilities and vendor-specific software requirements.
Multiple Cisco AS5800 controlled by 1 Cisco 7206VXR
I have been tasked by management to determine if there is a way to connect more than 1 AS5814 to a Cisco7206VXR for the purpose of Providing Dialup Modems. Currently we have a 1 to 1 ratio of Cisco 7206VXR Router-Shelf connected to a Cisco 5814 Dial-Shelf and it works without any problems. We are trying to see if anyone has had any luck with connecting more than 1 dial-shelf to a single Router-Shelf. Any recommendations are welcome. D. Scott Smith Operations Manager Core Communications, Inc. [EMAIL PROTECTED]
RE: Overflow circuit
QoS mechanisms (i.e. CBWFQ/LLQ) take care of prioritizing voice over data. So I am not worried about data. Dynamic routing (EIGRP in this case) does a beautiful job of failing over IP traffic from one T1 to another when required. The objective of this exercise is to see how we can go about overflowing voice traffic from the terrestial T1 to the satellite T1. So, this is not really about load-balancing or load-sharing. At this time, it looks like using H.323 gatekeeper as suggested by Patrick Murphy maybe the most likely way to go. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Stephen Sprunk > Sent: Sunday, March 28, 2004 2:35 AM > With G.729a and cRTP, you can cram over a hundred calls into <...> > a single T1; what is the average and peak usage predicted for > your deployment? > > While I know it's not ideal, you may want to consider using > CallMangler's bandwidth control features to ensure voice > traffic never exceeds the T1's capacity. That way you can > route all voice to the T1, all data to the satellite, and not > worry about fancy load-sharing tricks.
Re: Overflow circuit
> VoIP over satellite? I am very sceptical about it. Better, forget such > idea. It works just fine. In fact, quite a lot of international calls to smaller countries are routed exactly that way. Alex
Re: disabling SMTP
On Mar 28, 2004, at 10:44 AM, Eric A. Hall wrote: To be more realistic (and to close-in on any 'proposal' which might subsequently develop), it would likely be far more feasible to assign somewhat agressive negative weighting to sessions that use HELO (and further possible to assign mild positive weighting to sessions that use properly-formed EHLO), such as for use with session-wide rejects. This solution might work/help for what, maybe a week? Spammers are scum but they aren't dumb. I would imagine that posting this technique to NANOG just made it totally worthless. Look for malware to start being ESMTP compliant in a few hours, days or maybe a week if the spammers are too busy laughing at our complete and total collective failure at dealing with them effectively to put down their pina colada's to code the fix. Cynical? maybe. True? Sadly I think it is. Thanks, david ulevitch
Re: disabling SMTP
On 3/28/2004 10:19 AM, Eric A. Hall wrote: > might be feasible for some of us to disable legacy SMTP entirely. To be more realistic (and to close-in on any 'proposal' which might subsequently develop), it would likely be far more feasible to assign somewhat agressive negative weighting to sessions that use HELO (and further possible to assign mild positive weighting to sessions that use properly-formed EHLO), such as for use with session-wide rejects. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: disabling SMTP
On 3/28/2004 9:57 AM, Richard Welty wrote: > before i write an extended explanation of why i don't like this > idea much, i'd very much like to hear some of the motivation > behind the proposal. It wasn't a proposal, it was a request for data. My own local data suggests that HELO is almost exclusively used by malware agents (modulo the internal appliances and user agents, which is why I referenced the local exceptions). I'm mostly wondering how representative that is. It might be feasible for some of us to disable legacy SMTP entirely. Nothing is universal, of course, and what works for me and my domains obviously wouldn't work for ~Hotmail or other large-scale providers. But since I don't manage those networks, they are not part of my local decision process either. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: disabling SMTP
On Sun, 28 Mar 2004 10:22:44 -0500 (EST) Richard Welty <[EMAIL PROTECTED]> wrote: i should add that i think that this proposal is a bad idea for any number of reasons, but this cisco pix thing is very concrete so i just wanted to get it out there. before i write an extended explanation of why i don't like this idea much, i'd very much like to hear some of the motivation behind the proposal. i don't see where a client that gives EHLO and then doesn't negotiate any options is any different from a client that gives HELO, so i just don't see what refusing to accept email from HELO clients is supposed to buy you. on the server side, i don't see what refusing to send email when you don't see ESMTP in the banner accomplishes either. in either case, such a policy would only last until a VP figures out that you're responsible for his inability to exchange email with his mistress. richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Re: disabling SMTP
On Sun, 28 Mar 2004 08:59:40 -0500 Rob Nelson <[EMAIL PROTECTED]> wrote: > >yes. there are a lot of pix firewalls out there with smtp fixup turned on, > >effectively disabling ESMTP (not to mention sporadically breaking > >traditional SMTP.) > Could you elaborate on this? I use PIX firewalls all over the place and > don't seem to have a problem with SMTP or ESMTP. then you must have smtp fixup disabled. when smtp fixup is on (default on many older pixes, i gather that there may be some improvements on newer pixes), the smtp banner is mostly obscured by * characters. the intent is a classic security by obscurity play, to hide the type and verison of the MTA behind the pix. the problem is two fold: 1) it obscures so much of the banner that any ESMTP advertisement in the banner is hidden, so the SMTP client doesn't know that it can EHLO. for standards compliant MTAs, the result is a default to the minimal SMTP standard mode of operation, and options such as SMTP over TLS are never negotiated even when both the SMTP client and server are "ready to go". 2) it turns out that the * obscurity ploy is badly done, and while it hides enough of the banner to break ESMTP, it doesn't hide enough of the banner to reliably obscure the MTA in use. even if security by obscurity were a good idea (i, and many others, maintain that it is not), broken security by obscurity is annoying beyond belief. on more than one occasion, i've had clients ask me to investigate why they're having obscure problems with email transactions. in many cases, i've found that telneting to port 25 on the SMTP server end has produced the "wall of asterisks", and that having them turn off smtp fixup on the pix invariably cures the problem. it's sufficiently frequent that it's generally the first thing i check for these days (it's also first because ruling it in or out is very quick.) richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Re: disabling SMTP
[3/28/2004 7:29 PM] Rob Nelson : Could you elaborate on this? I use PIX firewalls all over the place and don't seem to have a problem with SMTP or ESMTP. Check whether "smtp fixup" is enabled - and if it is, disable it using # no fixup protocol smtp 25 Test the results (from an outside host, using netcat / telnet to port 25) to see for yourself. Briefly, a pix doing "smtp fixup" - * Munges the smtp banner entirely with * (that breaks an rfc or two) * Disables ESMTP (so EHLO will not be accepted) * Munges several replies returned by the mailserver, turning them to XXX srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: disabling SMTP
yes. there are a lot of pix firewalls out there with smtp fixup turned on, effectively disabling ESMTP (not to mention sporadically breaking traditional SMTP.) Could you elaborate on this? I use PIX firewalls all over the place and don't seem to have a problem with SMTP or ESMTP. Rob Nelson [EMAIL PROTECTED] Rob Nelson [EMAIL PROTECTED]
RE: Overflow circuit
None of the satellite circuit I have worked on during the last five years has been more than 550 ms RTT. They are all C-band VSAT type systems in North America and Latin America. The economy (both $$ and quality) of satellite is such that it is only considered ... 1) No reasonably priced or reliable terrestial alternative is available. This has generally been the case for mineral exploration type operations. Political motivations have also come into play in some cases, e.g. when an unfriendly jurisdiction/neighbour exists between A and B. 2) When you don't have 2-4 weeks for all the xLEC/IXC/PTT to agree on things so that you can come up with an end-to-end build design, then spend another 6-8 weeks coordinating the build out, and it is not unusual to spend yet another week or two for the said xLEC/IXC/PTT to blame each other when the circuit won't turn up because someone left a piece of tone generating test equipment plugged in. I can turn up a sat circuit in as little as 24-hours once the teleport is in place (typically 2-3 weeks for remote locations). The same also goes for increasing/descreasing bandwidth on demand (can be very expensive). 3) When you need to reduce the number of points of failures to that single (30,000 km * 2) hop. 4) When you need a reliable/cheaper backup/overflow to the primary terrestial circuit (my original question for starting this thread ;) > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Alexei Roudnev > Sent: Saturday, March 27, 2004 11:21 PM > To: Rafi Sadowsky > Cc: Steven M. Bellovin; Michel Py; [EMAIL PROTECTED] > Subject: Re: Overflow circuit > > > 500 RTT, + 150 jitter buffer, + something else... it will be > 700 - 800 msec, more likely. When we worked with a few > sattelliite lines (5 years ago), I never saw ping rtt less > than 800 msec. Of course, it does not mean that you can not > see RTT = 500 msec (but I never saw it). > > But I was talking aboutt other thing - ~1second delay != bad > quality, it is just a delay, which means that, if you have > good echo cancellers (which is interesting question) and > follow talking discipline, you can talk without any problems. > It explains, why satellite links + VoIP can be a good > combination (moreover; after satellite delay, which is 500 - > 600 msec, VoIP additional delay ,which is 50 - 150 msec, does > not change overall delay so much, as in case of VoIP over bad > link _vs_ traditional telephony (200 msec vs 20 msec = 10 > times; 800 msec vs. 600 msec = 30%). > > > > > ## On 2004-03-27 19:30 -0800 Alexei Roudnev typed: > > > > AR> > > AR> It means, that satellite (with it's 1 second delay and > unavoidable > echo) > > > > Geosynchronous satellite IP link RTT can be just over 500 mill-sec > > (real life experience) IMHO thats a rather significant difference > > > > -- > > > > Rafi > > > > > > >
Re: Overflow circuit
Thus spake "Mailing List Subscriptions" <[EMAIL PROTECTED]> Please use your real name when posting to nanog (per the AUP). > Two private line T1's between A and B - one terrestial T1 with >200 > ms RTT, the other T1 is over satellite with ~500 ms RTT. The circuits > are being used for mixed VoIP (70%) and data (30%) applications. To > achieve optimal voice quality, we want to route all VoIP calls over the > terrestial T1 until it is "full", then divert all subsequent VoIP calls over > the satellite T1 (**while existing VoIP calls continue to be routed over > the terrestial T1). With G.729a and cRTP, you can cram over a hundred calls into a single T1; what is the average and peak usage predicted for your deployment? While I know it's not ideal, you may want to consider using CallMangler's bandwidth control features to ensure voice traffic never exceeds the T1's capacity. That way you can route all voice to the T1, all data to the satellite, and not worry about fancy load-sharing tricks. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
