RE: Advertising local host routes in BGP?

I have tried to check what was originally stated by the Jeffrey and I have
to agree with Carlos that the problem is with the conditionally publishing
the /32 prefixes on HSRP state. If the L1 on the Gige links is OK and then
we broke the L2 between HSRP routers (for example change the Vlan on one of
those routers connection to the switch) both of them will advertise the /32
prefixes in case of using the static routes to the interface.

I did manage to find a way to stop publishing those /32 prefixes by the
router is it has no connection to those prefixes - maybe this will help.
To do that, you have to have assign an ip address from the 1.1.1.0/24 which
will be tracked - it has to answer to icmp - let assume it will be 1.1.1.4.
I use such ip address on the switch Vlan interface, which is used to connect
those /32 prefixes.

Then the configuration will look like below:

#R1
interface g0/0
ip address 1.1.1.2 255.255.255.0

router bgp 1
 neighbor 1.1.1.3 remote-as 1
 neighbor 1.1.1.3 update-source FastEthernet0/0

#R2
interface g0/0
ip address 1.1.1.3 255.255.255.0

router bgp 1
 neighbor 1.1.1.2 remote-as 1
 neighbor 1.1.1.2 update-source FastEthernet0/0

#R1 and R2
interface g0/0
standby ip 1.1.1.1
!
router bgp 1
 network 1.1.1.4 mask 255.255.255.255
 network 1.1.1.5 mask 255.255.255.255
 network 1.1.1.6 mask 255.255.255.255
 network 1.1.1.7 mask 255.255.255.255
 network 1.1.1.8 mask 255.255.255.255
!
ip route 1.1.1.4 255.255.255.255 GigabitEthernet0/0 track 2
ip route 1.1.1.5 255.255.255.255 GigabitEthernet0/0 track 2
ip route 1.1.1.6 255.255.255.255 GigabitEthernet0/0 track 2
ip route 1.1.1.7 255.255.255.255 GigabitEthernet0/0 track 2
ip route 1.1.1.8 255.255.255.255 GigabitEthernet0/0 track 2
!
ip sla 2
 icmp-echo 1.1.1.4
 timeout 500
 threshold 400
 frequency 1
ip sla schedule 2 start-time now
 match ip route-source prefix-list ROUTE_SOURCE
track 2 ip sla 2 reachability

I such configuration if there is any L1/L2 problem with the connection
between R1 or R2 and the rest of the network 1.1.1.0/24 (especially with
connection to dedicated earlier ip 1.1.1.4), the /32 routes will stop to be
advertised by the router as soon as the track object will go down and the
neighborship between R1 and R2 go down. If one the track object or the
neighborship will be up (for example using some access-list icmp filtering
between the tracked ip and the router or the routers BGP neighborship) the
/32 prefixes will be advertised by both routers.

Hope this helps.

