[j-nsp] BGP default action constraints with advertise-inactive?

[Wojciech Janiszewski]

Hi Jason,

"advertise-inactive" makes router to advertise BGP route even if it is not
active. One example is when you have a static and BGP route for the same
prefix. By default, static route is preferred and BGP is marked as
inactive. As such BGP route would not be advertised. By configuring
"advertise-inactive" you can advertise such inactive BGP route.

HTH,
Wojciech


sob., 23 lut 2019, 16:58: Jason Lixfeld via juniper-nsp <
juniper-nsp at puck.nether.net> napisał(a):

> Hello!
>
> I’m confused about some observations while testing BGP announcements of
> inactive routes.  I’m hoping someone can offer some clue.
>
> I have this sample route:
>
> jlixfeld at mx# run show route table rifoo.inet.0 protocol static
> 44.44.44.0/21 detail
>
> rifoo.inet.0: 27 destinations, 29 routes (27 active, 0 holddown, 0 hidden)
> 44.44.44.0/21 (1 entry, 1 announced)
>         *Static Preference: 5
>                 Next hop type: Discard, Next hop index: 0
>                 Address: 0x71101cc
>                 Next-hop reference count: 42
>                 State: <Active NotInstall Int Ext>
>                 Age: 12:24:23
>                 Validation State: unverified
>                 Task: RT
>                 Announcement bits (1): 2-BGP_RT_Background
>                 AS path: I
>                 Communities: 4444:1001
>
> [edit]
> jlixfeld at mx#
>
> My understanding is:
>
> 1. With advertise-inactive configured, this route should be advertised to
> an EBGP neighbor that has no export policy configured.
> [
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/advertise-inactive-edit-protocols-bgp.html
> ]
>
> 2. The BGP default action of 'accept' should not require an accept action
> in a policy statement.
> [
> https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-routing-policies-actions-defaults.html
> ]
>
> However, neither of these two cases seem to be true, so my understanding
> is obviously wrong and I haven’t been able to find any documentation that
> points to the difference in behaviour.
>
> Based on the configuration below, here’s what works and what doesn’t:
>
> To 4.4.4.4: 44.44.44.0/21 is not announced.
> To 5.5.5.5: 44.44.44.0/21 is not announced unless tfoo includes 'then
> accept' and ANNOUNCE:ANCHOR then {} includes 'accept'
> To 6.6.6.6: 44.44.44.0/21 is not announced unless sfoo ANNOUNCE:ANCHOR
> then {} includes 'accept'
>
> routing-instances {
>     rifoo {
>         routing-options {
>             rib rifoo.inet6.0 {
>                 static {
>                     route 2607:4444::/32 {
>                         discard;
>                         no-install;
>                         community 4444:1001;
>                     }
>                 }
>             }
>             static {
>                 route 44.44.44.0/21 {
>                     discard;
>                     no-install;
>                     community 4444:1001;
>                 }
>         protocols {
>             bgp {
>                 group gfoo {
>                     type external;
>                     advertise-inactive;
>                     neighbor 4.4.4.4 {
>                         peer-as 5555;
>                     }
>                     neighbor 5.5.5.5 {
>                         export pfoo
>                         peer-as 5555;
>                     }
>                     neighbor 6.6.6.6 {
>                         export sfoo
>                         peer-as 5555;
>                     }
>                 }
>             }
>         }
>     }
> }
> policy-statement pfoo {
>     term tfoo {
>         from policy sfoo
>         # then accept;
>     }
> }
> policy-statement sfoo {
>     term ANNOUNCE:ANCHOR {
>         from {
>             protocol static;
>             community TYPE:ANCHOR;
>         }
>         then {
>             community delete TYPE:ANCHOR;
>             # accept;
>         }
>     }
> }
> community TYPE:ANCHOR members 4444:1001;
>
> Can anyone see what I might be missing here?
>
> Thanks!
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>