BMP misconfiguration leads to unicast prefix entries having incorrect key

[brmcdoug]

best practice is for RRs to BMP monitor their clients rather than the other way around. if an RR client runs BMP on their RR session the collector/topology processor will write an incorrect entry into the graphDB:

"key": "10.0.12.0_24_10.0.0.10",
"peer_ip": "10.0.0.10",
"nexthop": "10.0.0.12",
"bmp_ip": "10.0.0.8" <-- this RR client was configured to collect/pass BMP data from the RR to Jalapeno

}

Key should be: 10.0.12.0_24_10.0.0.12

Topology processor should probably check BMP message peer_ip == nexthop, and if != then use nexthop in key construction

[sbezverk]

Hi Bruce, I see your point, but there is an issue. When BGP Withdraw a prefix it does not send next-hop in the update, as a result with the model you propose it will be impossible reliably identify a prefix entry to delete. I think we need to think a bit more how to correctly deal with this situation. Thank you Serguei From: Bruce McDougall ***@***.***> Reply-To: cisco-open/jalapeno ***@***.***> Date: Monday, August 1, 2022 at 8:16 PM To: cisco-open/jalapeno ***@***.***> Cc: Subscribed ***@***.***> Subject: [cisco-open/jalapeno] BMP misconfiguration leads to unicast prefix entries having incorrect key (Issue #51) best practice is for RRs to BMP monitor their clients rather than the other way around. if an RR client runs BMP on their RR session the collector/topology processor will write an incorrect entry into the graphDB: "key": "10.0.12.0_24_10.0.0.10", "peer_ip": "10.0.0.10", "nexthop": "10.0.0.12", "bmp_ip": "10.0.0.8" <-- this RR client was configured to collect/pass BMP data from the RR to Jalapeno } Topology processor should probably check BMP message peer_ip == nexthop, and if != then use nexthop in key construction — Reply to this email directly, view it on GitHub<#51>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD4E7UGMVL4C5JHAINGDSA3VXAH6FANCNFSM55IN4C4Q>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>