cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3876
Views
0
Helpful
9
Replies

GLBP configuration

sly007
Level 1
Level 1

Kindly assist in troubleshooting GLBP functionality

GLBP has been configured one 2951 and 3945 (using the etherswitch module on 3945) Routers, using OSPF.   After configuration, the load-balancing is working properly, as the route from the local systems periodically changes from Route 1 to the other and back at regular interver. But whenever I shut down a link, to test the functionality and availability of the redundant link of GLBP, the whole  circuit would go down, making destination no longer reachable. I believe there is something that ought to be done or some of the configurations is not complet. Please help troubleshoot, the configs are below.

In addition, how is the "ip sla group"  configured on the 2951 and 3945 Routers, to be able to track objects? It gives me the "ip sla responder" and "ip sla key-chain" options on image version c2951-universalk9-mz.SPA.150-1.M3.bin

ROUTER_1

GigabitEthernet0/0         192.168.215.252 YES NVRAM  up                    up

GigabitEthernet0/1         192.168.155.2   YES NVRAM  up                    up

GigabitEthernet0/2         unassigned      YES NVRAM  administratively down down

GigabitEthernet1/0         unassigned      YES NVRAM  administratively down down

Router_1#sh run int g0/0

interface GigabitEthernet0/0

description Call Center LAN

ip address 192.168.215.252 255.255.254.0

duplex auto

speed auto

glbp 10 ip 192.168.215.254

glbp 10 timers 5 18

glbp 10 priority 101

glbp 10 preempt

glbp 10 weighting 100 lower 91 upper 91

glbp 10 load-balancing weighted

glbp 10 weighting track 1 decrement 10

track 1 interface GigabitEthernet0/1 line-protocol

ROUTER_2

Interface                  IP-Address      OK? Method Status                Protocol

GigabitEthernet0/0         unassigned      YES NVRAM  administratively down down

GigabitEthernet0/1         192.168.155.6   YES NVRAM  up                    up

GigabitEthernet0/2         unassigned      YES NVRAM  down                  down

Serial0/0/0:0              unassigned      YES NVRAM  down                  down

Serial0/0/1:1              unassigned      YES NVRAM  down                  down

GigabitEthernet2/0         192.168.215.253 YES NVRAM  up                    up

Router_2#sh run int g2/0

interface GigabitEthernet2/0

ip address 192.168.215.253 255.255.254.0

ip nbar protocol-discovery

glbp 10 ip 192.168.215.254

glbp 10 timers 5 18

glbp 10 preempt

glbp 10 weighting 100 lower 91 upper 91

glbp 10 load-balancing weighted

glbp 10 weighting track 1 decrement 10

track 1 interface GigabitEthernet0/1 line-protocol

1 Accepted Solution

Accepted Solutions

Do you get a different result if you physically pull the cable? If you have a specific route that you receive from the other side, you could try changing the tracking config to track the route. For example, if you receive prefix 192.168.1.0/24 from the provider, you could configure track like:

track 1 ip route 192.168.1.0/24 reachability

Otherwise, there are some tracking issues with the IOS version that you're running. You could try to update the IOS to see if this other problem is resolved. Personally, if pulling the cable still doesn't show you that the interface is down (tracked), then I would update the IOS first to see if it worked. I've tested shutting down the interface to see if line protocol was seen as down, and it is:

Track 1

  Interface FastEthernet0/0 line-protocol

  Line protocol is Down (hw admin-down)

    4 changes, last change 00:00:04

Notice that it says admin-down, so you, in theory, should be seeing the same thing. Your glbp configuration should work fine once you get the tracking situation resolved.

HTH,

John

HTH, John *** Please rate all useful posts ***

View solution in original post