newb VLAN question

Answered Question
Jan 25th, 2010

Hello all,


I have a few Cisco 6509 routers that are setup with specific VLANs. I have a VLAN 11 that should have two working IP's in case one of the routers goes down, however only one of the IP's are working.


On the first router I have:


interface Vlan11
description Guest VLAN
ip address 10.10.x.2 255.255.255.0
ip access-group 114 in
ip helper-address 172.0.x.x
ip helper-address 172.0.x.x
no ip redirects
standby 10 ip 10.10.x.1
standby 10 priority 140
standby 10 preempt


The 10.10.x.2 is working properly and no problems.


On the second router:


interface Vlan11
description Guest VLAN
ip address 10.10.x.3 255.255.255.0
ip access-group 114 in
ip helper-address 172.0.x.x
ip helper-address 172.0.x.x
no ip redirects
standby 10 ip 10.10.x.1
standby 10 priority 140
standby 10 preempt


Now if I ping 10.10.x.3 I get no reply and therefore if my first router goes down and this becomes the primary my guest vlan will not be working.


I wanted to know where to start looking as to why this specific IP is not working and how I might get it back up and running.


Any other info you need let me know.


Thanks

Correct Answer by Jon Marshall about 7 years 1 month ago

poststandard wrote:


Jon,


OK you are right, as far as VLAN 11, the active is the 10.10.x.2 address and the standby is the 10.10.x.3.


What I don't understand is why does 10.10.x.2 ping with no problem with the same access list, but not the 10.10.x3?


You said: "If you want to test the ping from your host you will need to modify the  acl and add a line in for just that"


Can you provide an example of what that line should look like?


I appreciate your help.


Forgot to mention from your last post, don't use same priority on each router. Use 110 on the want you want active and 100 on the one you want standby. The priority is used to work out which router will be active, the highest number becomes the active router.


What I don't understand is why does 10.10.x.2 ping with no problem with the same access list, but not the 10.10.x3?


Okay i'll try and explain. An access-list applied inbound to a L3 vlan interface controls traffic that comes from clients on that vlan. So in your example the acl is applied to traffic coming from vlan 11 clients. You are pinging from a client not on that vlan. So the packet arrives at the L3 switch from a different vlan. The packet is then forwarded to the L3 SVI for vlan 11 on the same switch. So this one will respond to ping because the packet has not come from vlan 11 but from some other vlan.


So your client = 172.x.x.x


4500_1 is the switch that your clients traffic arrrives on. 4500_1 L3 SVI for vlan 11 is 10.10.x.2.


4500_2 is the switch that is connected to 4500_1 via a L2 trunk. 4500_2 L3 SVI for vlan 11 is 10.10.x.3.


So you ping 10.10.x.2 from your client. The packet arrives at 4500_1 and goes to the vlan 11 interface. However note that the packet did not arrive at the vlan 11 interface from vlan 11. The packet actually came from another vlan ie. your clients vlan. So access-list 114 was not checked.


When you ping 10.10.x.3 the packet again arrives on 4500_1 and this time the packet is routed onto vlan 11 and switched across the trunk link. Now the packet is actually coming from vlan 11 because 4500_1 placed it into vlan 11  so acl 114 now comes into play and denies the ping.


Like i said it's because of the virtualisation of the interfaces on a L3 switch that things can get a bit confusing.


The acl line would look something like


access-list 114 permit icmp host <172.x.x.x> host 10.10.x.2 echo-request

access-list 114 permit icmp host <172.x.x.x> host 10.10.x.3 echo-request


but note that you would have to redo the acl unless it is numbered and these lines need to go straight after the top 4.


Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jon Marshall Mon, 01/25/2010 - 06:56

poststandard wrote:


Hello all,


I have a few Cisco 6509 routers that are setup with specific VLANs. I have a VLAN 11 that should have two working IP's in case one of the routers goes down, however only one of the IP's are working.


On the first router I have:


interface Vlan11
description Guest VLAN
ip address 10.10.x.2 255.255.255.0
ip access-group 114 in
ip helper-address 172.0.x.x
ip helper-address 172.0.x.x
no ip redirects
standby 10 ip 10.10.x.1
standby 10 priority 140
standby 10 preempt


The 10.10.x.2 is working properly and no problems.


On the second router:


interface Vlan11
description Guest VLAN
ip address 10.10.x.3 255.255.255.0
ip access-group 114 in
ip helper-address 172.0.x.x
ip helper-address 172.0.x.x
no ip redirects
standby 10 ip 10.10.x.1
standby 10 priority 140
standby 10 preempt


