cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
881
Views
0
Helpful
12
Replies

BGP Prefix-list OUT config not getting Merged

Touseef Gulgundi
Cisco Employee
Cisco Employee

BGP Prefix-list OUT config not getting Merged


Additional BGP Prefix list configuration present on the router which is not a part of NSO Service/XML template is getting deleted when new configuration is getting pushed to the device.


DRY RUN output

-----------------------------------------------------------------


router bgp 109

neighbor 4.4.4.4 description "Tossi-test test email mail only"

neighbor 2011::44 description "Tossi-test test email mail only"

address-family ipv4 unicast

  no neighbor 1.1.1.1 prefix-list DENY_SPECIFIC out

  no neighbor 2.2.2.2 prefix-list DENY_SPECIFIC out

  no neighbor 3.3.3.3 prefix-list DENY_SPECIFIC out

  exit-address-family

 

  XML Template

----------------------------------------------------------------

 

             <address-family>

                  <ipv4 when="{$IPv4Peer !='None'}" >

                          <af>unicast</af>

                          <neighbor >

                            <id>{$IPv4Peer}</id>

                            <activate/>

                            <maximum-prefix>

                              <max-prefix-no>{$MaxPrefix}</max-prefix-no>

                              <threshold>{$Warning}</threshold>

                              <warning-only/>

                            </maximum-prefix>

                            <prefix-list>

                              <direction>in</direction>

                              <prefix-list-name>bogons</prefix-list-name>

                            </prefix-list>

                            <remove-private-as/>

                            <filter-list >

                              <direction>in</direction>

                              <as-path-list>{$ASPathACL}</as-path-list>

                            </filter-list>

                            <filter-list>

                              <direction>out</direction>

                              <as-path-list>99</as-path-list>

                            </filter-list>

                          </neighbor>

12 Replies 12

Touseef Gulgundi
Cisco Employee
Cisco Employee

This issue occurs when I modify the configuration on NSO Serivce, BGP Prefix-list OUT has been configured  manually on the device and is getting deleted from the device instead of the configuration getting merged. Prefix-list OUT config is not a part of NSO XML tempalte



Output of commit dry run Output

-----------------------------------------------------------------


router bgp 109

neighbor 4.4.4.4 description "Tossi-test test email mail only"

neighbor 2011::44 description "Tossi-test test email mail only"

address-family ipv4 unicast

  no neighbor 1.1.1.1 prefix-list DENY_SPECIFIC out

  no neighbor 2.2.2.2 prefix-list DENY_SPECIFIC out

  no neighbor 3.3.3.3 prefix-list DENY_SPECIFIC out

  exit-address-family

what version of NSO, what NED/NED version.. what device type...

is this a service model? load-merge? your lack of details make any discussion difficult

thanks

This is a service model NSO  version  - 4.6, NED cisco-ios - 5.8.3 ,Device type- ASR1006 .

Hi

Ok... if i understand correctly... (given CAPITALIZATIONS you used... )...

there is a "prefix-list" called "OUT"... applied in the "out" direction... to a specific neighbor... (maybe all of them)

and then you are creating "another prefix-list" called DENY_OUT and you expect to _also apply this_ to the SAME neighbor in the SAME "direction" "out" .... and you're wondering why the "merge" --- meaning BOTH (two) prefix-list applied to the SAME neighbor... in the SAME direction isn't happening?

*** if i got this correct... (two prefix-list for the same neighbor in the same direction)... this is not how IOS works... this has nothing to do with NSO... you'll simply swap prefix-lists... you can only have one prefix-list "in" and one "out" direction

you can test this directly on a device...

(sorry i flipped the names when i did it by hand)

Add one prefix-list the first time:

-----------------------------------------------------------------

lisp6-44a(config)#router bgp 123

lisp6-44a(config-router)#neighbor 1.1.1.1 remote-as 321

lisp6-44a(config-router)#neighbor 1.1.1.1 prefix-list DENY_SPECIFIC out   <----** HERE

lisp6-44a(config-router)#^Z

lisp6-44a#show  running-config | beg bgp

router bgp 123

bgp log-neighbor-changes

neighbor 1.1.1.1 remote-as 321

neighbor 1.1.1.1 prefix-list DENY_SPECIFIC out  <---*** results

!

(skip...)



ok... right now, one prefix-list in the "out" direction is configured...

Now, let's use a different prefix-list name... called "OUT"


lisp6-44a#conf

Configuring from terminal, memory, or network [terminal]?

Enter configuration commands, one per line.  End with CNTL/Z.

lisp6-44a(config)#router bgp 123                               

lisp6-44a(config-router)#neighbor 1.1.1.1 prefix-list OUT out  <-----** HERE

lisp6-44a(config-router)#^Z

lisp6-44a#show  running-config | beg bgp

router bgp 123

