[c-nsp] IOS XR BFD

[Pavel Lunin]

2009/7/5 Nick 'tarantul' Novikov <tarantul at gmail.com>

>
> Ok. Example of physical topology:
> http://pastebin.ca/1484472
> All physical links protected by IS-IS.
> RR* routers can't keep full BGP table and for this reason ASBR*
> announce 0/0 route only. If I configure BGP session between ASBR* and
> use for it lo0 interfaces I will have a loop. Do not you think?


You know, I might also be missing something, but I don't see much difference
from iBGP's point of view. Traffic anyway goes through RRs on the way from
the core to outside as well as between ASBRs and RRs know only defaults.
What advantage does iBGP on subifs give here? I'd understand if you had a
link or an LSP between ASBRs and wanted to exclude a possibility of passing
plain IP traffic from one ASBR to another through RRs, but in this case...
am I missing something? How loops are avoided now?

Moreover what is a reason of separation of RRs and ASBRs in such a manner?
Normally you want RRs to carry traffic as little as possible but do well
their control plane jobs with no excuse. Why RRs can't fit full BGP? I bet
because their FIBs are constrained (sort of sup32 TCAM capability problem),
but not due to thier RIBs. Ideally RRs should stand out of forwarding
topology and not carry transit traffic at all.


> otherwise static routes will save you (does
> > IOS XR support BFD for them? :)
>
> So fsck... No. IOS XR can't. If I configure (X.X.X.X - subif BGP
> neighbor, not lo0 address)
> router static
>  address-family ipv4 unicast
>  X.X.X.X/32 Null0
>  !
> !
> BGP session don't drop!
> In old school IOS a similar construction works great.


Hm...  seems strange anyway. Does this route come active? Isn't it possible
that something like an ARP entry for x.x.x.x treated as a connected route
with lower admin distance? I know some non-cisco devices which can do so. Or
something else might beat this static route. What about 'sh ip route
x.x.x.x' (or whatever this command looks like in IOS XR) and 'ping x.x.x.x'
after adding this route? And if the route to null0 comes active and ping
fails, but iBGP stills alive, can you do some sort of investigation to know
how traffic reaches the peer, which path it goes along?

--
Regards,
Pavel