Now if I ping 10.10.x.3 I get no reply and therefore if my first router goes down and this becomes the primary my guest vlan will not be working.


I wanted to know where to start looking as to why this specific IP is not working and how I might get it back up and running.


Any other info you need let me know.


Thanks


What does access-list 114 look like ?


Where are you pinging from ie. what IP address ?


Can you also post the output of a "sh stanbby brief" from the 6500.


Finally you shouldn't have the same HSRP priorities on both switches make the standby HSRP interface < 140.


Jon

poststandard Mon, 01/25/2010 - 07:07

Hi Jon,


Access-list 114:


access-list 114 permit udp any host 172.20.x.x eq bootps
access-list 114 permit udp any host 172.20.x.x eq bootps
access-list 114 permit udp host 172.20.x.x any eq bootpc
access-list 114 permit udp host 172.20.x.x any eq bootpc
access-list 114 deny   ip 10.10.11.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 114 deny   ip 172.16.0.0 0.15.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 10.0.0.0 0.255.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 192.168.0.0 0.0.255.255 10.10.11.0 0.0.0.255


I am pinging from my computer which is IP: 172.22.142.x - which is fine because I can ping 10.10.x.2 with no problems, just not the 10.10.x.3.


sh standby brief - from router1
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active addr     Standby addr    Group addr
Vl10        10  140  P Active   local           10.10.10.3      10.10.10.1
Vl11        10  140  P Standby  10.10.11.3      local           10.10.11.1
Vl15        15  140  P Standby  10.10.15.3      local           10.10.15.1
Vl18        18  140  P Active   local           172.18.142.3    172.18.142.1
Vl19        19  140  P Active   local           172.19.0.3      172.19.0.1
Vl20        20  140  P Init     unknown         unknown         172.20.142.1
Vl21        21  140  P Active   local           172.21.0.3      172.21.0.1
Vl22        22  140  P Active   local           172.22.0.3      172.22.0.1
Vl23        23  140  P Active   local           172.23.0.3      172.23.0.1
Vl24        24  140  P Active   local           172.24.0.3      172.24.0.1
Vl25        25  140  P Active   local           172.25.0.3      172.25.0.1
Vl110       11  140  P Active   local           172.20.110.252  172.20.110.254
Vl130       28  140  P Active   local           unknown         172.28.130.253
Vl140       28  140  P Active   local           172.28.140.252  172.28.140.1
Vl200       20  140  P Active   local           172.20.200.252  172.20.200.254


from router2


sh standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active addr     Standby addr    Group addr
Vl10        10  120    Standby  10.10.10.2      local           10.10.10.1
Vl11        10  140  P Active   local           10.10.11.2      10.10.11.1
Vl15        15  140    Active   local           10.10.15.2      10.10.15.1
Vl18        18  120    Standby  172.18.142.2    local           172.18.142.1
Vl19        19  120    Standby  172.19.0.2      local           172.19.0.1
Vl20        20  120    Init     unknown         unknown         172.20.142.1
Vl21        21  120    Standby  172.21.0.2      local           172.21.0.1
Vl22        22  120    Standby  172.22.0.2      local           172.22.0.1
Vl23        23  120    Standby  172.23.0.2      local           172.23.0.1
Vl24        24  120    Standby  172.24.0.2      local           172.24.0.1
Vl25        25  120    Standby  172.25.0.2      local           172.25.0.1
Vl110       11  120    Standby  172.20.110.251  local           172.20.110.254
Vl130       28  120    Active   local           unknown         172.28.130.253
Vl140       28  120    Standby  172.28.140.251  local           172.28.140.1
Vl200       20  120    Standby  172.20.200.251  local           172.20.200.254


As far as the HSRP priorities which router should I change it on and does it matter what # below 140 I change it to?


Thanks

Jon Marshall Mon, 01/25/2010 - 07:15

Access-list 114:


access-list 114 permit udp any host 172.20.x.x eq bootps
access-list 114 permit udp any host 172.20.x.x eq bootps
access-list 114 permit udp host 172.20.x.x any eq bootpc
access-list 114 permit udp host 172.20.x.x any eq bootpc
access-list 114 deny   ip 10.10.11.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 114 deny   ip 172.16.0.0 0.15.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 10.0.0.0 0.255.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 192.168.0.0 0.0.255.255 10.10.11.0 0.0.0.255


This doesn't look right. There is an implict deny ip any any at the end of each acl so apart from the top 4 lines you are denying all other traffic from clients on vlan 11 - is this what you want ?? Are you sure this is the full acl ?


As far as the HSRP priorities which router should I change it on and does it matter what # below 140 I change it to?


