configuring RIP between a Pix and a 4500 switch

Answered Question
Dec 29th, 2009

I have a 4500 switch which is in the center of one of my customers networks.  The 4500 effectively routes between all the production VLAN's for the customer.

I have a PIX connected to the switch in VLAN 1.  I have just configured RIP v1 as follows on the PIX:

rip outside passive version 1

rip inside passive version 1

rip inside default version 1

I used a sniffer and captured the RIP updates between the 4500 and the PIX.  I see the pix sending out a RIP update for the default route.  However I do not ever see the 4500 update it routing table to reflect it

routes on 4500.JPG

It is unclear to me why the 4500 wont update it route table with the default route from the PIX.  I want this to be a secondary default route in case the Main static route goes down.

Thanks

Kevin

I have this problem too.
0 votes
Correct Answer by Jon Marshall about 6 years 10 months ago

k-melton wrote:

Jon

I read the article entitled "Reliable Static Routing Backup Using Object Tracking" that you had sent the link for.  Here is the config I have so far based on what it said to do:

ip sla monitor 1

type echo protocol ipIcmpEcho 209.145.88.29

frequency 30

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

ip local policy route-map ipsla

access-list 150 permit icmp host 209.145.88.30 host 209.145.88.29

access-list 150 deny   icmp any any

route-map ipsla permit 150

match ip address 150

set interface GigabitEthernet0/1

ip route 0.0.0.0 0.0.0.0 209.XXX.88.XX track 123

ip route 0.0.0.0 0.0.0.0  123.456.789.123 254

Here is the output from the sho ip route track table command:

bhigw2#sho ip route track-tab
ip route 0.0.0.0 0.0.0.0 209.xxx.88.xx track 123 state is [up]
bhigw2#

I am hoping this may be all we need.  If you can look this over and tell me what you think.

Have a splendid weekend!

Kevin

Kevin

Had a spare half hour Sunday evening so did a quick lab. Apologies for this but reliable static routing with object tracking is actually overkill for what we need. All you actually need to do is track the route so full config -

ip sla monitor 1

type echo protocol ipIcmpEcho 209.145.88.29

frequency 30

track 123 rtr 1 reachability

ip route 0.0.0.0 0.0.0.0 209.145.88.29 track 123

and that's all you need to add. I tested this by shutting down the ethernet interface on the upstream router ie. the 209.145.88.29 router and once the IP SLA failed on bhigw2 the static route was removed. Once removed it was no longer being redistributed into EIGRP and so was not passed back down the line to the 4500. The 4500 then used it's floating static route pointing to the other gateway. Note, i think i have already mentioned this but make your floating static AD 200 or above.

Once i brought the interface back up and the IP SLA succeeded the route was reinstalled on bhigw2 and then redistributed all the way back to the 4500.

So i think we are there. Let me know if you have any other queries.

Jon

Correct Answer by Jon Marshall about 6 years 10 months ago

k-melton wrote:

One more thing

In response to:

2) if ethernet then we could use IP SLA with object-tracking. If we have to insert another route when we remove the default route we can simply use a dummy route. An additional fail safe would be to use a route-map when we redistribute the statics into EIGRP on the border router. We only allow the default route to be redistributed so whatever dummy route we added would not be redistributed to your ASA.

I think I have object tracking configured,,, did you see this on a post from earlier this morning?  I am pinging the ISP GW from the Border router using IP SLA  (perhaps object tracking is different, I will research). 

Also I had created a route map on the Border router as you had recommended this earlier.  It is only allowing the default route and denying all others..

see below:

route-map static permit 10
match ip address 20


bhigw2#sho access-list 20
Standard IP access list 20
    10 permit 0.0.0.0 (3 matches)
    20 deny   any (42 matches)
bhigw2#

Hope this helps

Kevin

Kevin

You have configured the IP SLA but but you need to tie that into the static route and i'm not aware you have done that altho you may have. Have a look at this link which explains it all -

Object tracking

The route-map does help thanks. It means if we have to insert a dummy route there is no possibility of it getting past the border router.

Jon

Correct Answer by Jon Marshall about 6 years 10 months ago

k-melton wrote:

Raj

I made sure that auto summary is turned off everywhere.  Here are the outputs from bhiedge switch in the DMZ and bhiasaip (inside Firewall)

bhiedge#sho ip eigrp top all
EIGRP-IPv4 Topology Table for AS(100)/ID(172.16.1.7)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 206.248.224.0/24, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (28416/28160), Vlan1
P 192.168.5.0/24, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.3 (28416/28160), Vlan1
P 172.16.1.0/24, 1 successors, FD is 2816, serno 1
        via Connected, Vlan1
bhiedge#

bhiasaip#   sho ei top all

EIGRP-IPv4 Topology Table for AS(100)/ID(192.168.10.20)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 192.168.10.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 192.168.11.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 192.168.5.0 255.255.255.0, 1 successors, FD is 28160, serno 1
        via Connected, Ethernet0/1
P 172.16.1.0 255.255.255.0, 1 successors, FD is 28160, serno 2
        via Connected, Ethernet0/0
P 198.100.100.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 206.248.224.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (30720/28160), Ethernet0/0
bhiasaip#

When i turn on debugging on the Edge switch, I do not see anything happening with respect to EIGRP.  No routes or anything else..

bhiedge#debug ip eigrp
IP-EIGRP Route Events debugging is on
bhiedge#debug ip eigrp top
% Incomplete command.

bhiedge#debug ip eigrp top ?
  WORD  Topology instance name

bhiedge#debug ip eigrp top 100
IP-EIGRP Route Events debugging is on
bhiedge#

Thanks Raj

Kevin

Kevin

I think we need to see all the routing tables from the relevant devices as Raj requested.

Can we have routing tables from border router/outside firewall (op), DMZ switch, inside firewall ip.

Also can you post relevant config from each of the above devices for any static routes that you have added.

Some routers are showing as FD inaccessible which often means that there is a better route available such as a static i think we need to see exactly what is configured on each device.

Jon

Correct Answer by sachinraja about 6 years 10 months ago

Hi kevin

I do see the routes for 206.248.224.0/24 on the dmz and bhiasaip firewall.... these are the routes which are propagated from the bhiasaop firewall right ? I see the following:

P 206.248.224.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (30720/28160), Ethernet0/0

can you give a show ip route on dmz and bhiasaip firewall and confirm if these routes are installed in the routing table ? are you having issues with reachability ?

Regards

Raj

Correct Answer by sachinraja about 6 years 10 months ago

It is such an interesting post, and thought of barging in... i was reading the entire post for the past 20 mins and have a fair idea .. Sorry if i misunderstood something or asking questions which have already been answered here..

the dmz switch bhiedge is layer 3 ? I saw in some posts before that it was layer 2 ? are the L3 DMZ terminating on the bhiasaop firewall or the bhiedge switch (for the VLANs 172.16.1.x) ? can you please give "show ip eigrp neighbor" on the ASA bhiasaop firewall to check if it has a neighbor relation with bhiedge switch ? Why dont u have a direct eigrp neighborship with bhiasaip instead of having the switch in between (on L3) ? incase the dmz switch has eigrp configured, make sure you dont have passive interface configured for the layer 3 vlan ip subnets..

Raj

Correct Answer by Jon Marshall about 6 years 10 months ago

k-melton wrote:

Because I have static routes on the Border router which point to the client inside network addresses, I had to write the following route-map and ACL

route-map static permit 10
match ip address 20

bhigw2#sho access-list 20
Standard IP access list 20
    10 permit 0.0.0.0 (2 matches)
    20 deny   any (28 matches)

