From andhy.indarto at indosat.com Mon Mar 8 06:19:06 2010 From: andhy.indarto at indosat.com (Andhy Indarto) Date: Mon, 8 Mar 2010 18:19:06 +0700 Subject: [alcatel-nsp] Network Address Translation on 7750 Message-ID: <2233A6BE8D55AE4C9119D7870748FC311004AE23@isatjkt-msg01.office.corp.indosat.com> Dear all, Is there any features or policy or filter that have same result as NAT/PAT ? Thank you for your kind assistant. Regards, andhi indarto ***** "This message is intended only for recipients who are authorized to receive it. It contains confidential and/ or legally priveleged information belong to PT INDOSAT Tbk ("INDOSAT"), therefore the authorized recipients shall protect this confidential information disclosed pursuant to provisions of Indosat's policy. If you are not a valid recipient of this message, please delete it from your system and/ or destroy all of the tangible material produced from the information herein together with all copies or reproductions thereof and notify the sender immediately. Please also be notified that any disclosure, copying, distribution or taking any action based on the contents of this message is strictly prohibited and may be unlawful". ***** -------------- next part -------------- An HTML attachment was scrubbed... URL: From andhy.indarto at indosat.com Mon Mar 8 06:58:47 2010 From: andhy.indarto at indosat.com (Andhy Indarto) Date: Mon, 8 Mar 2010 18:58:47 +0700 Subject: [alcatel-nsp] Network Address Translation on 7750 In-Reply-To: Message-ID: <2233A6BE8D55AE4C9119D7870748FC311004AE31@isatjkt-msg01.office.corp.indosat.com> Dear sir, Thank you for your information. My TiMOS is TiMOS-C-6.1.R9 so I have to wait than ...:-) Once again thank you for your information and assistant. Regards, andhi indarto -----Original Message----- From: HENDERICKX Wim [mailto:Wim.Henderickx at alcatel-lucent.com] Sent: Monday, March 08, 2010 6:41 PM To: Andhy Indarto; alcatel-nsp at puck.nether.net Cc: Ferry Hariyanto Subject: RE: [alcatel-nsp] Network Address Translation on 7750 NAT/PAT was just released in R8.0 From: alcatel-nsp-bounces at puck.nether.net [mailto:alcatel-nsp-bounces at puck.nether.net] On Behalf Of Andhy Indarto Sent: maandag 8 maart 2010 12:19 To: alcatel-nsp at puck.nether.net Cc: Ferry Hariyanto Subject: [alcatel-nsp] Network Address Translation on 7750 Dear all, Is there any features or policy or filter that have same result as NAT/PAT ? Thank you for your kind assistant. Regards, andhi indarto ***** "This message is intended only for recipients who are authorized to receive it. It contains confidential and/ or legally priveleged information belong to PT INDOSAT Tbk ("INDOSAT"), therefore the authorized recipients shall protect this confidential information disclosed pursuant to provisions of Indosat's policy. If you are not a valid recipient of this message, please delete it from your system and/ or destroy all of the tangible material produced from the information herein together with all copies or reproductions thereof and notify the sender immediately. Please also be notified that any disclosure, copying, distribution or taking any action based on the contents of this message is strictly prohibited and may be unlawful". ***** ***** "This message is intended only for recipients who are authorized to receive it. It contains confidential and/ or legally priveleged information belong to PT INDOSAT Tbk ("INDOSAT"), therefore the authorized recipients shall protect this confidential information disclosed pursuant to provisions of Indosat's policy. If you are not a valid recipient of this message, please delete it from your system and/ or destroy all of the tangible material produced from the information herein together with all copies or reproductions thereof and notify the sender immediately. Please also be notified that any disclosure, copying, distribution or taking any action based on the contents of this message is strictly prohibited and may be unlawful". ***** -------------- next part -------------- An HTML attachment was scrubbed... URL: From rofik.alfajar at gmail.com Mon Mar 8 08:11:35 2010 From: rofik.alfajar at gmail.com (Rofik Alfajar) Date: Mon, 8 Mar 2010 20:11:35 +0700 Subject: [alcatel-nsp] Network Address Translation on 7750 In-Reply-To: <2233A6BE8D55AE4C9119D7870748FC311004AE31@isatjkt-msg01.office.corp.indosat.com> References: <2233A6BE8D55AE4C9119D7870748FC311004AE31@isatjkt-msg01.office.corp.indosat.com> Message-ID: <7ccd7b631003080511x2e8686b9tc5870ecb84742632@mail.gmail.com> Pak Andhy, Actually SR OS 8.0.R1 just released. You don't have to wait anymore... Please check the Alcatel-Lucent Customer and Business Partner Portals. But take into consideration, router with SR OS 8.0 can only be managed by 5620 SAM 8.0 BR/Rofik Alfajar On Mon, Mar 8, 2010 at 6:58 PM, Andhy Indarto wrote: > Dear sir, > > Thank you for your information. My TiMOS is TiMOS-C-6.1.R9 so I have to > wait than ?J > > Once again thank you for your information and assistant. > > Regards, > > andhi indarto > > > > -----Original Message----- > *From:* HENDERICKX Wim [mailto:Wim.Henderickx at alcatel-lucent.com] > *Sent:* Monday, March 08, 2010 6:41 PM > *To:* Andhy Indarto; alcatel-nsp at puck.nether.net > *Cc:* Ferry Hariyanto > *Subject:* RE: [alcatel-nsp] Network Address Translation on 7750 > > > > NAT/PAT was just released in R8.0 > > > > *From:* alcatel-nsp-bounces at puck.nether.net [mailto: > alcatel-nsp-bounces at puck.nether.net] *On Behalf Of *Andhy Indarto > *Sent:* maandag 8 maart 2010 12:19 > *To:* alcatel-nsp at puck.nether.net > *Cc:* Ferry Hariyanto > *Subject:* [alcatel-nsp] Network Address Translation on 7750 > > > > Dear all, > > Is there any features or policy or filter that have same result as NAT/PAT > ? > > Thank you for your kind assistant. > > Regards, > > andhi indarto > > > > > > > > ***** > > "This message is intended only for recipients who are authorized to receive it. > > It contains confidential and/ or legally priveleged information belong to PT INDOSAT Tbk ("INDOSAT"), therefore the authorized recipients shall protect this confidential information disclosed pursuant to provisions of Indosat's policy. > > If you are not a valid recipient of this message, please delete it from your system and/ or destroy all of the tangible material produced from the information herein together with all copies or reproductions thereof and notify the sender immediately. > > Please also be notified that any disclosure, copying, distribution or taking any action based on the contents of this message is strictly prohibited and may be unlawful". > > ***** > > > > > ***** > "This message is intended only for recipients who are authorized to receive it. > It contains confidential and/ or legally priveleged information belong to PT INDOSAT Tbk ("INDOSAT"), therefore the authorized recipients shall protect this confidential information disclosed pursuant to provisions of Indosat's policy. > If you are not a valid recipient of this message, please delete it from your system and/ or destroy all of the tangible material produced from the information herein together with all copies or reproductions thereof and notify the sender immediately. > Please also be notified that any disclosure, copying, distribution or taking any action based on the contents of this message is strictly prohibited and may be unlawful". > ***** > > > _______________________________________________ > alcatel-nsp mailing list > alcatel-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/alcatel-nsp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Mon Mar 8 13:44:24 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 10:44:24 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308104424.2BF59565@resin14.mta.everyone.net> I am seeing several cases of Gigabit Ethernet circuits in a LAG with a large difference in traffic levels. For example, in one LAG I have one GigE at 45Mbps and the other at 550Mbps. Has anyone else seen this and have an understanding of why? It's only on a few LAGs in a network of many LAGs. scott From surfer at mauigateway.com Mon Mar 8 15:26:43 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 12:26:43 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308122643.2BF5FF48@resin14.mta.everyone.net> -----Original Message----- I am seeing several cases of Gigabit Ethernet circuits in a LAG with a large difference in traffic levels. For example, in one LAG I have one GigE at 45Mbps and the other at 550Mbps. Has anyone else seen this and have an understanding of why? It's only on a few LAGs in a network of many LAGs. --- Wim.Henderickx at alcatel-lucent.com wrote: Can you tell which services are running on the LAG ? ------------------------------------------------ These're between 7750-to-7750 core MPLS routers. We use many services, such as VPRNs, VPLSs and epipes, but they all don't extend to all access 7450s. So it'd be realy hard to tell. Do some service types cause a different hashing such that I'd see a very large difference in traffic? In a network with many 10s of LAGs only 2 are exhibiting this behavior. Both LAGs are made up of 2 GigEs. One is balancing at 42Mbps/550Mbps and the other is 65Mbps/230Mbps. scott --------------------- ------------------------ -------------------------- From sgridelli at gmail.com Mon Mar 8 15:40:14 2010 From: sgridelli at gmail.com (Stefano Gridelli) Date: Mon, 8 Mar 2010 15:40:14 -0500 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <20100308104424.2BF59565@resin14.mta.everyone.net> References: <20100308104424.2BF59565@resin14.mta.everyone.net> Message-ID: Any rate statement at the port level? On 3/8/10, Scott Weeks wrote: > > > I am seeing several cases of Gigabit Ethernet circuits in a LAG with a large > difference in traffic levels. For example, in one LAG I have one GigE at > 45Mbps and the other at 550Mbps. Has anyone else seen this and have an > understanding of why? It's only on a few LAGs in a network of many LAGs. > > scott > _______________________________________________ > alcatel-nsp mailing list > alcatel-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/alcatel-nsp > -- Sent from my mobile device From surfer at mauigateway.com Mon Mar 8 16:09:05 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 13:09:05 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308130905.2BF5F797@resin14.mta.everyone.net> On 3/8/10, Scott Weeks wrote: > I am seeing several cases of Gigabit Ethernet circuits in a LAG with a large > difference in traffic levels. For example, in one LAG I have one GigE at > 45Mbps and the other at 550Mbps. Has anyone else seen this and have an > understanding of why? It's only on a few LAGs in a network of many LAGs. --- sgridelli at gmail.com wrote: From: Stefano Gridelli Any rate statement at the port level? --------------------------------------------- No, they're configured the same as all the others that're not exhibiting this behavior. scott -------------------- ------------------ --------------------- From surfer at mauigateway.com Mon Mar 8 16:16:19 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 13:16:19 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308131619.2BF5F538@resin14.mta.everyone.net> --- Wim.Henderickx at alcatel-lucent.com wrote: From: "HENDERICKX Wim" No we don't have that. We recently did a test where we had a lag link of 4 links and we had almost equal traffic balancing with r8. -------------------------------------------------- I'm not so worried about them being almost equal. I am worried about them being *very* unbalanced and I was hoping to have a way to see if there is anything wrong when the configs are the same as other LAGs that are not exhibiting this behavior. On one pair of 7750s: Gig 1 LAG 1: 42Mbps Gig 2 LAG 1: 550Mbps More than 10 times difference on different 7750s: Gig 1 LAG 2: 65Mbps Gig 2 LAG 2: 230Mbps 3.5 times difference. Other LAGS we have are much closer in traffic levels. scott ------------------- ------------------- --------------------- From Ryan.Landry at TELUS.COM Mon Mar 8 16:55:02 2010 From: Ryan.Landry at TELUS.COM (Ryan Landry) Date: Mon, 8 Mar 2010 14:55:02 -0700 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <20100308131619.2BF5F538@resin14.mta.everyone.net> References: <20100308131619.2BF5F538@resin14.mta.everyone.net> Message-ID: On 2010-03-08, at 2:16 PM, Scott Weeks wrote: > > > --- Wim.Henderickx at alcatel-lucent.com wrote: > From: "HENDERICKX Wim" > > No we don't have that. We recently did a test where we had a lag link of 4 links and we had almost equal traffic balancing with r8. > -------------------------------------------------- > > > I'm not so worried about them being almost equal. I am worried about them being *very* unbalanced and I was hoping to have a way to see if there is anything wrong when the configs are the same as other LAGs that are not exhibiting this behavior. > > On one pair of 7750s: > > Gig 1 LAG 1: 42Mbps > Gig 2 LAG 1: 550Mbps > > More than 10 times difference > > > > on different 7750s: > > Gig 1 LAG 2: 65Mbps > Gig 2 LAG 2: 230Mbps > > 3.5 times difference. > > > Other LAGS we have are much closer in traffic levels. > scott > these are network or access lag ports? any recent failures within the bundle? are you pushing multicast across by chance? which TiMOS? From surfer at mauigateway.com Mon Mar 8 18:20:00 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 15:20:00 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308152000.2BF5DB12@resin14.mta.everyone.net> --- Ryan.Landry at TELUS.COM wrote: From: Ryan Landry On 2010-03-08, at 2:16 PM, Scott Weeks wrote: > --- Wim.Henderickx at alcatel-lucent.com wrote: > From: "HENDERICKX Wim" > > No we don't have that. We recently did a test where we had a lag link of 4 links and we had almost equal traffic balancing with r8. > -------------------------------------------------- > I'm not so worried about them being almost equal. I am worried about them being *very* unbalanced and I was hoping to have a way to see if there is anything wrong when the configs are the same as other LAGs that are not exhibiting this behavior. these are network or access lag ports? any recent failures within the bundle? are you pushing multicast across by chance? which TiMOS? ------------------------------------ They're network LAGs, no recent failures, no multicast and both 6.0r11 and 7.0r7 scott From surfer at mauigateway.com Mon Mar 8 18:37:28 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 15:37:28 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308153728.2C03D45A@resin16.mta.everyone.net> --- Ryan.Landry at TELUS.COM wrote: also, what is 'tools dump lag lag-id ' showing you for each port's bandwidth? -------------------------------------- That one's kinda long, but here it goes... ;-) *A:WLKU7750# tools dump lag lag-id 2 Port state : Up Selected subgrp : 1 NumActivePorts : 2 ThresholdRising : 12 ThresholdFalling: 4 IOM bitmask : 6 Config MTU : 9212 Oper. MTU : 9212 Bandwidth : 2000000 multi-chassis : NO ------------------------------------------------------------------------------------ Indx PortId RX pkts TX pkts State Active Port Cfg Oper Speed BW AP CS Pri Mtu Mtu ------------------------------------------------------------------------------------ 0 1/1/2 556699363199 311450362191 Up yes 32768 9212 9212 1000000 0 2 1 2/1/2 304080315493 314231853533 Up yes 32768 9212 9212 1000000 0 2 ------Port 1/1/2 LACP info------ RX sm state......CURRENT PT sm state......FAST_PERIODIC MUX sm state.....COLLECTING_DISTRIBUTING begin............FALSE NTT..............FALSE lacpEnbld........TRUE ready_N..........FALSE selected.........SELECTED portMoved........FALSE portEnabled......TRUE txTimestamp 0....3079994462 txTimestamp 1....3079994264 txTimestamp 2....3079994362 nextTxTimestamp..1 pLacpPdu.........0x0 subGrpId.........1 isCollDistr......TRUE currentWhileTimerExpired..FALSE periodicTimerExpired......FALSE PrtrOprSysPri : 32768 PrtrOprSysId : 00:03:fa:c1:69:f8 PrtrOprkey : 3331 ------Port 2/1/2 LACP info------ RX sm state......CURRENT PT sm state......FAST_PERIODIC MUX sm state.....COLLECTING_DISTRIBUTING begin............FALSE NTT..............FALSE lacpEnbld........TRUE ready_N..........FALSE selected.........SELECTED portMoved........FALSE portEnabled......TRUE txTimestamp 0....3079994462 txTimestamp 1....3079994562 txTimestamp 2....3079994662 nextTxTimestamp..0 pLacpPdu.........0x0 subGrpId.........1 isCollDistr......TRUE currentWhileTimerExpired..FALSE periodicTimerExpired......FALSE PrtrOprSysPri : 32768 PrtrOprSysId : 00:03:fa:c1:69:f8 PrtrOprkey : 3331 From Ryan.Landry at TELUS.COM Mon Mar 8 16:56:56 2010 From: Ryan.Landry at TELUS.COM (Ryan Landry) Date: Mon, 8 Mar 2010 14:56:56 -0700 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <20100308131619.2BF5F538@resin14.mta.everyone.net> References: <20100308131619.2BF5F538@resin14.mta.everyone.net> Message-ID: <304DFA6D-3371-4C90-B86A-EC2608CB4C23@telus.com> On 2010-03-08, at 2:16 PM, Scott Weeks wrote: > > > --- Wim.Henderickx at alcatel-lucent.com wrote: > From: "HENDERICKX Wim" > > No we don't have that. We recently did a test where we had a lag link of 4 links and we had almost equal traffic balancing with r8. > -------------------------------------------------- > > > I'm not so worried about them being almost equal. I am worried about them being *very* unbalanced and I was hoping to have a way to see if there is anything wrong when the configs are the same as other LAGs that are not exhibiting this behavior. > > On one pair of 7750s: > > Gig 1 LAG 1: 42Mbps > Gig 2 LAG 1: 550Mbps > > More than 10 times difference > > > > on different 7750s: > > Gig 1 LAG 2: 65Mbps > Gig 2 LAG 2: 230Mbps > > 3.5 times difference. > > > Other LAGS we have are much closer in traffic levels. > scott > also, what is 'tools dump lag lag-id ' showing you for each port's bandwidth? From surfer at mauigateway.com Mon Mar 8 18:52:36 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 15:52:36 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308155236.2C03D279@resin16.mta.everyone.net> --- Ryan.Landry at TELUS.COM wrote: also, what is 'tools dump lag lag-id ' showing you for each port's bandwidth? --------------------------------------- My apologies, I should read better. You just wanted the BWs. They're the same on all ends: *A:WLKU7750# tools dump lag lag-id 2 Bandwidth : 2000000 *A:KAIL7750# tools dump lag lag-id 3 Bandwidth : 2000000 I also checked all the other info in the output of "tools dump lag lag-id X" and all looks good AFAICT. scott From philxor at gmail.com Mon Mar 8 18:47:39 2010 From: philxor at gmail.com (Phil Bedard) Date: Mon, 8 Mar 2010 18:47:39 -0500 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <20100308153728.2C03D45A@resin16.mta.everyone.net> References: <20100308153728.2C03D45A@resin16.mta.everyone.net> Message-ID: <78C98768-6484-455C-B71E-2C65DCF6E19A@gmail.com> I guess it's hard to know exactly which services are flowing across the link but if it's only acting as an LSR then it should be hashing based on the MPLS stack (Up to 5 labels), ingress port, and system ID. Are there any potential really high BW services across the LAG? With the IOM3/IMM you can have it hash on both the labels and the IPv4 header, but not on the IOM2. If there are services originating on the box there are all kinds of rules on how things are hashed on egress, but LSR it's pretty simple. Phil On Mar 8, 2010, at 6:37 PM, Scott Weeks wrote: > > > --- Ryan.Landry at TELUS.COM wrote: > also, what is 'tools dump lag lag-id ' showing you for each port's bandwidth? > -------------------------------------- > > That one's kinda long, but here it goes... ;-) > > > > *A:WLKU7750# tools dump lag lag-id 2 > > Port state : Up > Selected subgrp : 1 > NumActivePorts : 2 > ThresholdRising : 12 > ThresholdFalling: 4 > IOM bitmask : 6 > Config MTU : 9212 > Oper. MTU : 9212 > Bandwidth : 2000000 > > multi-chassis : NO > > ------------------------------------------------------------------------------------ > Indx PortId RX pkts TX pkts State Active Port Cfg Oper Speed BW AP CS > Pri Mtu Mtu > ------------------------------------------------------------------------------------ > 0 1/1/2 556699363199 311450362191 Up yes 32768 9212 9212 1000000 0 2 > 1 2/1/2 304080315493 314231853533 Up yes 32768 9212 9212 1000000 0 2 > > ------Port 1/1/2 LACP info------ > > RX sm state......CURRENT > PT sm state......FAST_PERIODIC > MUX sm state.....COLLECTING_DISTRIBUTING > > begin............FALSE > NTT..............FALSE > lacpEnbld........TRUE > ready_N..........FALSE > selected.........SELECTED > portMoved........FALSE > portEnabled......TRUE > txTimestamp 0....3079994462 > txTimestamp 1....3079994264 > txTimestamp 2....3079994362 > nextTxTimestamp..1 > pLacpPdu.........0x0 > subGrpId.........1 > isCollDistr......TRUE > > currentWhileTimerExpired..FALSE > periodicTimerExpired......FALSE > > PrtrOprSysPri : 32768 > PrtrOprSysId : 00:03:fa:c1:69:f8 > PrtrOprkey : 3331 > > ------Port 2/1/2 LACP info------ > > RX sm state......CURRENT > PT sm state......FAST_PERIODIC > MUX sm state.....COLLECTING_DISTRIBUTING > > begin............FALSE > NTT..............FALSE > lacpEnbld........TRUE > ready_N..........FALSE > selected.........SELECTED > portMoved........FALSE > portEnabled......TRUE > txTimestamp 0....3079994462 > txTimestamp 1....3079994562 > txTimestamp 2....3079994662 > nextTxTimestamp..0 > pLacpPdu.........0x0 > subGrpId.........1 > isCollDistr......TRUE > > currentWhileTimerExpired..FALSE > periodicTimerExpired......FALSE > > PrtrOprSysPri : 32768 > PrtrOprSysId : 00:03:fa:c1:69:f8 > PrtrOprkey : 3331 > > > > _______________________________________________ > alcatel-nsp mailing list > alcatel-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/alcatel-nsp From surfer at mauigateway.com Mon Mar 8 19:17:46 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Mar 2010 16:17:46 -0800 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG Message-ID: <20100308161746.2C002ECA@resin16.mta.everyone.net> --- philxor at gmail.com wrote: From: Phil Bedard I guess it's hard to know exactly which services are flowing across the link but if it's only acting as an LSR then it should be hashing based on the MPLS stack (Up to 5 labels), ingress port, and system ID. Are there any potential really high BW services across the LAG? With the IOM3/IMM you can have it hash on both the labels and the IPv4 header, but not on the IOM2. If there are services originating on the box there are all kinds of rules on how things are hashed on egress, but LSR it's pretty simple. -------------------------------------- We carry our internet traffic in a VPRN. This is 99+% of all traffic. I'm guess I'm going to have to go with just 2 cases of bad load balancing. The network goes something like this: br1 br2 | | | | 7750----7750 |\ /| | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | |/ \| 7750----7750====7750 ^ | No links are full. The 'middle' is 10G and the 'edges' are multi-GigE. br1 has about twice the bandwidth as br2, so perhaps the label from br2 is hashed over one of the 2 GigEs (above the arrow) and the label of br1 is over the other and it's just a case of bad load balancing. More that 10 to 1, though, seems excessive. Thank you everyone on and off-list for your help. :-) scott From Ryan.Landry at TELUS.COM Mon Mar 8 19:40:15 2010 From: Ryan.Landry at TELUS.COM (Ryan Landry) Date: Mon, 8 Mar 2010 17:40:15 -0700 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <20100308161746.2C002ECA@resin16.mta.everyone.net> References: <20100308161746.2C002ECA@resin16.mta.everyone.net> Message-ID: <303DA33A-E810-4155-A756-BAB7B397E449@telus.com> On 2010-03-08, at 5:17 PM, Scott Weeks wrote: > > --- philxor at gmail.com wrote: > From: Phil Bedard > > I guess it's hard to know exactly which services are flowing across the > link but if it's only acting as an LSR then it should be hashing based > on the MPLS stack (Up to 5 labels), ingress port, and system ID. Are > there any potential really high BW services across the LAG? With the > IOM3/IMM you can have it hash on both the labels and the IPv4 header, > but not on the IOM2. > > If there are services originating on the box there are all kinds of > rules on how things are hashed on egress, but LSR it's pretty simple. > -------------------------------------- > > > We carry our internet traffic in a VPRN. This is 99+% of all traffic. > I'm guess I'm going to have to go with just 2 cases of bad load > balancing. The network goes something like this: > > > br1 br2 > | | > | | > 7750----7750 > |\ /| > | \ / | > | \ / | > | \ / | > | X | > | / \ | > | / \ | > | / \ | > |/ \| > 7750----7750====7750 > ^ > | > > > No links are full. The 'middle' is 10G and the 'edges' are multi-GigE. br1 has about twice the bandwidth as br2, so perhaps the label from br2 is hashed over one of the 2 GigEs (above the arrow) and the label of br1 is over the other and it's just a case of bad load balancing. More that 10 to 1, though, seems excessive. > > > Thank you everyone on and off-list for your help. :-) > scott well, you carry your inet in a vprn, so this may not be applicable, but you can included L4 in the hash algorithm. i haven't tested it nor had need for it. configure system l4-load-balancing configure port eth load-bal include-l4|exclude-l4 other than that, i've really had no problems with load being split unevenly, be it ECMP or LAG, in the lab or otherwise. does your dst inet traffic basically have one egress LSR? ie: maybe you just don't have a lot of src/dst to hash against. g'luck. .rL From Ryan.Landry at TELUS.COM Mon Mar 8 19:47:38 2010 From: Ryan.Landry at TELUS.COM (Ryan Landry) Date: Mon, 8 Mar 2010 17:47:38 -0700 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <303DA33A-E810-4155-A756-BAB7B397E449@telus.com> References: <20100308161746.2C002ECA@resin16.mta.everyone.net> <303DA33A-E810-4155-A756-BAB7B397E449@telus.com> Message-ID: <5AC8D2BD-F063-460F-9C98-8AB2589CFA3A@telus.com> On 2010-03-08, at 5:40 PM, Ryan Landry wrote: > > On 2010-03-08, at 5:17 PM, Scott Weeks wrote: > >> >> --- philxor at gmail.com wrote: >> From: Phil Bedard >> >> I guess it's hard to know exactly which services are flowing across the >> link but if it's only acting as an LSR then it should be hashing based >> on the MPLS stack (Up to 5 labels), ingress port, and system ID. Are >> there any potential really high BW services across the LAG? With the >> IOM3/IMM you can have it hash on both the labels and the IPv4 header, >> but not on the IOM2. >> >> If there are services originating on the box there are all kinds of >> rules on how things are hashed on egress, but LSR it's pretty simple. >> -------------------------------------- >> >> >> We carry our internet traffic in a VPRN. This is 99+% of all traffic. >> I'm guess I'm going to have to go with just 2 cases of bad load >> balancing. The network goes something like this: >> >> >> br1 br2 >> | | >> | | >> 7750----7750 >> |\ /| >> | \ / | >> | \ / | >> | \ / | >> | X | >> | / \ | >> | / \ | >> | / \ | >> |/ \| >> 7750----7750====7750 >> ^ >> | >> >> >> No links are full. The 'middle' is 10G and the 'edges' are multi-GigE. br1 has about twice the bandwidth as br2, so perhaps the label from br2 is hashed over one of the 2 GigEs (above the arrow) and the label of br1 is over the other and it's just a case of bad load balancing. More that 10 to 1, though, seems excessive. >> >> >> Thank you everyone on and off-list for your help. :-) >> scott > > well, you carry your inet in a vprn, so this may not be applicable, but you can included L4 in the hash algorithm. i haven't tested it nor had need for it. > > configure system l4-load-balancing > configure port eth load-bal include-l4|exclude-l4 > > other than that, i've really had no problems with load being split unevenly, be it ECMP or LAG, in the lab or otherwise. > > does your dst inet traffic basically have one egress LSR? ie: maybe you just don't have a lot of src/dst to hash against. > > g'luck. > > .rL yeah, so you answered my question before i even answered it. my apologies for not reading the whole thing thru before replying. .rL From philxor at gmail.com Mon Mar 8 22:10:43 2010 From: philxor at gmail.com (Phil Bedard) Date: Mon, 8 Mar 2010 22:10:43 -0500 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <20100308161746.2C002ECA@resin16.mta.everyone.net> References: <20100308161746.2C002ECA@resin16.mta.everyone.net> Message-ID: <7B6EC5F3-36AB-4477-AEA2-C11439871163@gmail.com> If your best path for the majority of VPRN routes is one exit router (next-hop), all of that traffic will only take one physical link due the routes using the same VPN label. 8.0 supports entropy labels, where the PE uses a hash based on the incoming IPv4 src/dst to create a new bottom of stack label. ALU uses a reserved set of labels 512k-1M so when the label hits the egress PE it knows it is an entropy label. It's meant to solve the problem you are seeing, but it requires 8.0 and chassis-mode C (all IOM-2s). Phil On Mar 8, 2010, at 7:17 PM, Scott Weeks wrote: > > --- philxor at gmail.com wrote: > From: Phil Bedard > > I guess it's hard to know exactly which services are flowing across the > link but if it's only acting as an LSR then it should be hashing based > on the MPLS stack (Up to 5 labels), ingress port, and system ID. Are > there any potential really high BW services across the LAG? With the > IOM3/IMM you can have it hash on both the labels and the IPv4 header, > but not on the IOM2. > > If there are services originating on the box there are all kinds of > rules on how things are hashed on egress, but LSR it's pretty simple. > -------------------------------------- > > > We carry our internet traffic in a VPRN. This is 99+% of all traffic. > I'm guess I'm going to have to go with just 2 cases of bad load > balancing. The network goes something like this: > > > br1 br2 > | | > | | > 7750----7750 > |\ /| > | \ / | > | \ / | > | \ / | > | X | > | / \ | > | / \ | > | / \ | > |/ \| > 7750----7750====7750 > ^ > | > > > No links are full. The 'middle' is 10G and the 'edges' are multi-GigE. br1 has about twice the bandwidth as br2, so perhaps the label from br2 is hashed over one of the 2 GigEs (above the arrow) and the label of br1 is over the other and it's just a case of bad load balancing. More that 10 to 1, though, seems excessive. > > > Thank you everyone on and off-list for your help. :-) > scott > _______________________________________________ > alcatel-nsp mailing list > alcatel-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/alcatel-nsp From Diego.Garcia_Del_Rio at alcatel-lucent.com Mon Mar 8 22:10:33 2010 From: Diego.Garcia_Del_Rio at alcatel-lucent.com (GARCIA DEL RIO Diego) Date: Tue, 9 Mar 2010 04:10:33 +0100 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG In-Reply-To: <20100308161746.2C002ECA@resin16.mta.everyone.net> References: <20100308161746.2C002ECA@resin16.mta.everyone.net> Message-ID: <9E5A55C2D9FF54418F0FF0E9F3EAC2C102F5AE2C@FRVELSMBS22.ad2.ad.alcatel.com> Hi Guys, The load balancing really depends on whether the system can see the IP or MAC layer of the services or not, so, if the node is taking traffic through a SAP or a network port but traffic is pure IP-over-Ethernet when it enters the node, then traffic will be nicely balanced and hashed based on SRC/DST ports and IPs. If the node is acting as a pure LSR, though, we don't normally look at the upper layers (anything beyond the label stack) as this can cause some issues with Ethernet-over-MPLS traffic being mistakenly identified as IPv4 or IPv6 (if a 0x4 or 0x6 is present where the IP version field is, we would identify the packet as IP while its in reality Ethernet). 7.0 R5 (I think) introduced the following command: configure system lsr-load-balancing lbl-ip which allows you to look at both IP and MPLS layers in an LSR node. This should really be used in pure IP environments, though in some cases, it might be applicable to mixed services (L2 MPLS VPNs and L3 MPLS VPNs). Please check the documentation and your local Alcatel-Lucent point of contact for more information. Cheers, Diego Garcia del Rio 701 E. Middlefield Rd Mountain View CA 94043 Mobile: +1 (415) 439-9420 OnNet: 2852-2726 -----Original Message----- From: alcatel-nsp-bounces at puck.nether.net [mailto:alcatel-nsp-bounces at puck.nether.net] On Behalf Of Scott Weeks Sent: Monday, 8 March 2010 4:18 PM To: alcatel-nsp at puck.nether.net Subject: Re: [alcatel-nsp] unbalanced traffic on GigEs in a LAG --- philxor at gmail.com wrote: From: Phil Bedard I guess it's hard to know exactly which services are flowing across the link but if it's only acting as an LSR then it should be hashing based on the MPLS stack (Up to 5 labels), ingress port, and system ID. Are there any potential really high BW services across the LAG? With the IOM3/IMM you can have it hash on both the labels and the IPv4 header, but not on the IOM2. If there are services originating on the box there are all kinds of rules on how things are hashed on egress, but LSR it's pretty simple. -------------------------------------- We carry our internet traffic in a VPRN. This is 99+% of all traffic. I'm guess I'm going to have to go with just 2 cases of bad load balancing. The network goes something like this: br1 br2 | | | | 7750----7750 |\ /| | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | |/ \| 7750----7750====7750 ^ | No links are full. The 'middle' is 10G and the 'edges' are multi-GigE. br1 has about twice the bandwidth as br2, so perhaps the label from br2 is hashed over one of the 2 GigEs (above the arrow) and the label of br1 is over the other and it's just a case of bad load balancing. More that 10 to 1, though, seems excessive. Thank you everyone on and off-list for your help. :-) scott _______________________________________________ alcatel-nsp mailing list alcatel-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/alcatel-nsp From saveliev at mostelekom.net Tue Mar 9 02:03:44 2010 From: saveliev at mostelekom.net (Alexander Saveliev) Date: Tue, 9 Mar 2010 10:03:44 +0300 Subject: [alcatel-nsp] unbalanced traffic on GigEs in a LAG References: <20100308122643.2BF5FF48@resin14.mta.everyone.net> Message-ID: <0a5401cabf56$a89992d0$25e6a8c0@wssaveliev> Hello! We had same problem two years ago. SR-routers assign labels for L3 VPNs on per-vpn basis. And balances traffic on P-router--P-router links only with MPLS header. This is true for iom1 and iom-20g-b and for Release 6.1 and earlier. We tried to L4-headers method, but we didn't see that it worked. The way to solve the problem with SR-router is to buy new iom2 cards and use entropy labels, or to buy new iom3/imm cards and use 'lsr-load-balancing lbl-ip' method. Today we have a LAG on imm's and it balances fine. But for the whole network upgrade we thought that it would be economicaly better not to buy many new SR line cards, but to build a DWDM network. So we do not have now P-router--P-router links with traffic from several 7750 PE-routers. We have only PE-PE links. ----- Original Message ----- From: "Scott Weeks" To: Sent: Monday, March 08, 2010 11:26 PM Subject: Re: [alcatel-nsp] unbalanced traffic on GigEs in a LAG > > > -----Original Message----- > > I am seeing several cases of Gigabit Ethernet circuits in a LAG with a > large difference in traffic levels. For example, in one LAG I have one > GigE at 45Mbps and the other at 550Mbps. Has anyone else seen this and > have an understanding of why? It's only on a few LAGs in a network of > many LAGs. > > > --- Wim.Henderickx at alcatel-lucent.com wrote: > > Can you tell which services are running on the LAG ? > ------------------------------------------------ > > > > These're between 7750-to-7750 core MPLS routers. We use many services, > such as VPRNs, VPLSs and epipes, but they all don't extend to all access > 7450s. So it'd be realy hard to tell. > > Do some service types cause a different hashing such that I'd see a very > large difference in traffic? In a network with many 10s of LAGs only 2 > are exhibiting this behavior. Both LAGs are made up of 2 GigEs. One is > balancing at 42Mbps/550Mbps and the other is 65Mbps/230Mbps. > > scott > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------- > ------------------------ > -------------------------- > _______________________________________________ > alcatel-nsp mailing list > alcatel-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/alcatel-nsp From himawanam at gmail.com Wed Mar 24 00:57:06 2010 From: himawanam at gmail.com (Achmad Himawan) Date: Wed, 24 Mar 2010 11:57:06 +0700 Subject: [alcatel-nsp] Regex Message-ID: Hi all, Implemented 7710SR (TiMOS-B-5.0.R13) as Internet Gateway running BGP, we need to do specific as-path filtering. Some command, eg "show router bgp routes aspath-regex _ASN$" responded by "MINOR: CLI Invalid regular expression." But I have tested this regex format on an IOS engine, and its working. Is there any clue on this? Thanks for the help. Rgds, =Achmad -------------- next part -------------- An HTML attachment was scrubbed... URL: From rus-p at mostelekom.net Wed Mar 24 03:04:17 2010 From: rus-p at mostelekom.net (Ruslan Pustovoitov) Date: Wed, 24 Mar 2010 10:04:17 +0300 Subject: [alcatel-nsp] Regex In-Reply-To: References: Message-ID: <4BA9B971.1050502@mostelekom.net> Hi, Achmad I know that regex is relatively new in TiMOS. Try to upgrade code version to 7.x In my 7.0.R6 and 7750 SR it works as expected Achmad Himawan ?????: > Hi all, > > Implemented 7710SR (TiMOS-B-5.0.R13) as Internet Gateway running BGP, > we need to do specific as-path filtering. > > Some command, eg "show router bgp routes aspath-regex _ASN$" responded > by "MINOR: CLI Invalid regular expression." > But I have tested this regex format on an IOS engine, and its working. > > Is there any clue on this? > > Thanks for the help. > > Rgds, > =Achmad > ------------------------------------------------------------------------ > > _______________________________________________ > alcatel-nsp mailing list > alcatel-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/alcatel-nsp > From surfer at mauigateway.com Wed Mar 24 03:38:23 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 24 Mar 2010 00:38:23 -0700 Subject: [alcatel-nsp] Regex Message-ID: <20100324003823.7FC3E0AF@resin05.mta.everyone.net> ---------- himawanam at gmail.com wrote: ---------- From: Achmad Himawan Implemented 7710SR (TiMOS-B-5.0.R13) as Internet Gateway running BGP, we need to do specific as-path filtering. Some command, eg "show router bgp routes aspath-regex _ASN$" responded by "MINOR: CLI Invalid regular expression." But I have tested this regex format on an IOS engine, and its working. Is there any clue on this? --------------------------------------------------------------- It's more like Unix, rather than cisco. Look in Alcatel's "Basic System Configuration Guide" on page 41. show router bgp routes aspath-regex ".*36149$" scott ------------------- ------------- ----------------- From surfer at mauigateway.com Wed Mar 24 03:43:03 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 24 Mar 2010 00:43:03 -0700 Subject: [alcatel-nsp] Regex Message-ID: <20100324004303.7FC3E09D@resin05.mta.everyone.net> BTW, the below was run on TiMOS-B-6.0.R8. : show router bgp routes aspath-regex ".*36149$" scott -------------------- ------------------- ------------------ ------------------- ------------- ----------------- From geje at nextgentel.com Wed Mar 24 08:13:10 2010 From: geje at nextgentel.com (Geir Jensen) Date: Wed, 24 Mar 2010 13:13:10 +0100 Subject: [alcatel-nsp] 7750 SR as Internet Peering Router In-Reply-To: References: Message-ID: <84FB94BF572F554792F1BD88268F0FA90B153CC3@NGT-BGO-EX-01.nextgentel.corp> Hi all, Are any of you using the 7750 SR as Internet Peering router. And if you do, how will you rate it compared to juiper/cisco? Rgds Geir -------------- next part -------------- An HTML attachment was scrubbed... URL: From sliplever at gmail.com Wed Mar 24 09:24:54 2010 From: sliplever at gmail.com (Dan Snyder) Date: Wed, 24 Mar 2010 09:24:54 -0400 Subject: [alcatel-nsp] 7750 SR as Internet Peering Router In-Reply-To: <84FB94BF572F554792F1BD88268F0FA90B153CC3@NGT-BGO-EX-01.nextgentel.corp> References: <84FB94BF572F554792F1BD88268F0FA90B153CC3@NGT-BGO-EX-01.nextgentel.corp> Message-ID: On Mar 24, 2010, at 8:13 AM, "Geir Jensen" wrote: > Hi all, > > > > Are any of you using the 7750 SR as Internet Peering router. And > if you do, how will you rate it compared to juiper/cisco? > > > > Rgds > > Geir > I can let you know in a couple months. We are planning on replacing a couple of Cisco XR12K's with 7750's. -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rofik.alfajar at gmail.com Wed Mar 24 10:43:51 2010 From: rofik.alfajar at gmail.com (Rofik Alfajar) Date: Wed, 24 Mar 2010 21:43:51 +0700 Subject: [alcatel-nsp] 7750 SR as Internet Peering Router In-Reply-To: References: <84FB94BF572F554792F1BD88268F0FA90B153CC3@NGT-BGO-EX-01.nextgentel.corp> Message-ID: <7ccd7b631003240743p74ed6f60v676654b33e02873d@mail.gmail.com> Hi Geir, I've one customer in Indonesia which using 7710 SRc12 global routing and one customer using 7750 SR7 under VPRN to peer to the upstream provider. Currently handle more than 300K BGP active routes. Customer looks satisfied, formerly they use couple M7i and looks disappointed due to 1 GE interface(s) is not line rate BR/Rofik On Wed, Mar 24, 2010 at 8:24 PM, Dan Snyder wrote: > > > On Mar 24, 2010, at 8:13 AM, "Geir Jensen" wrote: > > Hi all, > > > > Are any of you using the 7750 SR as Internet Peering router. And if you > do, how will you rate it compared to juiper/cisco? > > > > Rgds > > Geir > > > I can let you know in a couple months. We are planning on replacing a > couple of Cisco XR12K's with 7750's. > > -Dan > > > > _______________________________________________ > alcatel-nsp mailing list > alcatel-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/alcatel-nsp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Wed Mar 24 13:15:21 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 24 Mar 2010 10:15:21 -0700 Subject: [alcatel-nsp] 7750 SR as Internet Peering Router Message-ID: <20100324101521.7FC43C88@resin15.mta.everyone.net> --- geje at nextgentel.com wrote: From: "Geir Jensen" Are any of you using the 7750 SR as Internet Peering router. And if you do, how will you rate it compared to juiper/cisco? -------------------------------------------- We currently use 7710s for upstream BGP peering, but will be moving to 7750s soon. We use 7750s to peer with our downstream customers and they work perfectly fine. The issue for you would revolve around the rest of your network. Will it be Alcatel 7750/7450? If not, there will be a learning curve because the OS is so different. If your level 1 folks are not so experienced they could have trouble switching back and forth between the cisco and Alcatel operating systems, which may mean more 3am trouble calls for you. ;-) The Alcatel OS is more like Juniper than cisco. scott -------------------- ------------------ ------------------