cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1005
Views
0
Helpful
6
Replies

access-list on glbp for managment switches

Steev112
Level 1
Level 1

Hi All,

 

I have two core switches 4507E and one vlan for data and management switches , configure glbp for this vlan as follow:

 

 

core1

 

interface Vlan100

 ip address 172.20.201.225 255.255.254.0

 ip access-group 101 in

 glbp 100 ip 172.20.200.6

 glbp 100 priority 150

 glbp 100 preempt

end

access-list 101 permit ip host 172.17.1.120 host 172.20.201.225

access-list 101 permit ip host 172.17.1.120 host 172.20.200.6

 

core2

 

interface Vlan100

 ip address 172.20.201.226 255.255.254.0

 ip access-group 101 in

 glbp 100 ip 172.20.200.6

access-list 101 permit ip host 172.17.1.120 host 172.20.201.226

access-list 101 permit ip host 172.17.1.120 host 172.20.200.6

 

 

 

and configure and access-list to access these switch only for this host as shows above:

 

I have faced these issue:

  1. When I try to telnet or SSH by glbp ip address “172.20.200.6” I access Core#2 not Core#1 since the active on is Core#1? Can anyone explain ?
  2. When I try to telnet or SSH by ip address “172.20.201.225” I couldn’t from remote site since I can ping this ip address? Can anyone explain? Only I can telnet or ssh for glbp ip address and access core#2 not one.

Thanks

1 Accepted Solution

Accepted Solutions

Good day Stephen. If I understand it correctly, the priority command for GLBP would determine which Switch/router becomes the Active Virtual Gateway. The role of this AVG would then be to manage the destination MAC for the GLBP virtual IP. So it would then manage the load balancing between the Active Virtual Gateway, and the Active Virtual Forwarders (Previously in HSRP this would be the standby Router/Switch). The AVFs would then process traffic as well. The load-balancing mechanism can be "round-robin" or "affinity" based. You can decide which one works for you then tune it accordingly.

This then, however means, that when you send traffic to the Gateway address (GLBP VIP) you would not always get a response from the Active router/switch. I suspect this is happening in your case. So when you telnet the VIP, the AVG sends the MAC of the AVF, and that is why you end up there. This is working correctly. If you want to manage your AVG (Active device with highest priority) then it may be best to use it's real IP.

The fact that you can't access the real IP either could be unrelated. More troubleshooting may be needed here.

View solution in original post

6 Replies 6

Jon Marshall
Hall of Fame
Hall of Fame

Steven

Can you repost as it has formatted weirdly for some reason.

Also can you -

1) be more specific in terms of which way are you telnetting ie. presumably from the remote site.

Are you saying you can ping core 1 real IP but not telnet to it ?

2) can you post a "sh glpb brief" from both switches.

3) is that the full acl ?

Jon

Hi Jon,

 

From remote site the IP address for PC is 172.17.1.120  and i can ping the core 1 and 2 (172.20.201.225/226)  but i can't telnet this IP address (172.20.201.225) only i able to telnet by this IP address 172.20.200.6 but access Core2 not 1.below full access-list:

 

access-list 101 permit ip host 172.17.1.120 host 172.20.201.225
access-list 101 permit ip host 172.17.1.120 host 172.20.200.6
access-list 101 permit ip host 172.17.114.40 host 172.20.201.225
access-list 101 permit ip host 172.17.114.40 host 172.20.200.6
access-list 101 permit ip host 172.17.116.3 host 172.20.201.225
access-list 101 permit ip host 172.17.116.3 host 172.20.200.6
access-list 101 permit ip host 172.17.116.11 host 172.20.201.225
access-list 101 permit ip host 172.17.116.11 host 172.20.200.6
access-list 101 permit tcp host 172.17.116.3 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.116.3 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.116.11 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.116.11 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.114.40 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.114.40 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.1.100 any
access-list 101 permit tcp host 172.17.1.120 any
access-list 101 deny   tcp any host 172.17.1.42
access-list 101 permit ip any any
access-list 101 deny   tcp any host 172.20.201.225
access-list 101 deny   tcp any host 172.20.200.6
!