Once I did this, I could see the 0 route advertised out.  What I am not seeing is the 0 route in the ASA (his EIGRP neighbor) route table. The only 0 route is the static configured on it... 

thx

Kevin

Kevin

If you have a statically configured default route on the ASA then a default route learnt from EIGRP will not replace it or be entered into the routing table. You would need to remove the statically configured route and then the EIGRP route would be used.

Presumably the default route from EIGRP is using the same next-hop as the statically configured default route on the ASA ?

Before you do this run this command on the ASA "sh eigrp topology all-links". You should see the EIGRP routes learnt from your border router and hopefully the default route will be there.

Jon

Correct Answer by Jon Marshall about 6 years 10 months ago

k-melton wrote:

Jon

Sorry for the delay in my response. 

We have a Metro Ethernet connection to the ISP...

Is the command that I use to redistribute the static

router eigrp 100

redistribute static ( i am not sure of the rest)  seems the options are route-map or metric

Thanks Jon

Kevin

Kevin

You don't need to specify a metric when you redistribute static routes into EIGRP (altho you do need a metric for redistributing everything else into EIGRP !!).

The route-map would be used if you had a number of static routes on the device and you only wanted to redistributed some of them.

So "redistribute static" should do the trick for you.

Jon

Correct Answer by Jon Marshall about 6 years 11 months ago

k-melton wrote:

John

I am experimenting with using a floating static default route here at this client as one of the options which you had recommended.

Here is a snapshot of the ip routes as configured on the core switch:

bhicore#sho run | i ip route

ip route 0.0.0.0 0.0.0.0 192.168.5.8

ip route 0.0.0.0 0.0.0.0 198.100.100.81 200

The 192.168.5.8 address is the inside interface of the ASA and leads to our Primary Metro Ethernet connection.

The 198.100.100.81 address is the inside interface of the PIX and leads to our Secondary DSL connection.

For testing:  If I unplug the inside interface of the ASA, will the router know it is not there?  How will it know to roll over to the Secondary connection.

Thanks

Kevin

Kevin

That's one of the problems with ethernet ie. the router may not realise the ASA has gone. That is why i suggested using a floating static on the router/switch pointing to the pix and then use the dynamic routing protocol for the ASA. EIGRP/RIP/OSPF will all have lower ADs than 200 so it should be used unless the ASA fails and then the route will not be sent to the switch.

If you want to use 2 static routes you will need to track the state of the ASA interface using IP SLA which your switch may or may not support.

Jon

Correct Answer by Jon Marshall about 6 years 11 months ago

k-melton wrote:

Jon

You did not misunderstand.  I have one static route configured for default and currently it provides the only path out to the Internet.  Since we do have a 2nd DSL connection for the client, I wanted to have a backup default route so that if something happens to the main one, I wont loose connectivity to the Internet.

The static route configured on the 4500 for default points to an ASA.  I guess I need to turn on RIP on the ASA as well and then remove the static route from the 4500 altogether?  Will I see both default routes on the ASA then, Jon?

Thanks

Kevin

Kevin

You don't necessarily need to run RIP on anything. You could actually have a floating static route on the 4500 ie,

ip route 0.0.0.0 0.0.0.0  200

the 200 is important because that is the AD. So your existing default-route is still the ASA, If the ASA is lost then the static route will be removed and the floating static used. If the ASA comes back online then the original static route will be used again.

Sounds great but because they are ethernet connections you would need to track the availability of the next-hop ie. the ASA internal interface. You do this with IP SLA which your switch may or may not support - depends on IOS version.

Alternatively you could -

1) have a floating static default-route

ip route 0.0.0.0 0.0.0 200

2) remove the other default route that points to the ASA

3) turn on RIP on the ASA and advertise a default route to the 4500.

Because RIP has a lower AD than 200 which is the AD of your floating static the RIP route would be used. If the ASA failed it would no longer advertise the route and then the floating static would be used.

This would be a simpler solution if you are happy to turn on RIP on your ASA.

Out of interest any reason why RIP, is this what you run internally ?. I ask because the ASA supports OSPF and as of v8.x code EIGRP.

Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.9 (19 ratings)
Loading.
Jon Marshall Tue, 12/29/2009 - 11:43

k-melton wrote:

I have a 4500 switch which is in the center of one of my customers networks.  The 4500 effectively routes between all the production VLAN's for the customer.

I have a PIX connected to the switch in VLAN 1.  I have just configured RIP v1 as follows on the PIX:

rip outside passive version 1

rip inside passive version 1

rip inside default version 1

I used a sniffer and captured the RIP updates between the 4500 and the PIX.  I see the pix sending out a RIP update for the default route.  However I do not ever see the 4500 update it routing table to reflect it

It is unclear to me why the 4500 wont update it route table with the default route from the PIX.  I want this to be a secondary default route in case the Main static route goes down.

Thanks

Kevin

Kevin

Could you clarify something ?

You have a static default-route configured on the 4500 and you have the pix advertising a default-route to the 4500 with RIP and you don't see the RIP route in the routing table on the 4500 - is that what you are saying ?

If so, you won't see it until the static route that you have configured is removed because the static configured route will have a lower AD and so be the one entered into the routing table.

If i have misunderstood please let me know.

Jon

Kevin Melton Tue, 12/29/2009 - 11:47

Jon

You did not misunderstand.  I have one static route configured for default and currently it provides the only path out to the Internet.  Since we do have a 2nd DSL connection for the client, I wanted to have a backup default route so that if something happens to the main one, I wont loose connectivity to the Internet.

The static route configured on the 4500 for default points to an ASA.  I guess I need to turn on RIP on the ASA as well and then remove the static route from the 4500 altogether?  Will I see both default routes on the ASA then, Jon?

Thanks

Kevin

Correct Answer
Jon Marshall Tue, 12/29/2009 - 11:50

k-melton wrote:

Jon

You did not misunderstand.  I have one static route configured for default and currently it provides the only path out to the Internet.  Since we do have a 2nd DSL connection for the client, I wanted to have a backup default route so that if something happens to the main one, I wont loose connectivity to the Internet.

The static route configured on the 4500 for default points to an ASA.  I guess I need to turn on RIP on the ASA as well and then remove the static route from the 4500 altogether?  Will I see both default routes on the ASA then, Jon?

Thanks

Kevin

Kevin

You don't necessarily need to run RIP on anything. You could actually have a floating static route on the 4500 ie,

ip route 0.0.0.0 0.0.0.0  200

the 200 is important because that is the AD. So your existing default-route is still the ASA, If the ASA is lost then the static route will be removed and the floating static used. If the ASA comes back online then the original static route will be used again.

Sounds great but because they are ethernet connections you would need to track the availability of the next-hop ie. the ASA internal interface. You do this with IP SLA which your switch may or may not support - depends on IOS version.

Alternatively you could -

1) have a floating static default-route

ip route 0.0.0.0 0.0.0 200

2) remove the other default route that points to the ASA

3) turn on RIP on the ASA and advertise a default route to the 4500.

Because RIP has a lower AD than 200 which is the AD of your floating static the RIP route would be used. If the ASA failed it would no longer advertise the route and then the floating static would be used.

This would be a simpler solution if you are happy to turn on RIP on your ASA.

Out of interest any reason why RIP, is this what you run internally ?. I ask because the ASA supports OSPF and as of v8.x code EIGRP.

Jon

Kevin Melton Tue, 12/29/2009 - 12:22

Jon

I did not realize until your reply that the ASA supports EIGRP. I am running 8.2.1 and checked it out and right you are.  I may try to configure that instead.

RIP was just a lowest common denominator that I was going to use.  I had forgotten about floating static routes.

Thanks for your help.  I will keep you posted.