-- 
-=[ Grzegorz Cegielski ]=- 
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Carlos G Mendioroz
> Sent: Wednesday, April 21, 2010 11:56 AM
> To: Jeffrey Pazahanick
> Cc: Cisco certification
> Subject: Re: Advertising local host routes in BGP?
> 
> What do you mean by "did'nt work" ? It does get your bgp routes
> advertised :)
> Your original problem statement was that a loop was being created
> because of this, not that you need not to have a static.
> 
> On a reread of your problem, it seems to me that what you really want
> is to publish conditionally on HSRP state. If this is so, it is a
> reencarnation of an ages old problem: HSRP solves the first hop route,
> but it does nothing to let the world know (i.e. the incoming traffic).
> 
> I guess you'll have to resort to EEM scripting to add/remove those
> statics...
> 
> -Carlos
> 
> Jeffrey Pazahanick @ 20/04/2010 22:42 -0300 dixit:
> > I appreciate your help so far.  My problem is as originally stated..
> > Is there a way to advertise host routes in BGP from a connected
> > interface without creating a static route pointing to that interface.
> >
> > int g0/0
> > ip addr 1.1.1.1 255.255.255.0
> >
> > router bgp 1
> > neig 2.2.2.2 remote-as 2
> > network 1.1.1.3 mask 255.255.255.255
> > network 1.1.1.4 mask 255.255.255.255
> > network 1.1.1.5 mask 255.255.255.255
> >
> > I want to advertise 1.1.1.3, .4,  and 5 in BGP without doing
> >
> > ip route 1.1.1.3 255.255.255.255 g0/0
> > ip route 1.1.1.4 255.255.255.255 g0/0
> > ip route 1.1.1.5 255.255.255.255 g0/0
> >
> > My output of the FIB and RIB were based on the suggestion of
> >
> > ip route 1.1.1.3 255.255.255.255 1.1.1.3
> > ip route 1.1.1.4 255.255.255.255 1.1.1.4
> > ip route 1.1.1.5 255.255.255.255 1.1.1.5
> >
> > which didn't work.
> >
> > On Tue, Apr 20, 2010 at 8:24 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> wrote:
> >> You tell me. Again, I don't fully understand what the problem is now.
> >> I guess you have to reproduce the problem in a lab scenario before you
> >> try to find a solution...
> >>
> >> -Carlos
> >>
> >> Jeffrey Pazahanick @ 20/04/2010 19:17 -0300 dixit:
> >>> I don't have the FIB/RIB data from the actual failure; only from
> >>> trying to find a way to advertise a host route in my lab..
> >>> So bgp inject-map is off of the table?
> >>>
> >>> On Tue, Apr 20, 2010 at 10:48 AM, Carlos G Mendioroz
> <tron_at_huapi.ba.ar> wrote:
> >>>> Hmm, I don't know what the problem is. All the info you send now
> seems ok.
> >>>> Can you provide a small configuration set that we can use to
> reproduce the
> >>>> issue ?
> >>>> If this is related to the doc you referred before, your FIB would be
> >>>> inconsistent with your RIB, which is not the case in the provided
> >>>> show ooutputs.
> >>>>
> >>>> -Carlos
> >>>>
> >>>> Jeffrey Pazahanick @ 20/4/2010 11:30 -0300 dixit:
> >>>>> That doesn't seem to work either...
> >>>>>
> >>>>> ip route 1.1.1.5 255.255.255.255 1.1.1.5
> >>>>>
> >>>>>
> >>>>> R1#sh ip cef 1.1.1.5 det
> >>>>> 1.1.1.5/32, version 37, epoch 0
> >>>>> 0 packets, 0 bytes
> >>>>>  via 1.1.1.5, 0 dependencies, recursive
> >>>>>    unresolved
> >>>>>
> >>>>> R1#sh arp
> >>>>> Protocol  Address          Age (min)  Hardware Addr   Type
> Interface
> >>>>> Internet  1.1.1.1                 -   0015.fa64.6d21  ARPA
> >>>>> FastEthernet0/1
> >>>>> Internet  1.1.1.5                16   0015.fa64.7b13  ARPA
> >>>>> FastEthernet0/1
> >>>>> Internet  10.1.12.1               -   0015.fa64.6d20  ARPA
> >>>>> FastEthernet0/0
> >>>>> Internet  10.1.12.2              16   0015.fa64.7518  ARPA
> >>>>> FastEthernet0/0
> >>>>>
> >>>>> R1#sh ip route 1.1.1.5
> >>>>> Routing entry for 1.1.1.5/32
> >>>>>  Known via "static", distance 1, metric 0
> >>>>>  Advertised by bgp 1
> >>>>>  Routing Descriptor Blocks:
> >>>>>  * 1.1.1.5
> >>>>>      Route metric is 0, traffic share count is 1
> >>>>>
> >>>>> ----
> >>>>>
> >>>>> Remove the static.
> >>>>>
> >>>>> R1#conf t
> >>>>> Enter configuration commands, one per line.  End with CNTL/Z.
> >>>>> R1(config)#no ip route 1.1.1.5 255.255.255.255 1.1.1.5
> >>>>> R1(config)#^Z
> >>>>> R1#ping
> >>>>> *Apr 20 14:29:07.057: %SYS-5-CONFIG_I: Configured from console by
> console
> >>>>> R1#ping 1.1.1.5
> >>>>>
> >>>>> Type escape sequence to abort.
> >>>>> Sending 5, 100-byte ICMP Echos to 1.1.1.5, timeout is 2 seconds:
> >>>>> !!!!!
> >>>>> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
> >>>>> R1#sh ip cef 1.1.1.5 det
> >>>>> 1.1.1.0/24, version 32, epoch 0, attached, connected
> >>>>> 0 packets, 0 bytes
> >>>>>  via FastEthernet0/1, 0 dependencies
> >>>>>    valid glean adjacency
> >>>>> R1#sh arp
> >>>>> Protocol  Address          Age (min)  Hardware Addr   Type
> Interface
> >>>>> Internet  1.1.1.1                 -   0015.fa64.6d21  ARPA
> >>>>> FastEthernet0/1
> >>>>> Internet  1.1.1.5                19   0015.fa64.7b13  ARPA
> >>>>> FastEthernet0/1
> >>>>> Internet  10.1.12.1               -   0015.fa64.6d20  ARPA
> >>>>> FastEthernet0/0
> >>>>> Internet  10.1.12.2              19   0015.fa64.7518  ARPA
> >>>>> FastEthernet0/0
> >>>>> R1#sh ip route 1.1.1.5
> >>>>> Routing entry for 1.1.1.0/24
> >>>>>  Known via "connected", distance 0, metric 0 (connected, via
> interface)
> >>>>>  Routing Descriptor Blocks:
> >>>>>  * directly connected, via FastEthernet0/1
> >>>>>      Route metric is 0, traffic share count is 1
> >>>>>
> >>>>>
> >>>>> Any other suggestions?
> >>>>>
> >>>>> On Sat, Apr 17, 2010 at 6:57 AM, Carlos G Mendioroz
> <tron_at_huapi.ba.ar>
> >>>>> wrote:
> >>>>>> Send it to the destination:
> >>>>>>
> >>>>>> ip route 1.1.1.5 255.255.255.255 1.1.1.5
> >>>>>>
> >>>>>> That worked in a couple of versions I tested it. I did no other
> test,
> >>>>>> so I don't know if it fixes your issue, but it may help.
> >>>>>>
> >>>>>> -Carlos
> >>>>>>
> >>>>>>
> >>>>>> Jeffrey Pazahanick @ 17/04/2010 1:33 -0300 dixit:
> >>>>>>> Carlos,
> >>>>>>>
> >>>>>>> How do you have a static /32 pointed to the segment if you are the
> next
> >>>>>>> hop?
> >>>>>>>
> >>>>>>> R1#conf t
> >>>>>>> Enter configuration commands, one per line.  End with CNTL/Z.
> >>>>>>> R1(config)#ip route 1.1.1.5 255.255.255.255 1.1.1.1
> >>>>>>> %Invalid next hop address (it's this router)
> >>>>>>> R1(config)#R1#conf t
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Apr 16, 2010 at 5:10 PM, Carlos G Mendioroz
> <tron_at_huapi.ba.ar>
> >>>>>>> wrote:
> >>>>>>>> Interesting reading (the loop problem).
> >>>>>>>> Caused by a floating static route to a multipoint if.
> >>>>>>>>
> >>>>>>>> You say:
> >>>>>>>>> The link says the solution is to point the statics to the next
> hop;
> >>>>>>>>> which I can't, as they are local.
> >>>>>>>> which triggered me to try it. And it works.
> >>>>>>>>
> >>>>>>>> You can have a static /32 route to a next hop which is in a
> connected
> >>>>>>>> segment. Which solves your need for a given /32 prefix to be
> published
> >>>>>>>> by BGP w/o the burden of proxy ARP poisoning your CEF adjacency
> >>>>>>>> table...
> >>>>>>>>
> >>>>>>>> -Carlos
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Jeffrey Pazahanick @ 16/04/2010 0:37 -0300 dixit:
> >>>>>>>>> I have a situation where I'm trying to advertise only 4 host
> routes
> >>>>>>>>> from a /24 network to my BGP neighbors.
> >>>>>>>>> As an example,
> >>>>>>>>>
> >>>>>>>>> #R1
> >>>>>>>>> interface g0/0
> >>>>>>>>> ip addr 1.1.1.2 255.255.255.0
> >>>>>>>>> standby ip 1.1.1.1
> >>>>>>>>>
> >>>>>>>>> router bgp 1
> >>>>>>>>> network 1.1.1.4 mask 255.255.255.255
> >>>>>>>>> network 1.1.1.5 mask 255.255.255.255
> >>>>>>>>> network 1.1.1.7 mask 255.255.255.255
> >>>>>>>>> network 1.1.1.9 mask 255.255.255.255
> >>>>>>>>>
> >>>>>>>>> With a single router, a static route to the interface worked
> fine..
> >>>>>>>>>
> >>>>>>>>> ip route 1.1.1.4 255.255.255.255 g0/0
> >>>>>>>>> ip route 1.1.1.5 255.255.255.255 g0/0
> >>>>>>>>> ip route 1.1.1.7 255.255.255.255 g0/0
> >>>>>>>>> ip route 1.1.1.9 255.255.255.255 g0/0
> >>>>>>>>>
> >>>>>>>>> When adding a redundant router, things initially work as well..
> >>>>>>>>>
> >>>>>>>>> #R2
> >>>>>>>>> interface g0/0
> >>>>>>>>> ip addr 1.1.1.3 255.255.255.0
> >>>>>>>>> standby ip 1.1.1.1
> >>>>>>>>>
> >>>>>>>>> router bgp 1
> >>>>>>>>> network 1.1.1.4 mask 255.255.255.255
> >>>>>>>>> network 1.1.1.5 mask 255.255.255.255
> >>>>>>>>> network 1.1.1.7 mask 255.255.255.255
> >>>>>>>>> network 1.1.1.9 mask 255.255.255.255
> >>>>>>>>>
> >>>>>>>>> ip route 1.1.1.4 255.255.255.255 g0/0
> >>>>>>>>> ip route 1.1.1.5 255.255.255.255 g0/0
> >>>>>>>>> ip route 1.1.1.7 255.255.255.255 g0/0
> >>>>>>>>> ip route 1.1.1.9 255.255.255.255 g0/0
> >>>>>>>>>
> >>>>>>>>> The issue arises when R1 fails, R2 has a CEF routing loop..
> >>>>>>>>>
> >>>>>>>>> Troubleshooting Cisco Express Forwarding Routing Loops
> >>>>>>>>> Document ID: 26083
> >>>>>>>>>
> >>>>>>>>>
> http://www.cisco.com/en/US/partner/tech/tk827/tk831/technologies_tech_note
> 09186a00800cdf2e.shtml
> >>>>>>>>>
> >>>>>>>>> The link says the solution is to point the statics to the next
> hop;
> >>>>>>>>> which I can't, as they are local.
> >>>>>>>>>
> >>>>>>>>> Is there another way to advertise these host routes?
> >>>>>>>>>
> >>>>>>>>> I've been trying to use inject-maps, but my own routers are the
> route
> >>>>>>>>> source, and it doesn't appear to work.
> >>>>>>>>>
> >>>>>>>>> Ideas?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Blogs and organic groups at http://www.ccie.net
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> _______________________________________________________________________
> >>>>>>>>> Subscription information may be found at:
> >>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> --
> >>>>>>>> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
> >>>>>>>>
> >>>>>> --
> >>>>>> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
> >>>>>>
> >>>> --
> >>>> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
> >>>
> >>> Blogs and organic groups at http://www.ccie.net
> >>>
> >>>
> _______________________________________________________________________
> >>> Subscription information may be found at:
> >>> http://www.groupstudy.com/list/CCIELab.html
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >> --
> >> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
> >>
> 
> --
> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
> 
> 
> Blogs and organic groups at http://www.ccie.net
> 
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net