Testing the route
Hello , I am trying to send a test packet to the router for which my router has received an update packet containg the route. So that i can test the route and check its validity for any false route information. also it will be helpfull to keep eye on security issues. Plz comment. Is this possible ? if not why? if yes give me your feedback.
Re: NAT Configuration for Dual WAN Router
Assuming your providers give you a new modem which is already NAT'ing the LAN side of the modem and you are plugging that into multiple NIC's on your linux router like; -modem-pub -> modem-priv -> linux-eth0 -modem-pub -> modem-priv -> linux-eth1 -linux-eth3 -> LAN switch 1) Configure VRRP (http://sourceforge.net/projects/vrrpd/) on eth0 and eth1 WAN side on the linux router. You should be able to configure the weighting on each interface equally so that they 'load share' (I've done this in FreeBSD). 2) Set the default gateway on the linux router to the VRRP interface (IP that is shared between eth0 and eth1). This would be a very scalable and reliable solution for this type of network. I've never tried it, but let me know if it works!On 12/14/05, Joe Johnson <[EMAIL PROTECTED] > wrote:I've been trying over and over to figure this one out, but I'm just hitting the end of my wits. We have a remote office that can only get 768Kbps DSL,which they've not totally maxed out. So management's solution now is to buya second DSL line, but they won't let me buy a dual WAN router (in case they add a 3rd DSL line).I've found some great articles on how to get the interfaces working with 2default gateways (I used this: http://www.linuxquestions.org/linux/answers/Networking/Spanning_Multiple_DSLs) and that is all running fine. It alternates every few minutes which WANport is used when I traceroute yahoo.com (which is fine) and everything isconnecting fine from the router. However, I can't figure out how to get NATrunning on the server for the 2 WAN ports for clients inside the LAN. I canNAT to 1 DSL, but that is useless. What I am looking for is a tutorial in how to do this or a pointer tosomeone who can help. Anyone know of a resource for this?Joe Johnson[EMAIL PROTECTED]
Team Cymru outage
Hi, NANOGers. Just a FYI - we at Team Cymru are upgrading some of our infrastructure today. This will result in partial and complete outages for most of the day. We will be back online, new and improved, by the end of the day. Thanks! Rob, for Team Cymru. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
One thing to note here is that while VoIP flows are low volume on a bits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow. And I have seen cases of older line cards approaching their pps limits when handling large numbers of VoIP flows even though there's plenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. -C On Dec 16, 2005, at 4:29 AM, [EMAIL PROTECTED] wrote: A single VoIP call is a rather slim volume of packets compared to many other uses of the Internet. If a network doesn't have systemic jitter caused by layer 2 congestion, then one would expect VoIP to work fine on a modern network. Indeed, that is what Bill Woodcock reported a year or so ago in regard to INOC-DBA. --Michael Dillon
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Chris Woodfield wrote: One thing to note here is that while VoIP flows are low volume on a bits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow. And I have seen cases of older line cards approaching their pps limits when handling large numbers of VoIP flows even though there's plenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. -C In that vein, and not quite on this topic, it would be real nice if voip applications made an effort to stop abusing networks with unneccessarily large pps. Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On 18/12/05, Chris Woodfield <[EMAIL PROTECTED]> wrote: One thing to note here is that while VoIP flows are low volume on abits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow.And I have seen cases of older line cards approaching their ppslimits when handling large numbers of VoIP flows even though there'splenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. Only older line cards ? Currently NPE-G1's are causing me more headaches in that regard. At least up until last friday. /Tony
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Joe Maimon wrote: Chris Woodfield wrote: One thing to note here is that while VoIP flows are low volume on a bits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow. And I have seen cases of older line cards approaching their pps limits when handling large numbers of VoIP flows even though there's plenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. -C In that vein, and not quite on this topic, it would be real nice if voip applications made an effort to stop abusing networks with unneccessarily large pps. VoIP by design will have high PPS per connection as opposed to data flows. At 20 ms sample rates you have 50 pps regardless of the CODEC or algorithm. Increasing the time per sample to 40 ms would cut this in half but the added latency would result in degraded quality. In addition, longer sample times would suffer much more degradation if there is packet loss. Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput. I'm not sure why you say the payload length has much to do with RTT. Serialization delay on slow edge links could increase RTT, but this would worsen substantially with longer samples (assuming the same CODEC and compression). Payload length is a factor of the sample length and compression algorithm. More efficient compression will result in smaller payloads but overhead becomes a higher percentage of the overall flow. Only lengthier samples will reduce PPS, and the added latency in a two-way conversation will substantially reduce call quality. -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] NetLojix Communications, Inc. - http://www.netlojix.com/ WestNet: Connecting you to the planet. 805 884-6323
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Sun, 18 Dec 2005, Joe Maimon wrote: Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput. What is your suggestion? High latency connections can have higher VOIP latency by increasing packet size, or "low" IP-latency connections can handle higher VOIP latency by increasing packet size? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Jay Hennigan wrote: VoIP by design will have high PPS per connection as opposed to data flows. At 20 ms sample rates you have 50 pps regardless of the CODEC or algorithm. Increasing the time per sample to 40 ms would cut this in half but the added latency would result in degraded quality. In addition, longer sample times would suffer much more degradation if there is packet loss. My point is that sampling length should take into effect the rtt. A rtt of 200ms tolerates far shorter sampling slices than does 20ms.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Mikael Abrahamsson wrote: On Sun, 18 Dec 2005, Joe Maimon wrote: Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput. What is your suggestion? High latency connections can have higher VOIP latency by increasing packet size, or "low" IP-latency connections can handle higher VOIP latency by increasing packet size? The latter.