Kevin Melton Tue, 01/05/2010 - 08:19

John

I am experimenting with using a floating static default route here at this client as one of the options which you had recommended.

Here is a snapshot of the ip routes as configured on the core switch:

bhicore#sho run | i ip route

ip route 0.0.0.0 0.0.0.0 192.168.5.8

ip route 0.0.0.0 0.0.0.0 198.100.100.81 200

The 192.168.5.8 address is the inside interface of the ASA and leads to our Primary Metro Ethernet connection.

The 198.100.100.81 address is the inside interface of the PIX and leads to our Secondary DSL connection.

For testing:  If I unplug the inside interface of the ASA, will the router know it is not there?  How will it know to roll over to the Secondary connection.

Thanks

Kevin

Correct Answer
Jon Marshall Tue, 01/05/2010 - 08:30

k-melton wrote:

John

I am experimenting with using a floating static default route here at this client as one of the options which you had recommended.

Here is a snapshot of the ip routes as configured on the core switch:

bhicore#sho run | i ip route

ip route 0.0.0.0 0.0.0.0 192.168.5.8

ip route 0.0.0.0 0.0.0.0 198.100.100.81 200

The 192.168.5.8 address is the inside interface of the ASA and leads to our Primary Metro Ethernet connection.

The 198.100.100.81 address is the inside interface of the PIX and leads to our Secondary DSL connection.

For testing:  If I unplug the inside interface of the ASA, will the router know it is not there?  How will it know to roll over to the Secondary connection.

Thanks

Kevin

Kevin

That's one of the problems with ethernet ie. the router may not realise the ASA has gone. That is why i suggested using a floating static on the router/switch pointing to the pix and then use the dynamic routing protocol for the ASA. EIGRP/RIP/OSPF will all have lower ADs than 200 so it should be used unless the ASA fails and then the route will not be sent to the switch.

If you want to use 2 static routes you will need to track the state of the ASA interface using IP SLA which your switch may or may not support.

Jon

Kevin Melton Tue, 01/05/2010 - 12:11

Jon

I am including a network diagram with the addresses striken for you to take a look at.  I am not so much concerned that the ASA may fail, but rather that my Metro Ethernet connection will fail.  I think I actually am going to have to set up a dynamic routing protocol between my Border router (bhigw2), my Outside PIX (bhiasaop) and my Inside ASA (bhiasaip).  Otherwise I am not sure how the Inside ASA would ever know that the default route is missing off of the Border router.

If you could please confirm that in fact I will have to turn on dynamic routing updates on the mentioned devices I would appreciate it.

I think this will make sense to you once you look at the attached drawing.

Thanks Jon

Kevin

Jon Marshall Tue, 01/05/2010 - 14:38

Kevin

Apologies but i can't read visios on my laptop. Can you post it as a .jpg/.png file instead ?

Jon

Jon Marshall Tue, 01/05/2010 - 16:47

k-melton wrote:

Jon

I am including a network diagram with the addresses striken for you to take a look at.  I am not so much concerned that the ASA may fail, but rather that my Metro Ethernet connection will fail.  I think I actually am going to have to set up a dynamic routing protocol between my Border router (bhigw2), my Outside PIX (bhiasaop) and my Inside ASA (bhiasaip).  Otherwise I am not sure how the Inside ASA would ever know that the default route is missing off of the Border router.

If you could please confirm that in fact I will have to turn on dynamic routing updates on the mentioned devices I would appreciate it.

I think this will make sense to you once you look at the attached drawing.

Thanks Jon

Kevin

Kevin

You are right although it is a little more complicated than that. You could use IP SLA  tracking on your 4500 and check the reachability of the next-hop from your border router ie. where you border sends traffic to after it leaves your LAN.

Or as you say you can use a routing protocol but note you still need to use IP SLA tracking but this time on the border router. Because it is ethernet you need to track the next-hop from the border router. If that is up then advertise the default-route into your routing protocol which will then get propogated to your pix and ASA. If it is not up then the border router should not advertise it to the pix -> asa -> 4500. Then the floating static on the 4500 will kick in and it should go via the other link.

Note if you are going to run dynamic routing between border router/pix/asa make sure you use authentication and that the border router is secure.

Either way involves a fair bit of extra config

1) IP SLA on 4500, if supported (need to know IOS and feature set). You would need to allow ICMP through both firewalls and the border router to get to the next-hop you are checking for reachability

2) IP SLA on border router (will be supported) - you need to enable routing protocol on all intermediate devices

Jon

Kevin Melton Tue, 01/12/2010 - 10:37

Jon

the current IOS running on my 4500 Sup II+ module is Version 12.2(46)SG, RELEASE SOFTWARE (fc1)

How can we tell if this will support IP SLA.

I have the following available in the IOS I know from using context sensative help:

bhicore#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
bhicore(config)#ip sla ?
  key-chain  Use MD5 authentication for IP SLAs control message
  responder  Enable IP SLAs Responder

bhicore(config)#ip sla

thanks Jon

Kevin

Jon Marshall Tue, 01/12/2010 - 12:17

k-melton wrote:

Jon

the current IOS running on my 4500 Sup II+ module is Version 12.2(46)SG, RELEASE SOFTWARE (fc1)

How can we tell if this will support IP SLA.

I have the following available in the IOS I know from using context sensative help:

bhicore#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
bhicore(config)#ip sla ?
  key-chain  Use MD5 authentication for IP SLAs control message
  responder  Enable IP SLAs Responder

bhicore(config)#ip sla

thanks Jon

Kevin

Kevin

What feature set are you running ?

Jon

Kevin Melton Tue, 01/12/2010 - 13:43

IP Base?..  here is the sho ver output

bhicore#sho ver
Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500-IPBASEK9-M), Version 12.2(46)SG, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Fri 27-Jun-08 16:56 by prod_rel_team
Image text-base: 0x10000000, data-base: 0x11ABEC24

ROM: 12.2(20r)EW1
Dagobah Revision 226, Swamp Revision 34

thx

Kevin

Jon Marshall Tue, 01/12/2010 - 14:07

k-melton wrote:

IP Base?..  here is the sho ver output

bhicore#sho ver
Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500-IPBASEK9-M), Version 12.2(46)SG, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Fri 27-Jun-08 16:56 by prod_rel_team
Image text-base: 0x10000000, data-base: 0x11ABEC24

ROM: 12.2(20r)EW1
Dagobah Revision 226, Swamp Revision 34

thx

Kevin

Kevin

Bad news unfortunately. You need Enterprise Services to run PBR but there is no Enterprise Services for the SupII+. I think PBR is only supported on Supervisor IV upwards on the 4500 switches.

Jon

Kevin Melton Thu, 01/14/2010 - 08:55

