i have a network setuop as attached.
All the access switches are 4506 with SUP 2 plus (l3 capable but are being used as L2)
These get connected to Core switches which are 4506 with SUP V.
Each access switch is configurd with a VLAN 1 ip address as well as a loopback address. We want to use the loopback IP for remote monitoring. Default route is configured on each access switch.
But i am not able to reach the switches via the loopback IPs. The trace drops at the core routers.
Am i missing something with this setup ?
Do you have routes to get to the loopbacks. If your switches are L2 only they won't propogate routes for the loopbacks. You would need to enter static routes for these on your L3 devices and redistribute into EIGRP.
vlan1 interface in l2 switch are shutdown by default. Make sure to execute "no shutdown" after creating the vlan1 interface
I am not clear about part of what is being done here and seeing configs might help. But I believe that the issue is that the access switches are being used as only layer 2 switches. A layer 2 switch can have only a single management address. But it sounds like the original poster is attempting to have 2 management addresses: they are using VLAN 1 for management and are trying to use loopback for management. I do not believe that both will work if the switch is used as only layer 2 switch.
I agree that a true Layer 2 switch can only have one management interface. However what the original poster is talking about is a layer 3 capable switch that is not routing. If i have understood this correctly you can indeed have another interface on the switch but because it is not routing the loopback will not propogate through the network. ie
On a 3550 switch in our lab.
The 3550 has a vlan 10 interface with an address of 10.15.1.3.
I added a loopback interface - loopback10 with an ip address of 192.168.75.1.
I made sure that the switch was not routing ie
no ip routing
Then on the router with an interface in the 10.15.1.x subnet i added a static
ip route 192.168.75.1 255.255.255.255 10.15.1.3 and redistributed this static into EIGRP.
I could ping the loopback from anywhere in the lab.
Is this a fair thing to do in terms of the original question or have i missed the point ?
As I said in my post: seeing configs would help. Then we would know better what they are trying to do. Based on the symptoms described I am guessing that they have not provided static routes in the core for the access switch loopbacks, which you did.
I would say that what you did is quite fair as a way to find what works. Whether it is fair in terms of the original question would depend on the full environment of the original question which we do not know. But I think that you did well to demonstrate a way to get it to work.
My opinion is that if they want to operate the access switches as just layer 2 switches, that there is no real advantage in configuring loopback interfaces. It just complicates things and I do not see any real advantage in it. Loopback interfaces have a real advantage when there is more than 1 layer 3 path to the device. But in this situation there is only a single layer 3 path and they are entirely dependent on the operation of the VLAN 1 interface. I think that they would be as well off (and configuration would be more simple) to have remote management use the VLAN 1 interface address as a loopback address.
Perhaps the original poster can clarify the reasons that they chose to implement loopback interfaces on layer 2 switches.
I agree entirely in that i cannot see what advantage is to be gained by using Loopbacks on the layer 2 access switches as each switch will be identifiable by one IP address only.
Where i was a little concerned was in your statement
"I do not believe that both will work if the switch is used as only layer 2"
and i was attempting to clarify what makes a switch layer 2 vs layer 3. Is it just whether you turn on "ip routing". If so then clearly you can have 2 ip addressable interfaces on a L3 capable switch even if you run it as a layer 2 switch.
I believe that we do not have a clear understanding of what the original poster is doing when he says that the access switches are layer 2 only. Your point is well taken that even if most of the layer 3 capabilities are not being used (no ip routing) that if it is a layer 3 capable switch then certain layer 3 capabilities will be present such as the ability to configure more than 1 layer 3 interface. In my original response I was perhaps overly focused on the operation as layer 2 only and not sufficiently focused on the native capability of the platform.
Either you have the IP add of Vlan removed or add a static route on your core switch pointing to loopback & redistribute in to routing protocol running on core.
you are going to need a static route on the core switch
ip route 188.8.131.52 255.255.255.224 184.108.40.206
I see you are redistributing static so this should do the trick.
you may want to apply a default metic in eigrp.
From the core switches (2 of them right?) you need to route the access switch loopback ip address to the access switch vlan1 ip address.
! ip route access_switch_loopback_ip_address 255.255.255.255 access_switch_vlan1_ip_address name access_switch_name-loopback#
ip route 220.127.116.11 255.255.255.255 18.104.22.168 name CC_TF_4506_SW1-L9
NOTE: I use host routing rather than subnet/network routing because I can't open your diagram :) therefore I can't see how all access switches connections to core switch. I assume each access switch is directly connected to the core switches as what the access switch and core switch configuration suggests and good design suggests.
one more item, the reason the loopback is not reachable is because it is a virutal interface. There is not a physical segment associated with the 22.214.171.124 255.255.255.224 segment.
Also since this is a loopback a /32 would be more efficient use of address space
i have a loopback address assigned to even the core switch int the same ip address range.
This would mean the loopback address configured on the access switches would be in the routing table as a connected segment.
Do you think adding a static route to the loopback would help. according to me the connected route would take precedence.
i dont think adding these routes should be of any help
I read from some Ciso document many years ago (book or online, I can't remember) that whatever subnet/network mask you put in the loopback ip address, it will always treat it as /32 or 255.255.255.255. Therefore, your subnetting only affects your documentation not your configuration - that will makes you waste a lot of ip address assignment for loopback interfaces. I maybe mistaken, wait for experts to reply.
There are some things the original poster would have to address to remedy this problem.
-loopbacks on core and access switch is using overlapping addresses.
-there's no route on the core switch to the access switch's loopback address.
BTW, access switch is routing. It has a default route to the core.
The problem is the core switch doesn't know how to route the loopback on the access switch. Reconfigure the loopbacks to a host address on the access/core switches (or) use an address/mask that's not overlapping with the other switch's address space.
Add a static route on the core switch to the loopback address/network of the access switch. Alternatively, you can also run a dynamic routing protocol between the access and core switch.
If you don't want to renumber the addresses, you can add a static host (/32) route on the core switch to access switch's loopback address and that would work as well. Longer prefix should be preferred over the connected network's shorter mask. Your static route would be something like:-
ip route 126.96.36.199 255.255.255.255 188.8.131.52
Sundar thanks for the explanation.
just one thing.i didn't understand when you say Reconfigure the loopbacks to a host address on the access/core switches (or) use an address/mask that's not overlapping with the other switch's address space.
say i reconfigured the loopbacks on the core to 172.16.100.0/24 and on the access switches i configured a loopback 172.16.200.0/24 (200.1, 200.2 ..and so on) what would be my static route on the core would like.
Will it be ip route 172.16.200.0 255.255.255.0 VLAN1 which i dont think will work either.
So in sum i would need to have a /32 on each access or as you said route the /32 from the core which will serve the purpose due to longer mask but doesn't seem to be a good soultion.
Can I ask you, why do you want to configure loopbacks? Both loopback & vlan interfaces are virtual interfaces and they would remain up as long as there's one port on the switch in which vlan1 is active. You don't stand to gain by using a loopback in your setup. Instead, you can configure a vlan interface, preferably a vlan other than vlan 1, for management purposes and add a default gateway/route on the access switches to point to the core switch's managment vlan's address.
This setup would ensure the management traffic remains separate from the user vlan traffic. Any disruption in the user vlan wouldn't affect the management traffic.
I agree with Sundar and Medan on this. If you do not want to run a dynamic routing protocol on your access switches in which case you would need to turn on ip routing anyway then you need to use /32 addresses for your loopbacks and then on your core switches you would need a route added for each switch ie.
ip route "/32 loopback address" 255.255.255.255 "vlan 1 interface of access switch".
You would then need to ensure that these static routes on your core are redistributed into your dynamic routing protocol.
If each switch has an IP address out of the same subnet for loopbacks this won't work because you need to have individual routes for each loopback via the relevant vlan 1 interface.
This is what i did to get it working in my lab - please see previous mail.