Problem with static routing when using ethernet sub-interfaces

6aganguly · ‎03-30-2010

Consider the following scenario:

ROUTER A CONFIG

interface Loopback1
ip address 10.10.10.255 255.255.255.255

interface Loopback2
ip address 20.20.20.255 255.255.255.255

interface FastEthernet0/0
no ip address

interface FastEthernet0/0.1
encapsulation dot1Q 100
ip address 1.1.1.1 255.0.0.0

interface FastEthernet0/0.2
encapsulation dot1Q 200
ip address 2.2.2.1 255.0.0.0

ip route 10.10.10.254 255.255.255.255 FastEthernet0/0.1 1.1.1.2
ip route 20.20.20.254 255.255.255.255 FastEthernet0/0.2 2.2.2.2

ROUTER B CONFIG

interface Loopback1
ip address 10.10.10.254 255.255.255.255

interface Loopback2
ip address 20.20.20.254 255.255.255.255

interface FastEthernet0/0
no ip address

interface FastEthernet0/0.1
encapsulation dot1Q 100
ip address 1.1.1.2 255.0.0.0

interface FastEthernet0/0.2
encapsulation dot1Q 200
ip address 2.2.2.2 255.0.0.0

ip route 10.10.10.255 255.255.255.255 FastEthernet0/0.1 1.1.1.1
ip route 20.20.20.255 255.255.255.255 FastEthernet0/0.2 2.2.2.1

with an ethernet cable connecting the two FastEthernet0/0 router interfaces.

A problem occurs if you admin down one of the sub-interfaces (say FastEthernet0/0.1 on Router A) because the corresponding sub-interface (FastEthernet0/0.1 on Router B in this case) stays up/up. So the static route for destination 10.10.10.255 remains in Router B's route table even though it is unreachable. Assuming Router B is advertising its static routes via (say) EIGRP and is the preferred route to Router A's loopback addresses even though an alternative route exists, the alternative route will not come into play and traffic destined for 10.10.10.255 will continue to be routed to Router B and black-holed.

Is there a way to make an ethernet sub-interface go down when the corresponding sub-interface also does? Or is an ethernet sub-interface always up/up as long as the physical interface is connected?

paolo bevilacqua · ‎03-30-2010

Is that an exercise you're doing ?

6aganguly · ‎03-30-2010

No - this is a scaled-down version of a larger configuration involving BGP traffic load-balancing in a multi-VRF environment. Those details however are irrelevant to the question about the behavior of ethernet sub-interfaces and have been stripped from the scenario.

Jon Marshall · ‎03-30-2010

6aganguly wrote:

with an ethernet cable connecting the two FastEthernet0/0 router interfaces.  
A problem occurs if you admin down one of the sub-interfaces (say FastEthernet0/0.1 on Router A) because the corresponding sub-interface (FastEthernet0/0.1 on Router B in this case) stays up/up.  So the static route for destination 10.10.10.255 remains in Router B's route table even though it is unreachable.  Assuming Router B is advertising its static routes via (say) EIGRP and is the preferred route to Router A's loopback addresses even though an alternative route exists, the alternative route will not come into play and traffic destined for 10.10.10.255 will continue to be routed to Router B and black-holed.
Is there a way to make an ethernet sub-interface go down when the corresponding sub-interface also does?  Or is an ethernet sub-interface always up/up as long as the physical interface is connected?

I'm not aware of being able to make a subinterface go down when a subinterface on another router goes down. However to achieve what you want you can use IP SLA and track the static route eg. on router B -

ip sla monitor 1

type pathEcho protocol ipIcmpEcho 1.1.1.1

frequency <-- choose how often you want the check to be made

ip sla monitor schedule 1 life forever start-time now

track 10 rtr 1 reachability

ip route 10.10.10.255 255.255.255.255 1.1.1.1 track 10

With the above config if 1.1.1.1 is no longer reachable ie. the subinterface goes down then the 10.10.10.255 route will be removed from the routing table on router B. If 1.1.1.1 comes back up the route is added back into the routing table.

Jon

Cisco are currently donating money to the Haiti earthquake appeal for every rating so please consider rating all helpful posts.

6aganguly · ‎04-02-2010

Thanks, Jon! That does look like a viable solution to our problem.