GLBP issues

[richard.priest]

Hi,

I have a setup where x3 routers are connected to a core of x2 stacked Huawei chassis switches.

For redundancy & to fully utilise all x3 routers I want to use GLBP, however it doesn't seem to be working correctly.

Setup is extremely simple, on each interface directly connected to the switches I've enabled GLBP with VIP address as the 1st IP in the subnet i.e:

R1

Interface Gi01/0

IP address 172.30.1.2 255.255.255.0

GLBP 1 IP 172.30.1.1

R2

Interface Gi01/0

IP address 172.30.1.3 255.255.255.0

GLBP 1 IP 172.30.1.1

R3

Interface Gi01/0

IP address 172.30.1.4 255.255.255.0

GLBP 1 IP 172.30.1.1

Huawei Switch

VLAN 10

ip address 172.30.1.5 255.255.255.0

Interface range Gi0/1 - 3

port link-type access
port default vlan 10

The GLBP group comes up perfectly, all the routers can ping each other without issue, and can ping the Huawei stack. As you'd expect the Huawei switch can ping each router without issue.

However when trying to ping the VIP, if the issued VIP by the AVG isn't the AVG i.e. it's just a forwarder in the listen state then there is no response. I end up deleting the GLBP group member, then clearing the ARP cache on the Huawei and hope the AVG issues a a response from the AVG

Any thoughts on what the issue might be? 

Cheers

[richard.priest]

I should add with the config setup as HSRP it works perfectly, I can bump the priority to any of the Routers and can ping the VIP without issue

[paul driver]

Hello
Preemption by default is disabled in glbp so if you disable the AVG then the other rtrs in the group(AVFs) without any preemption may not work as expected as the next suitable (higher priority) AVG shouldnt failover correctly, I would also suggest manually specify the AVG and enable preemption..

Example:
R1
interface x/x
ip address 172.30.1.2 255.255.255.0
glbp 1 ip 172.30.1.1
glbp 1 priority 120
glbp 1 preempt

R2
interface x/x
ip address 172.30.1.3 255.255.255.0
glbp 1 ip 172.30.1.1
glbp 1 priority 115
glbp 1 preempt

R3
interface x/x
ip address 172.30.1.4 255.255.255.0
glbp 1 ip 172.30.1.1
glbp 1 priority 100
glbp 1 preempt

[richard.priest]

Hi Paul,

Even with preemption configured on the interfaces, the same issue persisits.

Looking at the ARP table on the switch I can see it's issued a MAC for the next hop device, but L3 traffic is never returned from the AVF

[paul driver]

Hello

---

@richard.priest wrote:

Hi Paul,

Even with preemption configured on the interfaces, the same issue persisits.

Looking at the ARP table on the switch I can see it's issued a MAC for the next hop device, but L3 traffic is never returned from the AVF

---

Try the following:
glbp 1 timers msec 50 msec 70

glbp 1 timers redirect 600 14400

[richard.priest]

Hi Paul,

I'll certainly try the timers, but I'm not sure how they'll help. AIUI they're for tuning the time it takes for a dropped router to be replaced by the AVG with all 3 routers active i get issued a vMAC by the AVG and it's pot luck whether it's of an AVF that will respond.

All the routers have a direct connection to the switch, and all the routers can ping the SVI on the switch and the switch can ping all the interface IPs at all times.

Cheers

[paul driver]

Hello

---

@richard.priest wrote:

Hi Paul,

I'll certainly try the timers, but I'm not sure how they'll help. AIUI they're for tuning the time it takes for a dropped router to be replaced by the AVG with all 3 routers active i get issued a vMAC by the AVG and it's pot luck whether it's of an AVF that will respond.

All the routers have a direct connection to the switch, and all the routers can ping the SVI on the switch and the switch can ping all the interface IPs at all times.

Cheers

---

Tbh - now i am not so sure i am understanding you issue here 

so you have reachability to all rtrs even after failover correct ?

[richard.priest]

Hi Paul,

I have reachability via the interface address, but not via the VIP which is on the same subnet....

[paul driver]

Hello

okay and this is via a host attached to the switch  on the same subnet as the glbp vip and not the switch itself correct

[richard.priest]

This is either from a host on the same subnet or the switch.

[paul driver]

Hello

Okay at this point on a cisco switch I would now recommend to disable ip routing and make the switch a host switch however i cannot comment on how this would be accomplished on the huawei device.

try 

no ip routing ?

[richard.priest]

I can't really disable routing on the switch as it's future use will be as a core switch, it'll need to route traffic.

[Georg Pauwen]

Hello,

on a side note, as far as I recall, GLBP is Cisco proprietary, so I am not sure how and if it interacts with Huawei switches. Then again, HSRP is as well...

Does VRRP work ? That is standards based on supported on both...

[Georg Pauwen]

To add to that, I looked around and found the document linked below, which seems to confirm that GLBP does not work with Huawei switches, and the recommendation is to use VRRP. Check section 2.1.

https://actfornet.com/ueditor/php/upload/file/20181224/1545595324796861.pdf

[paul driver]

Hello

@Georg Pauwen That document just shows how Huawei switches using vrrp can interoperate with cisco glbp, GLBP as you stated is cisco proprietary and as the rtrs are cisco then glbp should work, but i do think at this time the issue the OP is experiencing points to the Huawei switch