This makes me want to ask then about EIGRP.  I understand that it is a bit overkill for this little network, however because it is link state would it not suffice?  I think that all the devices will support it on the ASA side leading to the Internet (Border Router, ASA Outside, DMZ switch which is a 3550 model, and Inside ASA?

If the Border router loses its Ethernet facing outside, then would EIGRP propogate the loss since it is a topology change down the line until it reached the Core Router?

Thanks Jon

Kevin

Jon Marshall Thu, 01/14/2010 - 09:16

k-melton wrote:

This makes me want to ask then about EIGRP.  I understand that it is a bit overkill for this little network, however because it is link state would it not suffice?  I think that all the devices will support it on the ASA side leading to the Internet (Border Router, ASA Outside, DMZ switch which is a 3550 model, and Inside ASA?

If the Border router loses its Ethernet facing outside, then would EIGRP propogate the loss since it is a topology change down the line until it reached the Core Router?

Thanks Jon

Kevin

Kevin

DMZ 3550 switch, if this is L2 then it doesn't need to support EIGRP. If L3 then you need EMI image on it.

You would have a default-route on the border router pointing to the next-hop ISP address and redistribute this into EIGRP. This will then be an EIGRP external route with an AD of 170 so make sure your floating static has a higher AD.

Once the route is removed from the border router then yes it will propogate all the way back to your 4500 and it will be removed and so the floating static you have configured on your 4500 to the other ASA will then be used. The only thing i'm not 100% sure about is will the route be removed if the interface goes down and i'm not sure it will because you are not receiving this route from your ISP, you are actually originating it on the border router.

So it will need testing. If i have time tomorrow i will lab it up for you.

Edit - actually if the interface goes down the route will be removed. It's more a question of what happens if the remote ISP router goes down that needs testing. What connectivity is there between your border router and the ISP router ie. is it ethernet or serial ?

Jon

Kevin Melton Tue, 01/26/2010 - 11:44

Jon

Sorry for the delay in my response. 

We have a Metro Ethernet connection to the ISP...

Is the command that I use to redistribute the static

router eigrp 100

redistribute static ( i am not sure of the rest)  seems the options are route-map or metric

Thanks Jon

Kevin

Correct Answer
Jon Marshall Tue, 01/26/2010 - 11:47

k-melton wrote:

Jon

Sorry for the delay in my response. 

We have a Metro Ethernet connection to the ISP...

Is the command that I use to redistribute the static

router eigrp 100

redistribute static ( i am not sure of the rest)  seems the options are route-map or metric

Thanks Jon

Kevin

Kevin

You don't need to specify a metric when you redistribute static routes into EIGRP (altho you do need a metric for redistributing everything else into EIGRP !!).

The route-map would be used if you had a number of static routes on the device and you only wanted to redistributed some of them.

So "redistribute static" should do the trick for you.

Jon

Kevin Melton Tue, 01/26/2010 - 12:30

Because I have static routes on the Border router which point to the client inside network addresses, I had to write the following route-map and ACL

route-map static permit 10
match ip address 20

bhigw2#sho access-list 20
Standard IP access list 20
    10 permit 0.0.0.0 (2 matches)
    20 deny   any (28 matches)

Once I did this, I could see the 0 route advertised out.  What I am not seeing is the 0 route in the ASA (his EIGRP neighbor) route table. The only 0 route is the static configured on it... 

thx

Kevin

Correct Answer
Jon Marshall Tue, 01/26/2010 - 12:38

k-melton wrote:

Because I have static routes on the Border router which point to the client inside network addresses, I had to write the following route-map and ACL

route-map static permit 10
match ip address 20

bhigw2#sho access-list 20
Standard IP access list 20
    10 permit 0.0.0.0 (2 matches)
    20 deny   any (28 matches)

Once I did this, I could see the 0 route advertised out.  What I am not seeing is the 0 route in the ASA (his EIGRP neighbor) route table. The only 0 route is the static configured on it... 

thx

Kevin

Kevin

If you have a statically configured default route on the ASA then a default route learnt from EIGRP will not replace it or be entered into the routing table. You would need to remove the statically configured route and then the EIGRP route would be used.

Presumably the default route from EIGRP is using the same next-hop as the statically configured default route on the ASA ?

Before you do this run this command on the ASA "sh eigrp topology all-links". You should see the EIGRP routes learnt from your border router and hopefully the default route will be there.

Jon

Kevin Melton Tue, 01/26/2010 - 13:22

I ran the command "sho eigrp top all-links" as you had indicated.  This showed

the learned routes just as you had indicated (way to go Jon!).

Here is a snapshot:

bhiasaop# sho eigrp top all

EIGRP-IPv4 Topology Table for AS(100)/ID(206.248.224.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 0.0.0.0 0.0.0.0, 0 successors, FD is Inaccessible, serno 0
        via 206.248.224.1 (33280/30720), Ethernet0/0
P 192.168.5.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.3 (30720/28160), Ethernet0/1
P 172.16.1.0 255.255.255.0, 1 successors, FD is 28160, serno 2
        via Connected, Ethernet0/1
P 206.248.224.2 255.255.255.255, 0 successors, FD is Inaccessible, serno 0
        via 206.248.224.1 (30720/28160), Ethernet0/0
P 206.248.224.0 255.255.255.0, 1 successors, FD is 28160, serno 3
        via Connected, Ethernet0/0

For some reason, the ASA is not propogating these routes inward towards the DMZ switch.  I have tried toggling auto-summary on the ASA and receive these messages while running debug on the DMZ switch:

bhiedge#
Jan 26 16:18:59.672: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(100) 100: Neighbor 172.16.1.2 (Vlan1) is down: peer restarted
Jan 26 16:19:00.140: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(100) 100: Neighbor 172.16.1.2 (Vlan1) is up: new adjacency
Jan 26 16:19:01.680: EIGRP-IPv4(Default-IP-Routing-Table:100): 172.16.1.0/24 - do advertise out Vlan1
Jan 26 16:19:01.680: EIGRP-IPv4:(100): Int 206.248.224.0/24 M 28416 - 25600 2816 SM 28160 - 25600 2560
Jan 26 16:19:01.680: EIGRP-IPv4(Default-IP-Routing-Table:100): 206.248.224.0/24 routing table not updated thru 172.16.1.2
Jan 26 16:19:01.688: EIGRP-IPv4(Default-IP-Routing-Table:100): 172.16.1.0/24 - do advertise out Vlan1
Jan 26 16:19:01.688: EIGRP-IPv4:(100): Int 206.248.224.0/24 M 28416 - 25600 2816 SM 28160 - 25600 2560
Jan 26 16:19:01.700: EIGRP-IPv4:(100): Int 206.248.224.0/24 M 28416 - 25600 2816 SM 28160 - 25600 2560

What am I missing Jon?

Kevin

Correct Answer
sachinraja Tue, 01/26/2010 - 13:39

It is such an interesting post, and thought of barging in... i was reading the entire post for the past 20 mins and have a fair idea .. Sorry if i misunderstood something or asking questions which have already been answered here..

the dmz switch bhiedge is layer 3 ? I saw in some posts before that it was layer 2 ? are the L3 DMZ terminating on the bhiasaop firewall or the bhiedge switch (for the VLANs 172.16.1.x) ? can you please give "show ip eigrp neighbor" on the ASA bhiasaop firewall to check if it has a neighbor relation with bhiedge switch ? Why dont u have a direct eigrp neighborship with bhiasaip instead of having the switch in between (on L3) ? incase the dmz switch has eigrp configured, make sure you dont have passive interface configured for the layer 3 vlan ip subnets..

Raj

Kevin Melton Wed, 01/27/2010 - 16:04

Raj

Dont feel like you are barging in.  I welcome your help with this.  John has been very gracious with his expertise on this and other posts.

To answer your questions

the dmz switch bhiedge is layer 3 ?

  Yes it is L3.  I have the one VLAN configured on it and it has an ip address on it that functions as the default gateway for the 4 servers in our DMZ.

Can you please give "show ip eigrp neighbor" on the ASA bhiasaop firewall to check if it has a neighbor relation with bhiedge switch ?

bhiasaop# sho eigrp nei
EIGRP-IPv4 neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   172.16.1.7              Et0/1            13     1d02h 3    200   0   44
2   172.16.1.3              Et0/1            14     1d02h 1    200   0   72
0   206.248.224.1           Et0/0            12     1d02h 6    200   0   41
bhiasaop#

Why dont u have a direct eigrp neighborship with bhiasaip instead of having the switch in between (on L3) ?

I think they are neighbors too?..

incase the dmz switch has eigrp configured, make sure you dont have passive interface configured for the layer 3 vlan ip subnets..

I dont have it configured as passive.  See below:

bhiedge#sho run | begin router
router eigrp 100
network 172.16.0.0

Thanks Raj.  Like I said, any input is welcome.

Kevin


sachinraja Wed, 01/27/2010 - 17:01

Hi Kevin

Even if the DMZ switch isnt L2, it should learn the routes propagated by bhiasaop.. as Jon said, give a "no auto-summary" on the eigrp process to make sure it can support classless routing.. the outputs on asa bhiasaop looks good.. can you give us the output on bhiedge switch and bhiasaip of the EIGRP topology database ? show ip eigrp topology ? are these networks being advertised back from bhipix ??

can you make sure you have the internal network 172.16.1.0 on the switch and bhiasaip pix ? have no auto-summary on all switches and PIX running EIGRP...

lastly - you can run debug eigrp neigbor to check if the routes are being received on the dmz switch ?

note - if you want to make bhiedge a layer 3 switch, you should probably split up the broadcast domain between bhiasaop and bhiasaip... have seperate /30 networks between the switch and the firewalls, so that there are prominant eigrp neighbors defined...

Hope this helps.. all the best

Raj

Kevin Melton Wed, 01/27/2010 - 17:36

Raj

I made sure that auto summary is turned off everywhere.  Here are the outputs from bhiedge switch in the DMZ and bhiasaip (inside Firewall)

bhiedge#sho ip eigrp top all
EIGRP-IPv4 Topology Table for AS(100)/ID(172.16.1.7)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 206.248.224.0/24, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (28416/28160), Vlan1
P 192.168.5.0/24, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.3 (28416/28160), Vlan1
P 172.16.1.0/24, 1 successors, FD is 2816, serno 1
        via Connected, Vlan1
bhiedge#

bhiasaip#   sho ei top all

EIGRP-IPv4 Topology Table for AS(100)/ID(192.168.10.20)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 192.168.10.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 192.168.11.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 192.168.5.0 255.255.255.0, 1 successors, FD is 28160, serno 1
        via Connected, Ethernet0/1
P 172.16.1.0 255.255.255.0, 1 successors, FD is 28160, serno 2
        via Connected, Ethernet0/0
P 198.100.100.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 206.248.224.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (30720/28160), Ethernet0/0
bhiasaip#

When i turn on debugging on the Edge switch, I do not see anything happening with respect to EIGRP.  No routes or anything else..

bhiedge#debug ip eigrp
IP-EIGRP Route Events debugging is on
bhiedge#debug ip eigrp top
% Incomplete command.

bhiedge#debug ip eigrp top ?
  WORD  Topology instance name

bhiedge#debug ip eigrp top 100
IP-EIGRP Route Events debugging is on
bhiedge#

Thanks Raj

Kevin

Correct Answer
sachinraja Wed, 01/27/2010 - 17:49

Hi kevin

I do see the routes for 206.248.224.0/24 on the dmz and bhiasaip firewall.... these are the routes which are propagated from the bhiasaop firewall right ? I see the following:

P 206.248.224.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (30720/28160), Ethernet0/0

can you give a show ip route on dmz and bhiasaip firewall and confirm if these routes are installed in the routing table ? are you having issues with reachability ?

Regards

Raj

Kevin Melton Thu, 01/28/2010 - 08:18

No issues with reachability Raj.  I have static routes configured for all networks everywhere.  This is a milestone as I am

attempting for the first time to implement some dynamic routing on the network in order to facilitate the ability to failover to a different route to 0.0.0.0 if the main Internet connection fails.  This is pretty well documented within the earlier parts of this chain between John and I.

I am simply trying to get the 0.0.0.0 route advertised by the Border Router to propogate down the line via EIGRP until it makes it into our Core Router.

I can post the route tables when I get onsite tomorrow if necessary.  But the main focus and next step should be why the 0 route is not making it from the bhiasaop device to the bhiedge switch, as EIGRP ought to be shipping it to the switch from the Firewall.  I am not sure why this is not happening.

Thanks

Kevin

Correct Answer
Jon Marshall Thu, 01/28/2010 - 04:22

k-melton wrote:

Raj

I made sure that auto summary is turned off everywhere.  Here are the outputs from bhiedge switch in the DMZ and bhiasaip (inside Firewall)

bhiedge#sho ip eigrp top all
EIGRP-IPv4 Topology Table for AS(100)/ID(172.16.1.7)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 206.248.224.0/24, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (28416/28160), Vlan1
P 192.168.5.0/24, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.3 (28416/28160), Vlan1
P 172.16.1.0/24, 1 successors, FD is 2816, serno 1
        via Connected, Vlan1
bhiedge#

bhiasaip#   sho ei top all

EIGRP-IPv4 Topology Table for AS(100)/ID(192.168.10.20)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 192.168.10.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 192.168.11.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 192.168.5.0 255.255.255.0, 1 successors, FD is 28160, serno 1
        via Connected, Ethernet0/1
P 172.16.1.0 255.255.255.0, 1 successors, FD is 28160, serno 2
        via Connected, Ethernet0/0
P 198.100.100.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 192.168.5.1 (28416/2816), Ethernet0/1
P 206.248.224.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.2 (30720/28160), Ethernet0/0
bhiasaip#

When i turn on debugging on the Edge switch, I do not see anything happening with respect to EIGRP.  No routes or anything else..

bhiedge#debug ip eigrp
IP-EIGRP Route Events debugging is on
bhiedge#debug ip eigrp top
% Incomplete command.

bhiedge#debug ip eigrp top ?
  WORD  Topology instance name

bhiedge#debug ip eigrp top 100
IP-EIGRP Route Events debugging is on
bhiedge#

Thanks Raj

Kevin

Kevin

I think we need to see all the routing tables from the relevant devices as Raj requested.

Can we have routing tables from border router/outside firewall (op), DMZ switch, inside firewall ip.

Also can you post relevant config from each of the above devices for any static routes that you have added.

Some routers are showing as FD inaccessible which often means that there is a better route available such as a static i think we need to see exactly what is configured on each device.

Jon

Kevin Melton Thu, 01/28/2010 - 08:23

Jon

I can put these routing tables in later if necessary, but I can definitely tell you that all routes are configured statically at this point.  This is how the network was first built.  It was simple and we did not see the need to run any dynamic protocol.  Now we are at a point where we can see how it would be beneficial to have the ability to fail over with respect to Internet access (we have many processes at this customer that depend on the Internet fo transactions) to keep things up.

This was not really an option before as the alternate Internet connection was a DSL connection that was only at 1 mg or some small figure.  It has since been upgraded to a 10 mg pipe.

Thanks Jon

Kevin

Jon Marshall Thu, 01/28/2010 - 08:40

k-melton wrote:

Jon

I can put these routing tables in later if necessary, but I can definitely tell you that all routes are configured statically at this point.  This is how the network was first built.  It was simple and we did not see the need to run any dynamic protocol.  Now we are at a point where we can see how it would be beneficial to have the ability to fail over with respect to Internet access (we have many processes at this customer that depend on the Internet fo transactions) to keep things up.

This was not really an option before as the alternate Internet connection was a DSL connection that was only at 1 mg or some small figure.  It has since been upgraded to a 10 mg pipe.

Thanks Jon

Kevin

Kevin

I believe that if the route is marked as FD inaccessible in the topology table as it is on the op firewall then it will not be advertised to any downstream neighbors ie. your 3550 DMZ switch. So until you remove the static route from the op firewall it isn't going to work which is a bit of a catch22. I say believe but i need to test unless Raj can confirm one way or the other.

What you could do is have a static default route on the ASA with an AD > 170 (lets say 200).  You could then remove your existing default static route. The new default with AD 200 would be used if EIGRP didn't work properly so you shouldn't lose connectivity. If EIGRP did work properly and the ASA (op) received a default route from the border router then this route would be used and should therefore hopefully not be marked as inaccessible in the topology table.

I'll have a quick test, altho i don't have ASA but should be able to do same thing with routers.

Jon

Jon Marshall Thu, 01/28/2010 - 10:31

Kevin

Just did a quick test and if a route is marked as inaccessible in the topology table it won't be advertised to any neighbors.

So what is happening is that your ASA (op) is receiving the default route from the border router via EIGRP. But you ASA also has a static default route configured on it. Because of the AD (administrative distance) the static route is preferred and so the EIGRP default route is marked as inaccessible and is not advertised to your DMZ switch.

Solution is as i posted in previous response to this post.

Jon

Kevin Melton Thu, 01/28/2010 - 13:11

Thanks for testing that out in a lab environment Jon.  I will have to strip out the static route tomorrow off of the ASA and see if thereafter EIGRP will propogate it down to the bhiedge switch. 

I will let you know Jon.

Kevin

Jon Marshall Tue, 01/26/2010 - 14:10

k-melton wrote:

I ran the command "sho eigrp top all-links" as you had indicated.  This showed

the learned routes just as you had indicated (way to go Jon!).

Here is a snapshot:

bhiasaop# sho eigrp top all

EIGRP-IPv4 Topology Table for AS(100)/ID(206.248.224.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 0.0.0.0 0.0.0.0, 0 successors, FD is Inaccessible, serno 0
        via 206.248.224.1 (33280/30720), Ethernet0/0
P 192.168.5.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.3 (30720/28160), Ethernet0/1
P 172.16.1.0 255.255.255.0, 1 successors, FD is 28160, serno 2
        via Connected, Ethernet0/1
P 206.248.224.2 255.255.255.255, 0 successors, FD is Inaccessible, serno 0
        via 206.248.224.1 (30720/28160), Ethernet0/0
P 206.248.224.0 255.255.255.0, 1 successors, FD is 28160, serno 3
        via Connected, Ethernet0/0

For some reason, the ASA is not propogating these routes inward towards the DMZ switch.  I have tried toggling auto-summary on the ASA and receive these messages while running debug on the DMZ switch:

bhiedge#
Jan 26 16:18:59.672: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(100) 100: Neighbor 172.16.1.2 (Vlan1) is down: peer restarted
Jan 26 16:19:00.140: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(100) 100: Neighbor 172.16.1.2 (Vlan1) is up: new adjacency
Jan 26 16:19:01.680: EIGRP-IPv4(Default-IP-Routing-Table:100): 172.16.1.0/24 - do advertise out Vlan1
Jan 26 16:19:01.680: EIGRP-IPv4:(100): Int 206.248.224.0/24 M 28416 - 25600 2816 SM 28160 - 25600 2560
Jan 26 16:19:01.680: EIGRP-IPv4(Default-IP-Routing-Table:100): 206.248.224.0/24 routing table not updated thru 172.16.1.2
Jan 26 16:19:01.688: EIGRP-IPv4(Default-IP-Routing-Table:100): 172.16.1.0/24 - do advertise out Vlan1
Jan 26 16:19:01.688: EIGRP-IPv4:(100): Int 206.248.224.0/24 M 28416 - 25600 2816 SM 28160 - 25600 2560
Jan 26 16:19:01.700: EIGRP-IPv4:(100): Int 206.248.224.0/24 M 28416 - 25600 2816 SM 28160 - 25600 2560

What am I missing Jon?

Kevin

Kevin

I was so busy concentrating on the default route propogation that i didn't notice that your DMZ switch was L3. Raj is right, this really should be L2 unless you have a very good reason to make it L3 and it would remove one more EIGRP peer.

For some reason the switch is seeing the routes as inaccessible with FD. Can you post output of "sh eigrp topology all-links" from the ASA and as Raj suggested "sh ip eigrp neigh".

I would look to make the switch L2 as routing on a DMZ switch really shouldn't be enabled. Is there a specific reason you wanted it as L3 ?

By the way, it's very rare you want "auto-summary" with EIGRP so stick with "no auto-summary" on all devices.

Jon

Kevin Melton Wed, 01/27/2010 - 16:10

Jon

I dont mind making the switch L2.  I just need to make sure that if I change their GW to the ASA @ 172.16.1.2, they would still be able to communicate with the devices on the inside networks.  I was unsure if the ASA would act as a gateway for the inside networks.  I can test this when I am back onsite on Friday.

Here are the outputs  you requested:

bhiasaop# sho eigrp nei
EIGRP-IPv4 neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   172.16.1.7              Et0/1            13     1d02h 3    200   0   44
2   172.16.1.3              Et0/1            14     1d02h 1    200   0   72
0   206.248.224.1           Et0/0            12     1d02h 6    200   0   41
bhiasaop#

bhiasaop# sh eigrp topology all-links

EIGRP-IPv4 Topology Table for AS(100)/ID(206.248.224.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 0.0.0.0 0.0.0.0, 0 successors, FD is Inaccessible, serno 0
        via 206.248.224.1 (33280/30720), Ethernet0/0
P 192.168.5.0 255.255.255.0, 0 successors, FD is Inaccessible, serno 0
        via 172.16.1.3 (30720/28160), Ethernet0/1
P 172.16.0.0 255.255.0.0, 1 successors, FD is 28160, serno 46
        via Summary (28160/0), Null0
P 172.16.1.0 255.255.255.0, 1 successors, FD is 28160, serno 2
        via Connected, Ethernet0/1
P 206.248.224.2 255.255.255.255, 0 successors, FD is Inaccessible, serno 0
        via 206.248.224.1 (30720/28160), Ethernet0/0
P 206.248.224.0 255.255.255.0, 1 successors, FD is 28160, serno 3
        via Connected, Ethernet0/0
bhiasaop#

Thanks John

Kevin Melton Fri, 01/29/2010 - 09:30

Jon

I wanted to give you a quick status update of the progress we have made at the client site today.

One at a time, and while using a console connection on each box I was removing a static route from in additon to SSH from the inside network, I was able to remove the static.  At each device once the static was removed, EIGRP would install the 0 route, and the message about it being "inaccessible" would dissapear.  Once again I appreciate your testing it in your lab, as this gave me a high confidence level while moving in that direction here.  Here are the outputs of the respective devices starting at the Border Router.

For testing I was going to disconnect the Ethernet connection to the ISP.  I think you had tested this before (or did you shut down the interface?) and replied that the result was the the Static route was removed.  Once that kink is worked out, I think we are golden here.

I am wondering if I need to use IP SLA to monitor the ISP's gateway.  We had discussed this at some point in the past, and I had configured it to some extent.  Here is the output from the IP SLA configuration on the Border router.  the address being monitored is the ISP GW.

bhigw2#sho run | beg ip sla


ip sla monitor 1
type echo protocol ipIcmpEcho 209.145.88.29
frequency 30
ip sla monitor schedule 1 life forever start-time now

bhigw2#         sho ip sla monitor collection
Entry number: 1
Start Time Index: 11:05:01.955 Eastern Fri Jan 29 2010
Number of successful operations: 120
Number of operations over threshold: 0
Number of failed operations due to a Disconnect: 0
Number of failed operations due to a Timeout: 0
Number of failed operations due to a Busy: 0
Number of failed operations due to a No Connection: 0
Number of failed operations due to an Internal Error: 0
Number of failed operations due to a Sequence Error: 0
Number of failed operations due to a Verify Error: 0
RTT Values:
RTTAvg: 6       RTTMin: 1       RTTMax: 231
NumOfRTT: 120   RTTSum: 722     RTTSum2: 101810

Start Time Index: 12:05:01.955 Eastern Fri Jan 29 2010
Number of successful operations: 44
Number of operations over threshold: 0
Number of failed operations due to a Disconnect: 0
Number of failed operations due to a Timeout: 0
Number of failed operations due to a Busy: 0
Number of failed operations due to a No Connection: 0
Number of failed operations due to an Internal Error: 0
Number of failed operations due to a Sequence Error: 0
Number of failed operations due to a Verify Error: 0
RTT Values:
RTTAvg: 5       RTTMin: 1       RTTMax: 219
NumOfRTT: 45    RTTSum: 266     RTTSum2: 48020


I am still not sure of how to tie this in with the Static route or if I even need to.  Thoughts?

Thx John

Kevin

Jon Marshall Fri, 01/29/2010 - 09:58

k-melton wrote:

Jon

I wanted to give you a quick status update of the progress we have made at the client site today.

One at a time, and while using a console connection on each box I was removing a static route from in additon to SSH from the inside network, I was able to remove the static.  At each device once the static was removed, EIGRP would install the 0 route, and the message about it being "inaccessible" would dissapear.  Once again I appreciate your testing it in your lab, as this gave me a high confidence level while moving in that direction here.  Here are the outputs of the respective devices starting at the Border Router.

For testing I was going to disconnect the Ethernet connection to the ISP.  I think you had tested this before (or did you shut down the interface?) and replied that the result was the the Static route was removed.  Once that kink is worked out, I think we are golden here.

I am wondering if I need to use IP SLA to monitor the ISP's gateway.  We had discussed this at some point in the past, and I had configured it to some extent.  Here is the output from the IP SLA configuration on the Border router.  the address being monitored is the ISP GW.

bhigw2#sho run | beg ip sla


ip sla monitor 1
type echo protocol ipIcmpEcho 209.145.88.29
frequency 30
ip sla monitor schedule 1 life forever start-time now

bhigw2#         sho ip sla monitor collection
Entry number: 1
Start Time Index: 11:05:01.955 Eastern Fri Jan 29 2010
Number of successful operations: 120
Number of operations over threshold: 0
Number of failed operations due to a Disconnect: 0
Number of failed operations due to a Timeout: 0
Number of failed operations due to a Busy: 0
Number of failed operations due to a No Connection: 0
Number of failed operations due to an Internal Error: 0
Number of failed operations due to a Sequence Error: 0
Number of failed operations due to a Verify Error: 0
RTT Values:
RTTAvg: 6       RTTMin: 1       RTTMax: 231
NumOfRTT: 120   RTTSum: 722     RTTSum2: 101810

Start Time Index: 12:05:01.955 Eastern Fri Jan 29 2010
Number of successful operations: 44
Number of operations over threshold: 0
Number of failed operations due to a Disconnect: 0
Number of failed operations due to a Timeout: 0
Number of failed operations due to a Busy: 0
Number of failed operations due to a No Connection: 0
Number of failed operations due to an Internal Error: 0
Number of failed operations due to a Sequence Error: 0
Number of failed operations due to a Verify Error: 0
RTT Values:
RTTAvg: 5       RTTMin: 1       RTTMax: 219
NumOfRTT: 45    RTTSum: 266     RTTSum2: 48020


I am still not sure of how to tie this in with the Static route or if I even need to.  Thoughts?

Thx John

Kevin

Kevin

Really glad to see you making progress on this.

As for tracking the ISP next-hop, what type of connectivity are you using to connect to the ISP ? If it was serial for example you wouldn't need to track it but if ethernet you will do.

You can tie in IP SLA with object-tracking which allows you to remove a route from the routing table and insert another one. What we don't really need to do is insert a new one, we just want to remove the default-route if the ISP end goes down. We may need to insert a dummy route though just because that's the way it works - more testing for me i think.

There are a number of approaches to this -

1) if serial connectivity no IP SLA - we are fine

2) if ethernet then we could use IP SLA with object-tracking. If we have to insert another route when we remove the default route we can simply use a dummy route. An additional fail safe would be to use a route-map when we redistribute the statics into EIGRP on the border router. We only allow the default route to be redistributed so whatever dummy route we added would not be redistributed to your ASA.

So couple of questions need answering

1) serial or ethernet

2) are you redistributing only the default route on the border router into EIGRP or are there others

3) Do you use a routing protocol between the border router and the ISP router. I'm guessing no but just wanted to confirm. This is yet another approach we could use ie. peer with the ISP using BGP for example and accept just a default-route off them. You then don't need to have a static route configured on the border router because you are getting it off the ISP. You simply redistribute BGP into EIGRP - that would be why you only want the default route off the ISP and not the full internet routing table.

