[c-nsp] Nexus 7000 MSDP peering policy woes

[Christopher.Marget at usc-bt.com]

Huh.  The copy of this note in my outbox is formatted nicely, but the one forwarded back to me by the list is a mess.
I'm not sure what happened to the newlines.  Thank you, Outlook.  Trying again, sorry for the noise.


I'm trying to implement PBR-filtering of MSDP messages from a Nexus 7000 running 5.0(2a), and I'm starting to think that the route-map is being interpreted wrong.

The relevant parts of the configuration are:

feature msdp
feature pbr
ip msdp originator-id loopback0
ip msdp peer W.X.Y.Z connect-source loopback0
ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY in
ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY out

ip access-list PERMIT-IP-ANY-ANY
 permit ip any any

route-map MSDP-INTRA-BUILDING-POLICY deny 10
  match ip address PERMIT-IP-ANY-ANY
route-map MSDP-INTRA-BUILDING-POLICY deny 20
  match ip address MSDP-FORBIDDEN-MC-GROUPS
route-map MSDP-INTRA-BUILDING-POLICY permit 30
  match ip address RFC-2365-GLOBAL-GROUPS
route-map MSDP-INTER-ENTERPRISE-POLICY deny 40

Next, I enable 'debug ip msdp' and 'debug ip msdp policy', and switch on a multicast source.  The debug output indicates that only the first line (deny 10) of the route-map is being evaluated:

2010 Aug 12 00:02:40.689445 msdp: librpm [7070] ========== RPM Evaluation starting for policy MSDP-INTRA-BUILDING-POLICY ==========
2010 Aug 12 00:02:40.689482 msdp: librpm [7070] **** Evaluating (rmap MSDP-INTRA-BUILDING-POLICY - seq 10 - cmd RPM_MATCH_IP_ADDR_ACL) ****
2010 Aug 12 00:02:40.689512 msdp: librpm [7070] **** Evaluation result (seq 10 - cmd RPM_MATCH_IP_ADDR_ACL):RPM_MATCH_IGNORE ****
2010 Aug 12 00:02:40.689562 msdp: librpm [7070] EVAL context->flag 0x0000001b
2010 Aug 12 00:02:40.689668 msdp: librpm [7070] Policy eval. returning action handle 0x00000000
2010 Aug 12 00:02:40.689698 msdp: librpm [7070] ========== RPM Evaluation result RPM_MATCH_REJECT ==========
2010 Aug 12 00:02:40.689743 msdp: [7070] (default-base) Entire outgoing SA to peer W.X.Y.Z filtered

So far, so good.  'deny 10' matches everything, so the next line of the route-map didn't get evaluated, and the announcement for this new multicast source is filtered.

Now I'll insert an earlier 'deny' line into the route-map, this time with an ACL that matches nothing:

ip access-list DENY-IP-ANY-ANY
 deny ip any any

route-map MSDP-INTRA-BUILDING-POLICY deny 5
  match ip address DENY-IP-ANY-ANY

Clear all of the mroutes, and fire the source back up.  Debug says:

2010 Aug 12 00:40:53.064084 msdp: librpm [7070] ========== RPM Evaluation starting for policy MSDP-INTRA-BUILDING-POLICY ==========
2010 Aug 12 00:40:53.064121 msdp: librpm [7070] **** Evaluating (rmap MSDP-INTRA-BUILDING-POLICY - seq 5 - cmd RPM_MATCH_IP_ADDR_ACL) ****
2010 Aug 12 00:40:53.064152 msdp: librpm [7070] **** Evaluation result (seq 5 - cmd RPM_MATCH_IP_ADDR_ACL):RPM_MATCH_IGNORE ****
2010 Aug 12 00:40:53.064181 msdp: librpm [7070] EVAL context->flag 0x0000005b
2010 Aug 12 00:40:53.064211 msdp: librpm [7070] Policy eval. returning action handle 0x00000000
2010 Aug 12 00:40:53.064238 msdp: librpm [7070] ========== RPM Evaluation result RPM_MATCH_REJECT ==========
2010 Aug 12 00:40:53.064282 msdp: [7070] (default-base) Entire outgoing SA to peer 10.255.255.228 filtered

Now, the earlier line (deny 5) in the route-map is being matched even though its ACL matches nothing (DENY-IP-ANY-ANY).

The route-map isn't getting evaluated beyond the first deny line in either case.

Could this possibly be correct behavior?