Any number will do as long as it is less than 140 ie. 110 is fine. If you don't specify a priority the default is 100 so most people configure the one they want as active with a priroity of 110 and leave the other one as default but as long as it is less than 140 you will be fine.


Jon

poststandard Mon, 01/25/2010 - 07:26

Jon,


No I missed a line - sorry. Here it is:


access-list 114 permit udp any host 172.20.200.3 eq bootps
access-list 114 permit udp any host 172.20.200.4 eq bootps
access-list 114 permit udp host 172.20.200.3 any eq bootpc
access-list 114 permit udp host 172.20.200.4 any eq bootpc
access-list 114 deny   ip 10.10.11.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 114 deny   ip 172.16.0.0 0.15.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 10.0.0.0 0.255.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 192.168.0.0 0.0.255.255 10.10.11.0 0.0.0.255
access-list 114 permit ip any any


Does that help?


I will change the HSRP properties. So in essence it should look like this:


core-router1:


standby 10 priority 110


corerouter2:


standby 10 priority 110

What exactly does the priority do and what will the change mean?


Also both routers are currently active.


Thanks

Jon Marshall Mon, 01/25/2010 - 07:41

poststandard wrote:


Jon,


No I missed a line - sorry. Here it is:


access-list 114 permit udp any host 172.20.200.3 eq bootps
access-list 114 permit udp any host 172.20.200.4 eq bootps
access-list 114 permit udp host 172.20.200.3 any eq bootpc
access-list 114 permit udp host 172.20.200.4 any eq bootpc
access-list 114 deny   ip 10.10.11.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 114 deny   ip 10.10.11.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 114 deny   ip 172.16.0.0 0.15.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 10.0.0.0 0.255.255.255 10.10.11.0 0.0.0.255
access-list 114 deny   ip 192.168.0.0 0.0.255.255 10.10.11.0 0.0.0.255
access-list 114 permit ip any any


Does that help?


I will change the HSRP properties. So in essence it should look like this:


core-router1:


standby 10 priority 110


corerouter2:


standby 10 priority 110

What exactly does the priority do and what will the change mean?


Also both routers are currently active.


Thanks


Yes it does help. I suspect this acl is blocking the ping. Because the switch is a L3 switch it can get a bit complicated as to the direction the traffic is entering the actual SVI interface.


You say both are active altho your "sh standby brief" didn't show that ? Can you confirm ?


If you want to test the ping from your host you will need to modify the acl and add a line in for just that. Apart from the HSRP issue i don't think you have a problem but you may want to modify the acl to test.


Jon

poststandard Mon, 01/25/2010 - 07:50

Jon,


OK you are right, as far as VLAN 11, the active is the 10.10.x.2 address and the standby is the 10.10.x.3.


What I don't understand is why does 10.10.x.2 ping with no problem with the same access list, but not the 10.10.x3?


You said: "If you want to test the ping from your host you will need to modify the  acl and add a line in for just that"


Can you provide an example of what that line should look like?


I appreciate your help.

Correct Answer
Jon Marshall Mon, 01/25/2010 - 08:08

poststandard wrote:


Jon,


OK you are right, as far as VLAN 11, the active is the 10.10.x.2 address and the standby is the 10.10.x.3.


What I don't understand is why does 10.10.x.2 ping with no problem with the same access list, but not the 10.10.x3?


You said: "If you want to test the ping from your host you will need to modify the  acl and add a line in for just that"


Can you provide an example of what that line should look like?


I appreciate your help.


Forgot to mention from your last post, don't use same priority on each router. Use 110 on the want you want active and 100 on the one you want standby. The priority is used to work out which router will be active, the highest number becomes the active router.


What I don't understand is why does 10.10.x.2 ping with no problem with the same access list, but not the 10.10.x3?


Okay i'll try and explain. An access-list applied inbound to a L3 vlan interface controls traffic that comes from clients on that vlan. So in your example the acl is applied to traffic coming from vlan 11 clients. You are pinging from a client not on that vlan. So the packet arrives at the L3 switch from a different vlan. The packet is then forwarded to the L3 SVI for vlan 11 on the same switch. So this one will respond to ping because the packet has not come from vlan 11 but from some other vlan.


So your client = 172.x.x.x


4500_1 is the switch that your clients traffic arrrives on. 4500_1 L3 SVI for vlan 11 is 10.10.x.2.


4500_2 is the switch that is connected to 4500_1 via a L2 trunk. 4500_2 L3 SVI for vlan 11 is 10.10.x.3.


So you ping 10.10.x.2 from your client. The packet arrives at 4500_1 and goes to the vlan 11 interface. However note that the packet did not arrive at the vlan 11 interface from vlan 11. The packet actually came from another vlan ie. your clients vlan. So access-list 114 was not checked.