If the ISP link goes down then they will no longer be sending you a default route which means it will no longer be in the routing table and hence won't be sent to the ASA.

As you can see there are a number of ways of doing it. BGP might be overkill with your ISP for this type of connection and the IP SLA might be a better approach.

Happy to test it for you but first if you could answer questions as we may not need to.

Jon

sachinraja Fri, 01/29/2010 - 10:07

Jon.. u da man... such nice explanations.. +5 for the last post, for sure ....

Jon Marshall Fri, 01/29/2010 - 10:49

sachinraja wrote:

Jon.. u da man... such nice explanations.. +5 for the last post, for sure ....

Raj

Thanks very much, sometimes i reread what i have written and wonder just how easy it is to understand

Jon

Kevin Melton Fri, 01/29/2010 - 10:16

Jon

Wanted to respond quickly that we are Metro Ethernet attached - no serial.

Let me read the rest of your post and I will get back to you.

Kevin

Kevin Melton Fri, 01/29/2010 - 10:19

More answers for you Jon

2) are you redistributing only the default route on the border router into EIGRP or are there others

Only the default route

3) Do you use a routing protocol between the border router and the ISP router. I'm guessing no but just wanted to confirm. This is yet another approach we could use ie. peer with the ISP using BGP for example and accept just a default-route off them. You then don't need to have a static route configured on the border router because you are getting it off the ISP. You simply redistribute BGP into EIGRP - that would be why you only want the default route off the ISP and not the full internet routing table.