bgp log-neighbor-changes

neighbor 1.1.1.1 remote-as 321

neighbor 1.1.1.1 prefix-list OUT out <---*** results

!

(skip...)



it's a "swap" - you can only have one "in" and one "out" per peer... but direction...  it's not a "merge"

if you want the "prefix-list" to contain multiple "ideas" (martians/bogons/whatever) you have to merge the prefixes in the list and use this one list...

If i misunderstood your goal/intention, please let me know.

We do not have any prefix-list configured in OUT direction as part of service template. Below is the config which gets pushed via NSO service.

--------------------------------------------------------------

neighbor 1.1.1.1 remote-as 1111

neighbor 1.1.1.1 description tgulgund-test1 mailme callme

neighbor 1.1.1.1 shutdown

neighbor 1.1.1.1 update-source GigabitEthernet1/2/0

neighbor 1.1.1.1 activate

neighbor 1.1.1.1 remove-private-as

neighbor 1.1.1.1 prefix-list xxxx in

neighbor 1.1.1.1 maximum-prefix 1000 50 warning-only

neighbor 1.1.1.1 filter-list 111 in

neighbor 1.1.1.1 filter-list 99 out

--------------------------------------------------------------


neighbor 1.1.1.1 prefix-list DENY_SPECIFIC_OUT out is configured manually on the device only for few peers as this is an exception not part of standard template.


Next when there any new changes/addition is done via NSO service  neighbor 1.1.1.1 prefix-list DENY_SPECIFIC_OUT config is getting deleted.

yfherzog
Cisco Employee
Cisco Employee

Do you happen to have tags="replace" somewhere on your template?

Any other explicit tags in use?

Nope .. No Explicit tags ... anywhere in the template.

            <address-family>

                  <ipv4 when="{$IPv4Peer !='None'}">

                          <af>unicast</af>

                          <neighbor>

                            <id>{$IPv4Peer}</id>

                            <activate/>

                            <maximum-prefix>

                              <max-prefix-no>{$MaxPrefix}</max-prefix-no>

                              <threshold>{$Warning}</threshold>

                              <warning-only/>

                            </maximum-prefix>

                            <prefix-list>

                              <direction>in</direction>

                              <prefix-list-name>bogons</prefix-list-name>

                            </prefix-list>

                            <remove-private-as/>

                            <filter-list>

                              <direction>in</direction>

                              <as-path-list>{$ASPathACL}</as-path-list>

                            </filter-list>

                            <filter-list>

                              <direction>out</direction>

                              <as-path-list>99</as-path-list>

                            </filter-list>

                          </neighbor>

Is that the whole template? Any other templates/services being invoked somehow?

You mentioned some pieces of configurations that NSO pushes which aren't on the template snippet you provided (update source, shutdown, etc.).

Any chance the issue is there?

Below is the whole template.

<router xmlns="urn:ios" >

            <bgp>

            <as-no>$ASN</as-no>

            <neighbor when="{$IPv4Peer !='None'}">

            <id>{$IPv4Peer}</id>

            <remote-as>{$AS_Number}</remote-as>

            <password when="{string-length($PeerPassword)>0}" >

                  <enctype when="{$EncryptionType = 5}">5</enctype>

                  <enctype when="{$EncryptionType = 7}">7</enctype>

                  <text>{$PeerPassword}</text>

            </password>

                <update-source when="{$InterfaceName='GigabitEthernet'}">

                   <GigabitEthernet>{$InterfaceNumber}</GigabitEthernet>

                </update-source>

                <update-source when="{$InterfaceName='TenGigabitEthernet'}">

                  <TenGigabitEthernet>{$InterfaceNumber}</TenGigabitEthernet>

                </update-source>

        <description>{$Name} {$Email} {$Contact}</description>

        <shutdown when="{$Actions='Shut'}"/>

            </neighbor>

        <neighbor when="{$IPv6Peer !='None'}">

            <id>{$IPv6Peer}</id>

            <remote-as>{$AS_Number}</remote-as>

                <update-source when="{$InterfaceName='GigabitEthernet'}">

                   <GigabitEthernet>{$InterfaceNumber}</GigabitEthernet>

                </update-source>

                <update-source when="{$InterfaceName='TenGigabitEthernet'}">

                  <TenGigabitEthernet>{$InterfaceNumber}</TenGigabitEthernet>

                </update-source>

        <description>{$Name} {$Email} {$Contact}</description>

      <shutdown when="{$Actions='Shut'}"/>

            </neighbor>

            <address-family>

                  <ipv4 when="{$IPv4Peer !='None'}">

                          <af>unicast</af>

                          <neighbor>

                            <id>{$IPv4Peer}</id>

                            <activate/>

                            <maximum-prefix>

                              <max-prefix-no>{$MaxPrefix}</max-prefix-no>

                              <threshold>{$Warning}</threshold>

                              <warning-only/>

                            </maximum-prefix>

                            <prefix-list>

                              <direction>in</direction>

                              <prefix-list-name>bogons</prefix-list-name>

                            </prefix-list>

                            <remove-private-as/>

                            <filter-list>

                              <direction>in</direction>

                              <as-path-list>{$ASPathACL}</as-path-list>

                            </filter-list>

                            <filter-list>

                              <direction>out</direction>

                              <as-path-list>99</as-path-list>

                            </filter-list>

                          </neighbor>

                  </ipv4>

                  <ipv6 when="{$IPv6Peer !='None'}">

                          <af>unicast</af>

                          <neighbor >

                            <id>{$IPv6Peer}</id>

                            <activate/>

                            <maximum-prefix>

                              <max-prefix-no>{$MaxPrefix}</max-prefix-no>

                              <threshold>{$Warning}</threshold>

                              <warning-only/>

                            </maximum-prefix>

                            <prefix-list>

                              <direction>in</direction>

                              <prefix-list-name>ipv6-bogons</prefix-list-name>

                            </prefix-list>

                            <remove-private-as/>

                            <filter-list>

                              <direction>in</direction>

                              <as-path-list>{$ASPathACL}</as-path-list>

                            </filter-list>

                            <filter-list>

                              <direction>out</direction>

                              <as-path-list>99</as-path-list>

                            </filter-list>

                          </neighbor>

                  </ipv6>

            </address-family>

            </bgp>

          </router>