When you ping 10.10.x.3 the packet again arrives on 4500_1 and this time the packet is routed onto vlan 11 and switched across the trunk link. Now the packet is actually coming from vlan 11 because 4500_1 placed it into vlan 11  so acl 114 now comes into play and denies the ping.


Like i said it's because of the virtualisation of the interfaces on a L3 switch that things can get a bit confusing.


The acl line would look something like


access-list 114 permit icmp host <172.x.x.x> host 10.10.x.2 echo-request

access-list 114 permit icmp host <172.x.x.x> host 10.10.x.3 echo-request


but note that you would have to redo the acl unless it is numbered and these lines need to go straight after the top 4.


Jon

poststandard Mon, 01/25/2010 - 08:36

OK Jon,


Thanks for the help, I appreciate the explanation. I will take a look and review all of this and then make some changes and let you know how it works out.


Thanks again.

poststandard Mon, 01/25/2010 - 11:15

Jon,


OK I went to check VLAN11 and it is not working. I think this is because the client computer thinks that 10.10.11.3 is the active one. I ran wireshark on the client computer and it went through the DHCP discover process and it is showing:


Source: 10.10.11.3

Desitnation: 224.0.0.2

Protocal: HSRP

Info: Hello (State Active)


Source: 10.10.11.2

Desitnation: 224.0.0.2

Protocal: HSRP

Info:  Hello (State Standby)


Routers are showing:


Router1:


sh standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active addr     Standby addr    Group addr
Vl10        10  140  P Active   local           10.10.10.3      10.10.10.1
Vl11        10  140  P Standby  10.10.11.3      local           10.10.11.1
Vl15        15  140  P Standby  10.10.15.3      local           10.10.15.1
Vl18        18  140  P Active   local           172.18.142.3    172.18.142.1
Vl19        19  140  P Active   local           172.19.0.3      172.19.0.1
Vl20        20  140  P Init     unknown         unknown         172.20.142.1
Vl21        21  140  P Active   local           172.21.0.3      172.21.0.1
Vl22        22  140  P Active   local           172.22.0.3      172.22.0.1
Vl23        23  140  P Active   local           172.23.0.3      172.23.0.1
Vl24        24  140  P Active   local           172.24.0.3      172.24.0.1
Vl25        25  140  P Active   local           172.25.0.3      172.25.0.1
Vl110       11  140  P Active   local           172.20.110.252  172.20.110.254
Vl130       28  140  P Active   local           unknown         172.28.130.253
Vl140       28  140  P Active   local           172.28.140.252  172.28.140.1
Vl200       20  140  P Active   local           172.20.200.252  172.20.200.254


sh standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active addr     Standby addr    Group addr
Vl10        10  120    Standby  10.10.10.2      local           10.10.10.1
Vl11        10  140  P Active   local           10.10.11.2      10.10.11.1
Vl15        15  140    Active   local           10.10.15.2      10.10.15.1
Vl18        18  120    Standby  172.18.142.2    local           172.18.142.1
Vl19        19  120    Standby  172.19.0.2      local           172.19.0.1
Vl20        20  120    Init     unknown         unknown         172.20.142.1
Vl21        21  120    Standby  172.21.0.2      local           172.21.0.1
Vl22        22  120    Standby  172.22.0.2      local           172.22.0.1
Vl23        23  120    Standby  172.23.0.2      local           172.23.0.1
Vl24        24  120    Standby  172.24.0.2      local           172.24.0.1
Vl25        25  120    Standby  172.25.0.2      local           172.25.0.1
Vl110       11  120    Standby  172.20.110.251  local           172.20.110.254
Vl130       28  120    Active   local           unknown         172.28.130.253
Vl140       28  120    Standby  172.28.140.251  local           172.28.140.1
Vl200       20  120    Standby  172.20.200.251  local           172.20.200.254


What is interesting is on the routers VLAN11 active is 10.10.11.2 and Stanby is 10.10.11.3 which would be correct.


I think that because Wireshark is showing 10.10.11.3 (the not working IP) as the active IP this is not working.


Do you have any suggestions?

poststandard Tue, 01/26/2010 - 15:52

Jon,


Issue is resolved. The problem was that sticky-mac was enabled on the port. I changed that and now it is working properly. The reason why I can't ping the .3 address is because it is one the secondary router and not the primary. If the primary fails it will go to the secondary and then the .3 address will take over.


I took your advice and changed the priorites.


I appreciate your help and I am sure I will be back with more questions at some point.


Thanks again.

Actions

This Discussion