No routing exchange between my client and the ISP

thx Jon

Jon Marshall Fri, 01/29/2010 - 10:22

k-melton wrote:

More answers for you Jon

2) are you redistributing only the default route on the border router into EIGRP or are there others

Only the default route

3) Do you use a routing protocol between the border router and the ISP router. I'm guessing no but just wanted to confirm. This is yet another approach we could use ie. peer with the ISP using BGP for example and accept just a default-route off them. You then don't need to have a static route configured on the border router because you are getting it off the ISP. You simply redistribute BGP into EIGRP - that would be why you only want the default route off the ISP and not the full internet routing table.

No routing exchange between my client and the ISP

thx Jon

Kevin

Apologies, you did tell me it was MetroEthernet before, i just forgot.

Right then it looks like the IP SLA setup. I can test this over the weekend and then  provide a working config. Is that okay with you ?

Jon

Kevin Melton Fri, 01/29/2010 - 12:44

That is all fine with me Jon.  I am supposed to put this into production on

next Wednesday evening if I can get all the pieces figured out.  Please dont work on this over the weekend

unless it is something you want to do.  I would rather you be enjoying your weekend.  All your effort is

apprciated on a grand scale.

I will read about the object tracking at the link which you have sent.

We are due for a snowstorm here tonight and tomorrow so I may be able to test on this some.

