Re: [j-nsp] load balancing between juniper routers for unequalcostpath
As both Chuck and Leigh have stated, you CAN use GRE tunnels to do this, however, you will run into MTU size issues by doing this. You will also need tunneling/Adaptive Services/MultiServices PICs (or ASM cards if it's an M7i were dealing with) to do gre tunneling. The far cleaner way here is to follow Andy's suggestions and build 2 x RSVP signalled LSPs with strict routing options (EROs) so that they take different paths across your network, but appear to be the same metric to OSPF, hence, they will load balance. If the metrics reflect true costs and latency, then this could easily result in packet sequencing problems. The specific set of packets which would experience problems will depend on what how set the load-balancing hash-key fields. Just pointing this out in case you care... :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing between juniper routers for unequalcostpath
Hi Paul, Agreed, however, with the load-balancing export mentioned earlier, JunOS does per-flow balancing, hence, any particular session (such as a VoIP call and a stream of UDP packets) will always use the same path; thus they will still arrive in the same order at the destination router. =) Different TCP or UDP sessions will indeed have ordering problems, assuming you are trying to co-ordinate multiple flows for the same set of services on different port numbers. However, each individual TCP-connection and/or UDP flow will indeed take the same path by the hashing algorithm. Good catch.! - Chris. -Original Message- From: Paul Goyette Sent: Friday, November 09, 2007 11:29 AM To: Chris Kawchuk; 'Hamid Ahmed'; 'Andy Lamontagne' Cc: 'juniper-nsp' Subject: RE: [j-nsp] load balancing between juniper routers for unequalcostpath As both Chuck and Leigh have stated, you CAN use GRE tunnels to do this, however, you will run into MTU size issues by doing this. You will also need tunneling/Adaptive Services/MultiServices PICs (or ASM cards if it's an M7i were dealing with) to do gre tunneling. The far cleaner way here is to follow Andy's suggestions and build 2 x RSVP signalled LSPs with strict routing options (EROs) so that they take different paths across your network, but appear to be the same metric to OSPF, hence, they will load balance. If the metrics reflect true costs and latency, then this could easily result in packet sequencing problems. The specific set of packets which would experience problems will depend on what how set the load-balancing hash-key fields. Just pointing this out in case you care... :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing between juniper routers for unequalcostpath
Agreed, however, with the load-balancing export mentioned earlier, JunOS does per-flow balancing, hence, any particular session (such as a VoIP call and a stream of UDP packets) will always use the same path; thus they will still arrive in the same order at the destination router. =) True if you include the TCP/UDP port info in the hash key. But then if you send ICMP packets, those fields are occupied by the sequence number, so some ECHO REQUEST will follow one path while others go over a different path. The response will show this when you get answers for 1, 2, 5, 3, 4, ... :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