i don't why i can't telnet the real IP address and why when telnet by GLBP IP address i access Core2 not Core1.

 

Thanks

Your acl has a "permit ip any any", is this just for testing because if isn't you don't need all those other lines and the deny lines at the end never get used.

Can you post a "sh glbp brief".

Jon

Hi Jon,

 

1. since i apply permit ip any any, still i can't telnet core#1 or Core#2 from different subnet but i can telnet from the same subnet? why?

2. is GLBP configuration wrong?

3. if i want to modify the access-list to remove the permit ip any any do i need to do:

 

access-list 101 permit ip host 172.17.1.120 host 172.20.201.225
access-list 101 permit ip host 172.17.1.120 host 172.20.200.6
access-list 101 permit ip host 172.17.114.40 host 172.20.201.225
access-list 101 permit ip host 172.17.114.40 host 172.20.200.6
access-list 101 permit ip host 172.17.116.3 host 172.20.201.225
access-list 101 permit ip host 172.17.116.3 host 172.20.200.6
access-list 101 permit ip host 172.17.116.11 host 172.20.201.225
access-list 101 permit ip host 172.17.116.11 host 172.20.200.6
access-list 101 permit tcp host 172.17.116.3 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.116.3 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.116.11 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.116.11 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.114.40 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.114.40 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.1.100 any
access-list 101 permit tcp host 172.17.1.120 any
access-list 101 deny tcp any host 172.17.1.42
access-list 101 deny tcp any host 172.20.201.225
access-list 101 deny tcp any host 172.20.200.6

 

or

 

access-list 101 permit ip host 172.17.1.120 host 172.20.201.225
access-list 101 permit ip host 172.17.1.120 host 172.20.200.6
access-list 101 permit ip host 172.17.114.40 host 172.20.201.225
access-list 101 permit ip host 172.17.114.40 host 172.20.200.6
access-list 101 permit ip host 172.17.116.3 host 172.20.201.225
access-list 101 permit ip host 172.17.116.3 host 172.20.200.6
access-list 101 permit ip host 172.17.116.11 host 172.20.201.225
access-list 101 permit ip host 172.17.116.11 host 172.20.200.6
access-list 101 permit tcp host 172.17.116.3 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.116.3 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.116.11 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.116.11 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.114.40 host 172.20.201.225 eq 443
access-list 101 permit tcp host 172.17.114.40 host 172.20.200.6 eq 443
access-list 101 permit tcp host 172.17.1.100 any
access-list 101 permit tcp host 172.17.1.120 any
 

no need to add deny for these "

access-list 101 deny tcp any host 172.17.1.42
access-list 101 deny tcp any host 172.20.201.225
access-list 101 deny tcp any host 172.20.200.6"

 

Please advise

 

 

 

 

Good day Stephen. If I understand it correctly, the priority command for GLBP would determine which Switch/router becomes the Active Virtual Gateway. The role of this AVG would then be to manage the destination MAC for the GLBP virtual IP. So it would then manage the load balancing between the Active Virtual Gateway, and the Active Virtual Forwarders (Previously in HSRP this would be the standby Router/Switch). The AVFs would then process traffic as well. The load-balancing mechanism can be "round-robin" or "affinity" based. You can decide which one works for you then tune it accordingly.

This then, however means, that when you send traffic to the Gateway address (GLBP VIP) you would not always get a response from the Active router/switch. I suspect this is happening in your case. So when you telnet the VIP, the AVG sends the MAC of the AVF, and that is why you end up there. This is working correctly. If you want to manage your AVG (Active device with highest priority) then it may be best to use it's real IP.

The fact that you can't access the real IP either could be unrelated. More troubleshooting may be needed here.

Hi Andre/Jon,

 

Thanks for your informations now is clear.