Talk to you soon

Kevin

Kevin Melton Fri, 01/29/2010 - 10:27

One more thing

In response to:

2) if ethernet then we could use IP SLA with object-tracking. If we have to insert another route when we remove the default route we can simply use a dummy route. An additional fail safe would be to use a route-map when we redistribute the statics into EIGRP on the border router. We only allow the default route to be redistributed so whatever dummy route we added would not be redistributed to your ASA.

I think I have object tracking configured,,, did you see this on a post from earlier this morning?  I am pinging the ISP GW from the Border router using IP SLA  (perhaps object tracking is different, I will research). 

Also I had created a route map on the Border router as you had recommended this earlier.  It is only allowing the default route and denying all others..

see below:

route-map static permit 10
match ip address 20


bhigw2#sho access-list 20
Standard IP access list 20
    10 permit 0.0.0.0 (3 matches)
    20 deny   any (42 matches)
bhigw2#

Hope this helps

Kevin

Correct Answer
Jon Marshall Fri, 01/29/2010 - 10:53

k-melton wrote:

One more thing

In response to:

2) if ethernet then we could use IP SLA with object-tracking. If we have to insert another route when we remove the default route we can simply use a dummy route. An additional fail safe would be to use a route-map when we redistribute the statics into EIGRP on the border router. We only allow the default route to be redistributed so whatever dummy route we added would not be redistributed to your ASA.

