BladeSystem - General
cancel
Showing results for 
Search instead for 
Did you mean: 

Misbehaviour of Port Mapping on c7000 Blades

 
SOLVED
Go to solution
Highlighted
Regular Advisor

Misbehaviour of Port Mapping on c7000 Blades

We did such a test with a C-7000 blade system: We connected 2 Flex-10 VC modules to Interconnect Bays 1 and 2, then port of LOM1-a on all servers mapped to VC@ Interconnect Bay1 and port LOM2-a mapped to VC@ Interconnect Bay2.
Then we removed the VC@ Bay2 and removed all profiles and networks and we even did factory reset on VC and Entire Enclosure and unplugged the power cords of enclosure but anytime we define a server profile and assign it to a server at one of server bays, it maps the port LOM2-a to Interconnect Bay 2!!!

Is there any remedy?
14 REPLIES 14
Highlighted
Honored Contributor

Re: Misbehaviour of Port Mapping on c7000 Blades

Port mappings are hard-wired, they aren't changed in profiles. For redundancy purposes, half of the signals are routed east and the other are routed west in the midplane so that even a mechanical failure (i.e. a hole) in the midlplane does not cause an outage if proper teaming has been utilized.
Highlighted
Honored Contributor

Re: Misbehaviour of Port Mapping on c7000 Blades

Hi Nima,

This is expected behavior. LOM2 can only leave the enclosure via uplink ports in VC module 1 if there is a module in bay 2 as well.

good luck
Highlighted
Regular Advisor

Re: Misbehaviour of Port Mapping on c7000 Blades

This is the point: The mappingin the enclosure, before inserting the second VC module, for each server was like this:

eth0->LOM1-a Bay#1
eth1->LOM2-a Bay#1

After Inserting the Second module, the mapping became like this:

eth0->LOM1-a Bay#1
eth1->LOM1-a Bay#2

Then, I removed the Second VC Module, Performed a factory reset and unplugged the enclosure power-cord and plugged it again!
But The Mapping still is:

eth0->LOM1-a Bay#1
eth1->LOM1-a Bay#2

The VC@Bay#2 no longer exists! This would not be hard-wired mapping policy for this case, since the initial hard-wired policy before inserting the second module was:

eth0->LOM1-a Bay#1
eth1->LOM2-a Bay#1

I am just looking for a workaround!
Highlighted
Honored Contributor

Re: Misbehaviour of Port Mapping on c7000 Blades

hi again Nima,

You can leave the virtual network for LOM2-a (as well as LOM2-b,c,d) set to Unassigned. That way you can continue to add flex adapters on LOM1.

No trouble doing this, and it allows you to add the VC module in bay 2 at a later date if you choose.

good luck, if you appreciate the answers we appreciate the points!
Highlighted
Honored Contributor

Re: Misbehaviour of Port Mapping on c7000 Blades

@Nima: your last post is just wrong. Port mappings are hard-wired and don't change. You must have made a mistake.
Highlighted
Regular Advisor

Re: Misbehaviour of Port Mapping on c7000 Blades

I'm so sorry! it was a typo! The observed misbehavior is like this:
eth0->LOM1-a Bay#1
eth1->LOM2-a Bay#2
Highlighted
Honored Contributor

Re: Misbehaviour of Port Mapping on c7000 Blades

Your description of the initial configuration, i.e. before your started messing about with everything, no matter what you think!, is just not possible.


> before inserting the second VC module, for each server was like this:

> eth0->LOM1-a Bay#1
> eth1->LOM2-a Bay#1

If eth1 == LOM2, then it is simply not possible for it to map to Bay #1. The mapping is HARD, and immutable. LOM#2 maps to Interconnect bay #2, there is nothing you can do about it.

You need to pay attention to David, he knows a bit about this stuff.
Highlighted
Regular Advisor

Re: Misbehaviour of Port Mapping on c7000 Blades

The initial Configuration is when the module at BAY#2 is not inserted! Then it is absolutely possible!
Highlighted
Regular Advisor

Re: Misbehaviour of Port Mapping on c7000 Blades

I've enclosed a screen-shot of a healthy scenario! (so called Initial Config.)!

THIS is not what I THINK, this is What I SEE!