Hi All, While I find IOS XR to be very powerful and flexible, especially with the RPL, I have found a few things that appear to be missing, which are completely possible under the classic IOS... For example, performing OSPF route filtering based on the tag present in the SPF update.  While XR permits SETTING a tag in the ospf_area_out and ospf_redistribution attachpoints, it doesn't support MATCHING the tag on ospf_area_in or distribute_list_in. There is a similar problem when matching a tag and advertising the route in BGP, using the tag to set a specific community.. In general, it appears that most attach points allow for SETTING the tag attribute, but there appear to be none (except sfp-prefix-priority) that allow MATCHING a tag that has been set elsewhere on the network.  This sounds like an omission or an oversight to me. Take this concrete example: Imagine a prefix 10.1.1.1 injected into the network from several different locations ("anycast" of sorts).  Each point of presence tags the route with a specific tag.  The injection is done through redistribution, and is injected with a metric type-1 external and initial metric of 4 (allowing for increase in metric across each hop through the network)  Now, In one PoP you want to FILTER out the routes origined at a specific PoP, but not the same prefix from a different PoP. -- classic IOS -- ! router ospf 1   distribute-list route-map DENY_ANYCAST in ! route-map DENY_ANYCAST deny 10   match tag 100 ! route-map DENY_ANYCAST permit 20 ! The above works perfectly under classic IOS. Under IOS XR, one would have thought that this could be accomplished this way: router ospf 1 distribute-list route-policy DENY_ANYCAST in ! route-policy DENY_ANYCAST if tag is 40 then    drop else    pass endif end-policy However, this cannot be applied because the tag attribute is not valid to match in the distribute-list attach point. Another possibility would have been router ospf 1   area 0     route-policy DENY_ANYCAST in ! (with the same policy as above) but again, "tag" attribut is not valid to match in the ospf_area_in attach point. I can find no work-around to this problem.  Filtering on prefix itself is not an option since it needs to be ACCEPTED from certain origins but not others. Any logical reason why the ability to match on tag when doing route manipulation and filtering was omitted in IOS XR when it's been available for a very long time under classic IOS ??? Thanks Leland ... View more

Hi All, I have come across a possible bug with ACL processing on the 6500 with the VS-S720-10G-3CXL (in VSS mode) running 12.2(33)SXI2a. In this example access list: ip access-list extended VLAN42_OUT   permit tcp any any established   permit udp 10.0.0.0 0.0.0.255 any eq tftp   permit tcp 10.0.0.0 0.0.0.255 any eq 2049   permit tcp 10.0.0.0 0.0.0.255 any eq sunrpc   permit udp 10.0.0.0 0.0.0.255 any gt 1023   deny ip any any log-input ! Traffic from 10.0.0.1 to a host on the vlan42 (where the ACL is attached)      TCP return traffic is fine.      tcp port 2049 is fine          rpc is fine      UDP > 1023 is fine but UDP to port 69 is blocked despite the explicit permit. tcpdump on the sending host shows the ICMP admin-denied from the switch for packets sent to destination UDP 69. If I change that line of permit to permit udp 10.0.0.0 0.0.0.255 any   (without specifying ports), then UDP 69 (and anything else) works fine. If I set permit udp 10.0.0.0 0.0.0.255 any eq tftp log-input , then nothing is seen in the log for the ACL. Nothing is seen in either case for the logs for this specific traffic in the logs (associated with the deny ip any any log-input). If I remove the permit ... tftp line entirely, then I see the blocked packets denied in the log. Basically it appears that the cisco is DENYING the traffic UDP to port 69, even though it's explictly permitted (and near the top of the ACL), but it is not denying the other similar rules (such as UDP > 1023). Smells like a bug to me. (yes, I am aware that tftp uses separate pseudo-random ports for the data transfer, but that's beside the issue at this point...) Anyone else seen this behaviour ? Thanks, Leland ... View more