I think I have object tracking configured,,, did you see this on a post from earlier this morning?  I am pinging the ISP GW from the Border router using IP SLA  (perhaps object tracking is different, I will research). 

Also I had created a route map on the Border router as you had recommended this earlier.  It is only allowing the default route and denying all others..

see below:

route-map static permit 10
match ip address 20


bhigw2#sho access-list 20
Standard IP access list 20
    10 permit 0.0.0.0 (3 matches)
    20 deny   any (42 matches)
bhigw2#

Hope this helps

Kevin

Kevin

You have configured the IP SLA but but you need to tie that into the static route and i'm not aware you have done that altho you may have. Have a look at this link which explains it all -

Object tracking

The route-map does help thanks. It means if we have to insert a dummy route there is no possibility of it getting past the border router.

Jon

Kevin Melton Fri, 01/29/2010 - 13:15

hey there

I have read thru the link you have sent.  Here is the latest configuration I have on the Border Router based upon what the link indicates is necessary:

ip sla monitor 1
type echo protocol ipIcmpEcho 209.145.88.29
frequency 30
ip sla monitor schedule 1 life forever start-time now

bhigw2#sho run | begin track
track 1 interface GigabitEthernet0/1 ip routing

bhigw2#sho run | begin ip route 0.0.0.0
ip route 0.0.0.0 0.0.0.0 209.145.88.29 track 1
ip route 0.0.0.0 0.0.0.0 209.145.88.29

I think I would need to get rid of that second (legacy) static route for 0.  Also I wanted to ask you about the secondary interface that the Link you sent for

Reliable Static Routing Backup Using Object Tracking. 

Since I dont actually have a Secondary interface in this situation as the guide call for, I am starting to think this is where you may have been referring to a dummy route.  Is that correct?

Thanks Jon.  We are close I can feel it.

Kevin

Kevin Melton Fri, 01/29/2010 - 14:08

Jon

I read the article entitled "Reliable Static Routing Backup Using Object Tracking" that you had sent the link for.  Here is the config I have so far based on what it said to do:

ip sla monitor 1

type echo protocol ipIcmpEcho 209.145.88.29

frequency 30

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

ip local policy route-map ipsla

access-list 150 permit icmp host 209.145.88.30 host 209.145.88.29

access-list 150 deny   icmp any any

route-map ipsla permit 150

match ip address 150

set interface GigabitEthernet0/1

ip route 0.0.0.0 0.0.0.0 209.XXX.88.XX track 123

ip route 0.0.0.0 0.0.0.0  123.456.789.123 254

Here is the output from the sho ip route track table command:

bhigw2#sho ip route track-tab
ip route 0.0.0.0 0.0.0.0 209.xxx.88.xx track 123 state is [up]
bhigw2#

I am hoping this may be all we need.  If you can look this over and tell me what you think.

Have a splendid weekend!

Kevin

Correct Answer
Jon Marshall Sun, 01/31/2010 - 13:07

k-melton wrote:

Jon

I read the article entitled "Reliable Static Routing Backup Using Object Tracking" that you had sent the link for.  Here is the config I have so far based on what it said to do:

ip sla monitor 1

type echo protocol ipIcmpEcho 209.145.88.29

frequency 30

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

ip local policy route-map ipsla

access-list 150 permit icmp host 209.145.88.30 host 209.145.88.29

access-list 150 deny   icmp any any

route-map ipsla permit 150

match ip address 150

set interface GigabitEthernet0/1

ip route 0.0.0.0 0.0.0.0 209.XXX.88.XX track 123

ip route 0.0.0.0 0.0.0.0  123.456.789.123 254

Here is the output from the sho ip route track table command:

bhigw2#sho ip route track-tab
ip route 0.0.0.0 0.0.0.0 209.xxx.88.xx track 123 state is [up]
bhigw2#

I am hoping this may be all we need.  If you can look this over and tell me what you think.

Have a splendid weekend!

Kevin

Kevin

Had a spare half hour Sunday evening so did a quick lab. Apologies for this but reliable static routing with object tracking is actually overkill for what we need. All you actually need to do is track the route so full config -

ip sla monitor 1

type echo protocol ipIcmpEcho 209.145.88.29

frequency 30

track 123 rtr 1 reachability

ip route 0.0.0.0 0.0.0.0 209.145.88.29 track 123

and that's all you need to add. I tested this by shutting down the ethernet interface on the upstream router ie. the 209.145.88.29 router and once the IP SLA failed on bhigw2 the static route was removed. Once removed it was no longer being redistributed into EIGRP and so was not passed back down the line to the 4500. The 4500 then used it's floating static route pointing to the other gateway. Note, i think i have already mentioned this but make your floating static AD 200 or above.

Once i brought the interface back up and the IP SLA succeeded the route was reinstalled on bhigw2 and then redistributed all the way back to the 4500.

So i think we are there. Let me know if you have any other queries.

Jon

Kevin Melton Tue, 02/02/2010 - 08:05

Jon

I appreciate your taking your time to verify this configuration and resulting operation.  Tomorrow night is when I get to test this on the production network.

I will remove the unnecessary aspects of my config to match what you have here.  I will follow up once complete early Thursday morning.

Great work!

Kevin

Kevin Melton Sat, 02/06/2010 - 05:24

Jon

Testing went fine and all worked as planned.

If one of the devices on the Edge fails (Border router, firewalls, or the bhiedge switch) will EIGRP also uninstall the default route?

Thanks again for the time you have put into this.

Kevin

Jon Marshall Sat, 02/06/2010 - 09:50

k-melton wrote:

Jon

Testing went fine and all worked as planned.

If one of the devices on the Edge fails (Border router, firewalls, or the bhiedge switch) will EIGRP also uninstall the default route?

Thanks again for the time you have put into this.

Kevin

Kevin

I was wondering how it went. Really glad to hear it worked as expected.

If any of the devices in the "chain" from the border router to the 4500 fails then yes the default-route will not get back to the 4500 and so the 4500 will use the backup link. That's the beauty of redistributing the static route from your edge router, all the other devices simply pass it on via EIGRP. And if any of these devices fail then they cannot then pass on the default route.

No problem with the time, enjoyed helping out and also learned a few things about EIGRP as well.

Jon

Actions

This Discussion