Subject: recursion flap

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 11 Jul 2002 19:47:28 -0400

if the peer is reachable via OPSF and EBGP then the route tab will have the
EBGP route (since the admin dist of EBGP is 20; OSPF is 110) so it will be
flagged as a recursion error and removed.  Then, when a 1 minute timer
triggers, the BGP route will be removed and the OPSF route will be installed
due to the recursion.  Then, when the 1 minute timer triggers again, the
OPSF route will be removed and the BGP route will be installed due to the
lower admin dist. ...Etc... (2 minute period)  Not sure how they resolve
this, how we should, and/or how "real" this problem is

???:
timer in rfc?
A "persistent flap"?
Notification/inform?
Juniper?

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 12 Jul 2002 09:52:35 -0400

Here is another twist on the same issue:

This seems to be an outgrowth of <another vendor> practice of assigning
<another vendor> point-to-point interface IP addresses with a /32 mask and
then redistributing direct/connected.  I believe the /32 for yourself is
incorrect, but:
"A third option is to <another vendor> e host addresses on both ends of a
point-to-
   point link.  This option provides the same address space savings as
   <another vendor> ing a 31-bit subnet mask, but may only be <another
vendor> ed in links <another vendor> ing PPP
   encapsulation [RFC1332].  The <another vendor> e of host addresses allows
for the
   assignment of IP addresses belonging to different networks at each
   side of the link, causing link and network management not to be
   straight forward."
    --RFC3021, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links"
(PROPOSED STANDARD)

Using BGP, <another vendor> told the <a major vendor> that to get to
50.1.1.2/32 it should use the next hop of 50.1.1.2.  A host route with a
nexthop equal to itself is not mentioned in the bgp RFC nor in the draft.
At least I did not find it [yet], but I did not really look that hard
because it is not that important.  Intuitively, it should not be sent and if
received it should be ignored.  In this regard it IS a <a major vendor> bug
(but that may not help--<another vendor> should not advertise such a route,
and/or <another vendor> e the "work-around" I propose below).

RFC:
    ...blah blah blah...
    "Mutually recursive routes (routes
    resolving each other or themselves), also fail the resolvability
    check"
    ...blah blah blah...

--draft-ietf-idr-bgp4-17.txt

I suspect that, if you watch it, you will see the bgp 50.1.1.2/32 route get
removed due to the recursiveness.  Then it will get re-installed based on
the 1.1.0/24 directly connected route.  This will repeat based on the
["nettable walker" or "scan" ???] <a major vendor> timer.  The interval
(half the period) is 60 seconds and is not configurable (again, not in any
RFCs). 

Also:
    ...blah blah blah...
    "implementations must
    take care that before any packets are forwarded along a BGP route,
    its associated NEXT_HOP address is resolved to the immediate
    (directly connected) next-hop address and this address"
    ...blah blah blah...

--draft-ietf-idr-bgp4-17.txt

And at one angle, the 50.1.1.2 address cannot be directly connected to
anybody but <another vendor>  since it has a /32 mask and <another vendor>
are its 1 and only 1 host.  So <another vendor> should not send it since it
will never be resolved.  There is some mention of the 32  I suppose it would
be ok to send the bgp 50.1.1.2/32 route to peers that are not on the same
point-to-point link, since in that case the next hop and prefix would not be
recursive; but then <another vendor> might break
the: "care must be taken to ensure a consistent view of routing within the
AS." (RFC1771) rule.  My vote is against allowing the bgp 50.1.1.2/32 route
to be sent to peers that are not on the same point-to-point link (or any
other link).  Also, I think maybe bgp should try a next longest bit match to
resolve the next hop.

The Work around is to add:
ip route 50.1.1.2 255.255.255.255 atm 4/0.1 on <major vendor>

Thoughts?

-----Original Message-----
From: Natale, Jonathan 
Sent: Thursday, July 11, 2002 7:47 PM
To: Bgp ([email-masked]); [email-masked]; [email-masked]
Subject: recursion flap

this, how <another vendor> should, and/or how "real" this problem is

???:
timer in rfc?
A "persistent flap"?
Notification/inform?
Juniper?