[c-nsp] EoMPLS with Port-channel with 8GE interfaces.

[Koen]

Hi,

I'm a colleague of Maarten also looking into this problem.

Egress traffic from the router to the switch is going through one 
interface of the port-channel on both sides.
Egress traffic from the switch to the router is load-balanced fine.

I think the problem we have is because of the etherchannel load-balance 
"mpls label-ip":
r1#show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
         src-dst-ip
         mpls label-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
   IPv4: Source XOR Destination IP address
   IPv6: Source XOR Destination IP address
   MPLS: Label or IP

I guess when the MPLS label and ip are always the same there is nothing 
to make load-balancing decisions on right?
The solution Olivier Boehmer mailed could solve this problem, then you 
use the xconnects as sort of a "trunks" to connect the switches...


--
Koen

Alexandre Snarskii wrote:
> On Mon, Aug 25, 2008 at 04:07:48PM +0200, Oliver Boehmer (oboehmer) wrote:
>> Maarten Moerman <> wrote on Monday, August 25, 2008 3:54 PM:
>>
>>> Hi,
>>>
>>> I have a kind of problem at the moment which I'll try to explain here.
>>>
>>> Diagram:
>>>
>>>  sw1 with 4 * GE--> 4 * GE @ r1 @ 10GE--> 10GE @ r2 4 * GE--> 4 *
>>> GEsw2 
>>>
>>> sw1 + sw2 = 6509 with 6748 blades
>>> r1 + r2 = 7604 with 6748 blades, and their interconnects are on 10GE
>>> xenpaks on 6704 10GE blades
>>>
>>> On sw1 +2 I have:
>>>
>>> Int port-channel1
>>> Trunk encaps dot1q (multiple vlan)
>>>
>>> Int giga x/1-4
>>> Channel-group 1 mode on
>>>
>>> On r1 + r2 I have:
>>>
>>> Int port-channel 1
>>>  mtu 9216
>>>  xconnect <loopback IP other router> <mpls-tag> encapsulation mpls
>>>
>>> Int giga x/1-4
>>>  mtu 9216
>>>  channel-group 1 mode on
>>>
>>> However, I'm currently facing the problem, that I cannot exceed the
>>> bandwith of that port-channel over 1gbit. The ingress is no problem,
>>> it tries to send, but the other side doesn't seem to pick up the
>>> traffic. 
> 
> Looks like you see the same problem as me: 
> http://puck.nether.net/pipermail/cisco-nsp/2007-March/039451.html
> 
> We solved this issue with avoiding eompls and transferring
> data over 10ge-link as simple switched vlan. 
> 
> Another (possible) solution - you can do some xconnect's from 
> one sw to another (they're 6509, right ? So, you can load SRA
> or SXH IOS on them and do xconnects directly between switches). 
> Why that solution not guaranteed to work - if you have to xconnect
> vlan with more than one gbit of traffic, you'll face the same 
> problem not on rt egress, but on egress of the first sw. 
> 
> 
>>> Does this have to do with the fact that the portchannel on the
>>> routers only see 1 source, and 1 destination address? So that it
>>> cannot correctly balance traffic among 4 interfaces?
>>>
>>> Anybody has an idea how to solve this?
>> I've never done xconnect on a port-channel, but you could remove the
>> channel on r1 and r2 and just configure "regular" EoMPLS PWs between
>> each of the four GigE links. Channeling is then only performed on sw1
>> and sw2.. I would consider running LACP/PaGP on the channel between
>> sw1/sw2..
>> This should work.
> 
> Well, it should, but not in case when you need to xconnect only 
> some vlan's from portchannel, and others you need to terminate
> locally or xconnect to another destinations...
>