Looks like I may not have this feature as these are 12410XR chassis. Here is what I have in our lab environment.
RP/0/9/CPU0:lab-router(config)#ipv4 access-list ABF RP/0/9/CPU0:lab-router(config-ipv4-acl)#permit ipv4 10.10.10.0/24 172.16.0.0/19 RP/0/9/CPU0:lab-router(config-ipv4-acl)#permit ipv4 10.10.10.0/24 any ? dscp Match packets with given DSCP value fragments Check non-initial fragments log Log matches against this entry log-input Log matches against this entry, including input interface packet-length Check packet length precedence Match packets with given precedence <cr> RP/0/9/CPU0:lab-router(config-ipv4-acl)#permit ipv4 10.10.10.0/24 any -Lee On Thu, Sep 11, 2014 at 12:37 AM, Oliver Boehmer (oboehmer) < [email protected]> wrote: > > > > >Since we have no default routes and all backbone links are full BGP minus > >default route, I am going to assume that the second permit statement > >won't work here. Would this just get specified as any since the first > >entry would be matched for local netblocks and > > sorry, 0.0.0.0/0 should be "any".. so the first line matches traffic to > your networks (and it just passes through normally and will be forwarded > according to your RIB/FIB), and the 2nd matches traffic from this customer > block to anything else, which then will be ABF'ed to your upstream. > > >it would not go further in the ACL? > > it actually would, so I missed a "permit ipv4 any any" catch-all at the > end of the ACL to ensure traffic from other sources is forwarded > normally.. it is a regular ACL, the ABF directives are just inserted into > it. > Need more coffee.. > > >These special case customers all are fed from a single 6509 to the border > >router that contains their one carrier of choice, but that border router > >contains several backbone links and each border router also having links > > to each other. I suspect that for simplifying this, we can match against > >traffic on the link coming from that 6509 to the border router. > > exactly, that sounds straight-forward, just apply this inbound and you're > set.. > > oli > > > > > > > > > >Thanks for the pointers. > > > > > >-Lee > > > > > >On Wed, Sep 10, 2014 at 11:09 PM, Oliver Boehmer (oboehmer) > ><[email protected]> wrote: > > > > > >> > >>I am looking to setup some policy based routing on an IOS-XR router. From > >>what I understand, XR does not have PBR, but ABF. When looking at how ABF > >>works, I don¹t see how to set a next hop route (only next hop per TCP > >>port). > > > >well, you can direct any traffic matching an ACE (be it layer 3 or 4) to a > >chosen next-hop. > > > >>My question then would be, how does one accomplish this on XR? What > >>I need to do is allow a particular IP block to only have access to one of > >>our backbone carriers and not the others. We have their /24 only > >>announced > >>out the one carrier, but for outbound traffic, I want to make sure their > >>traffic remains on that carrier but also have access to our local routes > >>(all our local customers and local networks). Is this something that can > >>be > >>done with ABF > > > >Yes, it can be done, but possibly a bit more difficult: > > > >ipv4 access-list ABF > > permit CUST/24 <your-own-netblocks> > > permit CUST/24 0.0.0.0/0 <http://0.0.0.0/0> next-hop > ><your-upstream-provider> > > > >not sure how your topology looks and where you would need to apply this > >forwarding rule, but the next-hop can be directly connected or resolve via > >some form of tunnel (including LDP/LSP). > > > > oli > > > > > > > > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
