Hi Gang, We have setup of two Core, and Some Distribution switches in LAN, We are running HSRP to p...

amey.dixit · ‎10-07-2011

Hi Gang,

We have setup of two Core, and Some Distribution switches in LAN, We are running HSRP to provide Redundancy on per Vlan basis.

We have Call manager ( Primary and Secondary ) 192.168.1.251,192.168.1.252, with one ethernet port which is connecting to Core one @ Gi 1/3, Which is working fine and we able to ping those UCS server as well.

Now My Question is:

This same CM we are also connecting to Secondary Core @ Gi 2/40 in same Vlan 100, We are running HSRP, But we unable to Get Ping reply from Core 2?

I am Posting Some Configuration Output for Ref.

Core_One#show run interface gig

Core_One#show run interface gigabitEthernet 1/3

Building configuration...

Current configuration : 112 bytes

!

interface GigabitEthernet1/3

switchport access vlan 100

switchport mode access

switchport nonegotiate

end

......

Core_Two#show run interface gig 2/40

Building configuration...

Current configuration : 113 bytes

!

interface GigabitEthernet2/40

switchport access vlan 100

switchport mode access

switchport nonegotiate

end

....

Core_One#show vlan bri

Core_One#show vlan brief

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Gi1/4, Gi1/5, Gi1/6, Gi1/11

Gi1/12, Gi1/14, Gi1/15, Gi1/16

Gi1/17, Gi1/18, Gi1/19, Gi1/20

Gi2/8, Gi2/9, Gi2/10, Gi2/37

Gi2/38, Gi2/39, Gi2/40, Gi2/42

10 cluster active

100 Windows-Server active Gi1/1, Gi1/2, Gi1/3, Gi2/1

Gi2/2, Gi2/3, Gi2/4, Gi2/5

Gi2/6, Gi2/7, Gi2/17, Gi2/21

Gi2/22, Gi2/23, Gi2/24, Gi2/25

Gi2/29, Gi2/30, Gi2/31, Gi2/32

Gi2/33, Gi2/34, Gi2/35, Gi2/36

Gi2/43, Gi2/48

200 Client-NODE-0ne active Gi2/15, Gi2/16, Gi2/18, Gi2/19

Gi2/20, Gi2/26, Gi2/27, Gi2/28

201 Client-NODE-two active

213 sap-Server active Gi1/7, Gi1/8, Gi1/9, Gi1/10

Gi2/11, Gi2/12, Gi2/13, Gi2/14

215 DMZ active Gi2/41

1002 fddi-default act/unsup

1003 token-ring-default act/unsup

1004 fddinet-default act/unsup

1005 trnet-default act/unsup

.........

What is possible reason for that?

so that we can fix this up

Thanks in Advance.

Cheers

Amey

Vaibhava Varma · ‎10-07-2011

Hi Amey

Are you able to learn the ARP/MAC of the UCS on Core_Two.

Do you have a direct connectivity of the CCM to the Core_Swithces or there is any L2 Switch in between.

Regards

Varma

amey.dixit · ‎10-07-2011

hey Varma,

Yes, i do check we are able to learn the ARP/MAC of the UCS on Core_Two.

and also under sh ip int bri, its shows up and up status, on core two in repected port.

2. yes we directly connected CCM to Core one and Core two.

Actually, we are not able to Ping those UCS server from Core 2, i also clear Counter on that Connected Interface.

Early Reply Really Apreciated

What should be Root Cause?

Thanks in advance

D.Amey

Vaibhava Varma · ‎10-07-2011

Hi Amey

Quite an interesting behaviour. Will it be possible to post you outputs of below. Just trying to look around the expected behaviour from CLI in this scenarion of UCS being multihomed to 2 L3 Switches. UCS is using the Logical IP assigned on a Bond Interface Right ( Both the Physical Interfaces are Active at the same time )

Core_One and Core_Two

1. show standby vlan 100 brief

2. show arp | i UCS_IP

3. show mac-address-table | i MAC_from_Above

Regards

Varma

amey.dixit · ‎10-08-2011

Hi Varma,

I Will send you command Output, on monday, But
Actually i want to understanda, wht Expected behaviour you want to understand from those command, if i say

in Sh ip int bri, ITs shows UP/UP, than this interface is physically and from Line protocol is up.

2. for HSRP, Please find Output of Sh standby brief:

Core_One#show standby bri
Core_One#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active          Standby         Virtual IP
Vl1         1   110  P Init     unknown         unknown         192.168.1.197
Vl10        10  110  P Active   local           10.10.0.9       10.10.0.10
Vl100       100 110  P Active   local           192.168.1.3     192.168.1.10
Vl200       200 110  P Active   local           192.168.200.3   192.168.200.10
Vl201       201 110  P Active   local           192.168.201.3   192.168.201.10
Vl213       213 110  P Active   local           192.168.213.3   192.168.213.205
Vl215       215 110  P Active   local           172.16.10.3     172.16.10.10

...........................................................................

which looks quite normal.

We are using 192.168.1.10 As VIP in HSRP.

and this is Default GW of our Call manager, which is quite normal.

so please try to remove my confusion, if i am having.

Thanks in Advance,

Amey

Vaibhava Varma · ‎10-08-2011

Hi Amey

I just wanted to look for how core 2 is learning the UCS_IP_MAC. From my understanding it should be learning via trunk link to core_one. Is this happening in your setup.

As I have asked you above the UCS would have 2 interfaces -One Connecting to Core_One and Other Connecting_to_Core_Two and you would have assigned a logical bond IP on the UCS. Is that correct. Now from UCS perspective it will be learning the HSRP_VIP_MAC from both Core_One and Core_Two.

How do you control at UCS side which interface to use for Outbound Traffic ie whether to take Core_One_Connecting_Link or Core_Two_Connecting_Link .

From my understanding both Links can not be active at same time and provide the same HSRP_VIP_MAC to it as it will cause MAC_Table_instability from my understanding. Same thing applies for learning the UCS_IP_MAC on Core_One and Core_Two

I suspect this might be somewhere contributing to this issue. I am not sure though as normally when in Servers we have Dual NIC its in 1:1 redundancy for the cases I have seen the links operate as Active and Standby and MAC learning happens through single link only.

So to me this seems to be a very typical and unexpected behaviour where communication between UCS_&_Core_One is happening and UCS_&_core_Two is down. First we need to make sure whether the MACs are being learnt the expected way or not.

Did you happen to take a look at the UCS and check for the Core_Two VLAN 100 ARP/MAC entries and they are getting populated correctly.

Regards

Varma

amey.dixit · ‎10-08-2011

Hi varma,

I will surely Send you Command Output on monday.

So that you are able to analyze MAC learning.

But, UCS is having one ETHERNET Interface, not TWO and IN Core 2, The Interface Where UCS Secondary Server is Connected is not down, its up but we are unable to Ping

UCS from Core2.

We are Connected Core 1 and Core 2 VIA Trunk.

I will Send you Command Output on Monday, So that we can understand

MACs are being learn in the expected way or not.

Any Other Command Output, Which you want to Analyse in Case MAC Learn in as Expected Way.

Regards

Amey

Vaibhava Varma · ‎10-08-2011

Hi Amey

I might be getting unclear on your actual network setup wrt to the UCS_Primary (192.168.251.1) and UCS_Secondary (192.168.1.252)

Can you also share your network Toplogy Diagram with the respective IPs of Primary and Secondary UCS

Till now with our discussion it seems

ucs-P--eth0--------Access_VLAN_100--Gi1/3---CoreOne---Trunk_Vlan_100----CoreTwo---Gi2/40--VLAN_100--eth0--UCS_S

Is this correct.

You can ping UCS_P(192.168.251.1) from Core_One..Is that correct ?

Problem Description

Can not Ping UCS_S(192.168.251.2) from Core_two. Is that correct ?

Can you Ping UCS_P(192.168.251.1) from Core_two

Can you ping UCS_S(192.168.251.2) from Core_One

To analyze this problem we basically need to look at the ARP/MAC entries for UCS_P and UCS_S on Core_One and Core_two

Regards

Varma

amey.dixit · ‎10-09-2011

Hi Varma,

Please find Answer:

Till now with our discussion it seems

ucs-P--eth0--------Access_VLAN_100--Gi1/3---CoreOne---Trunk_Vlan_100(Simple Trunk not Trunk allowed Vlan 100 )----CoreTwo---Gi2/40--VLAN_100--eth0--UCS_S

Is this correct..... We are using Simple Trunk, Sw Trunk allow vl 100, Because as far as i concern, Trunk Carries all vlan.

You can ping UCS_P(192.168.251.1) from Core_One..Is that correct ? Yes

Problem Description

Can not Ping UCS_S(192.168.251.2) from Core_two. Is that correct ? Yes We are not

Can you Ping UCS_P(192.168.251.1) from Core_two..................Yes we are not

Can you ping UCS_S(192.168.251.2) from Core_One.... Yes we are able to ping

To analyze this problem we basically need to look at the ARP/MAC entries for UCS_P and UCS_S on Core_One and Core_two

Yes i will send you output of ARP/MAC entries, looking forward for Solution.

Regards

Amey Dixit