Still something is a bit odd to me...

For example, on the output you provided, you have max-prefix configurations on the router/bgp/neighbor, while on the template you have the max-prefix under router/bgp/address-family/ipv4/neighbor.

I would suspect couple of things:

- The service mapping logic have changed, and it used to push the policy OUT and not anymore.

- Other templates are being applied or not being applied and should've been applied (e.g. where applied when the service instance was created but not applied anymore).

In general, if you changed the mapping logic for a service which has existing instances, the data fastmap had already stored is not going to be affected by the change, so removals are going to happen according to the previous logic (undo data was stored according to previous logic).

If that is the case, I'd suggest removing existing instances altogether and starting the test from the beginning.

If there are additional templates/services being applied, make sure they are applied as expected. If they were applied when the instance was created and not being applied on service update, then whatever they configured will be removed.

Apologies for the confusion. Below is the output from NSO service dry run out format when I try to add new peer.

router bgp 109

neighbor 4.4.4.4 remote-as 4444

neighbor 4.4.4.4 password None

neighbor 4.4.4.4 update-source GigabitEthernet1/2/0

neighbor 4.4.4.4 description "tgulgund-test2 email contact"

neighbor 2001::4 remote-as 4444

neighbor 2001::4 update-source GigabitEthernet1/2/0

neighbor 2001::4 description "tgulgund-test2 email contact"

address-family ipv4 unicast

  neighbor 4.4.4.4 activate

  neighbor 4.4.4.4 maximum-prefix 1000 50 warning-only

  neighbor 4.4.4.4 prefix-list bogons in

  neighbor 4.4.4.4 remove-private-as

  neighbor 4.4.4.4 filter-list 144 in

  neighbor 4.4.4.4 filter-list 99 out

  no neighbor 1.1.1.1 prefix-list DENY_SPECIFIC out

  no neighbor 2.2.2.2 prefix-list DENY_SPECIFIC out

  no neighbor 3.3.3.3 prefix-list DENY_SPECIFIC out

  exit-address-family

!

address-family ipv6 unicast

  neighbor 2001::4 activate

  neighbor 2001::4 maximum-prefix 1000 50 warning-only

  neighbor 2001::4 prefix-list ipv6-bogons in

  neighbor 2001::4 remove-private-as

  neighbor 2001::4 filter-list 144 in

  neighbor 2001::4 filter-list 99 out

  exit-address-family

Hmmm....

There are few ways in which data can be removed from the neighbors list.

1. You somehow replace the list instead of merging it - tags=replace somewhere would have caused that, but you mentioned this is not the case. (Did you used to have tags=nocreate somewhere before? Do you have it in a level above <router>?)

2. You are actively deleting those nodes in the service mapping logic (from template or from code). - This template you shared doesn't seem to do that, but you might have sections of code or other templates which does that somehow.

3. Those configurations has a backpointer to this service instance from previous runs (mapping logic have changed over time and fastmap now removes them) - you should be able to tell if that is the case with: 'show run devices device /path/to/configs/being/deleted/ | display service-meta-data'.

I understand from what you explain that the issue is happening on service modification.

Is it reproducible? If you remove the service instance, and recreate it and try to edit it again, is it still happening?

Those are my suspects.

If you suspect a bug, you should open a case with TAC.