Applying route-map to BDI interface

[Amos Kafwembe]

Hi All,

I am moving configurations from a Cisco 7200 to an ASR 920. I have some sub interfaces on the 7200 and have noticed the 920 doesn't take the sub-interfaces so i had to use service instances/ BDI as below. question is, I have route maps on my sub interfaces on the 7200.... how and where do i apply the route-maps on the 920 BDI? could it be my IOS version?

On 7200 rtr

interface GigabitEthernet0/1
 no ip address
 ip route-cache flow
 load-interval 30
 duplex full
 speed auto
 media-type rj45
 negotiation auto
 fair-queue
!
interface GigabitEthernet0/1.50
 encapsulation dot1Q 50
 ip address 21.19.3.1 255.255.255.240
 ip policy route-map CACHE

On ASR920

interface GigabitEthernet0/0/1
  no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation dot1q 50
  rewrite ingress tag pop 1 symmetric
  bridge-domain 50
 !

interface BDI50
 ip address 21.19.3.1 255.255.255.240

sh ver ==> on this version i get

hostname(config-if)#ip policy ?
% Unrecognized command

"bootflash:/asr920-universalk9_npe.03.15.00.S.155-2.S-std.b

sh ver

on this one hostname(config-if)#ip policy ?
  route-map  Policy route map

"bootflash:/asr920-universalk9_npe.03.16.00.S.155-3.S-ext.bin"

[Richard Burts]

From the output that you show it certainly looks like 3.15 does not support ip policy and 3.16 does support ip policy. So you may need to be sure that your router is running the newer version of code.

HTH

Rick

[Amos Kafwembe]

Hi Richard,

Is it in any way possible that an IOS version would stop PBR from working.. see my config below, i cant seem to get the PBR to work! I am capturing traffic as it leaves my network and have set the next hop as my cache server using an IP SLA which I am tracking...

Gate#show route-map CACHE_1
route-map CACHE_1, permit, sequence 10
  Match clauses:
    ip address (access-lists): CACHE_1
  Set clauses:
    ip next-hop verify-availability 10.139.101.2 10 track 101  [up]
    ip next-hop 19.3.12.10
  Policy routing matches: 0 packets, 0 bytes


Gate#show access-lists CACHE_1
Extended IP access list CACHE_1
    10 permit tcp 21.19.3.0 0.0.7.255 any eq www
    20 permit tcp 21.19.3.0 0.0.7.255 any gt 1024
    30 permit tcp 4.21.6.0 0.0.31.255 any eq www
    40 permit tcp 4.21.6.0 0.0.31.255 any gt 1024

interface GigabitEthernet0/0/3
 ip address 21.19.3.8 255.255.255.254
 ip policy route-map CACHE_1

Gate#show track
Track 101
  IP SLA 101 reachability
  Reachability is Up
    12 changes, last change 00:23:55
  Latest operation return code: OK
  Latest RTT (millisecs) 4
  Tracked by:
    Route Map 0

Gate#show ver
Cisco IOS XE Software, Version 03.16.00.S - Extended Support Release
Cisco IOS Software, ASR920 Software (PPC_LINUX_IOSD-UNIVERSALK9_NPE-M), Version 15.5(3)S, RELEASE SOFTWARE (fc6)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Sun 26-Jul-15 10:01 by mcpre


Cisco IOS-XE software, Copyright (c) 2005-2015 by cisco Systems, Inc.
All rights reserved.  Certain components of Cisco IOS-XE software are
licensed under the GNU General Public License ("GPL") Version 2.0.  The
software code licensed under GPL Version 2.0 is free software that comes
with ABSOLUTELY NO WARRANTY.  You can redistribute and/or modify such
GPL code under the terms of GPL Version 2.0.  For more details, see the
documentation or "License Notice" file accompanying the IOS-XE software,
or the applicable URL provided on the flyer accompanying the IOS-XE
software.


ROM: IOS-XE ROMMON

Gate uptime is 23 weeks, 6 days, 16 hours, 39 minutes
Uptime for this control processor is 23 weeks, 6 days, 16 hours, 41 minutes
System returned to ROM by reload
System restarted at 00:01:00 CAT Tue Nov 8 2016
System image file is "bootflash:asr920-universalk9_npe.03.16.00.S.155-3.S-ext.bin"
Last reload reason: PowerOn



This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

License Level: advancedmetroipaccess
License Type: Permanent
Next reload license Level: advancedmetroipaccess

cisco ASR-920-24TZ-M (Freescale P2020) processor (revision 1.2 GHz) with 910182K/6147K bytes of memory.
Processor board ID CAT1905V19L
24 Gigabit Ethernet interfaces
4 Ten Gigabit Ethernet interfaces
32768K bytes of non-volatile configuration memory.
3670016K bytes of physical memory.
1328927K bytes of SD flash at bootflash:.

Configuration register is 0x2102

[Richard Burts]

Some things seem to have changed from your original post. In that post it certainly looked like there are versions of code that prevent PBR from working. But in this post you are running a version of code that looks like it does support PBR. And in the original post you seem to need to use interface BDI for the IP address (and would have needed to put ip policy on BDI) but in this post you are doing that configuration on the Gig interface.

I do not believe that you are dealing with an issue of version of code but are dealing with inconsistencies in your configuration. In the access list you are specifying two IP addresses. I am puzzled at this since your interface has only a single IP address

    10 permit tcp 21.19.3.0 0.0.7.255 any eq www
    20 permit tcp 21.19.3.0 0.0.7.255 any gt 1024
    30 permit tcp 4.21.6.0 0.0.31.255 any eq www
    40 permit tcp 4.21.6.0 0.0.31.255 any gt 1024

and if you look carefully at how the interface is configured there is a mismatch between the address and mask of the interface and the address and mask of the access list

 ip address 21.19.3.8 255.255.255.254

I believe that if you resolve the difference so that the access list matches what is configured on the interface that PBR will start to work.

HTH

Rick

[Amos Kafwembe]

Hi Rick,

I had upgraded the ASR to the new IOS and was able to configure the policy on the interface. I highly doubt the IP address on the interface has to match the subnets in the ACL.

the set up is like this, I have a cache server which is to cache all traffic as it enters the router from the internet and also to cache traffic as it goes to the internet;

ACL capturing traffic destined to the internet;

     Extended IP access list CACHE_1

    10 permit tcp 21.19.3.0 0.0.7.255 any eq www
    20 permit tcp 21.19.3.0 0.0.7.255 any gt 1024
    30 permit tcp 4.21.6.0 0.0.31.255 any eq www
    40 permit tcp 4.21.6.0 0.0.31.255 any gt 1024

ACL capturing traffic from the internet;

     Extended IP access list CACHE_2 

    10 permit tcp any eq www 21.19.3.0 0.0.7.255
    20 permit tcp any gt 1024 21.19.3.0 0.0.7.255
    30 permit tcp any eq www 4.21.6.0 0.0.31.255
    40 permit tcp any gt 1024 4.21.6.0 0.0.31.255

the ACL capturing traffic destined to the internet is applied via route-map , it is supposed to send traffic to the Cache before which it goes out to the internet

interface GigabitEthernet0/0/3
 ip address 21.19.3.8 255.255.255.254
 ip policy route-map CACHE_1

the ACL capturing traffic as it enters from the internet and sends it to the cache before being forwarded to the LAN

interface BDI3963
 ip address 19.3.12.10 255.255.255.252
 ip policy route-map CACHE_2

Route-maps;

route-map CACHE_2, permit, sequence 10
  Match clauses:
    ip address (access-lists): CACHE_2
  Set clauses:
    ip next-hop verify-availability 10.139.102.2 10 track 102  [up]
    ip next-hop 21.19.3.8
  Policy routing matches: 0 packets, 0 bytes
route-map CACHE_1, permit, sequence 10
  Match clauses:
    ip address (access-lists): CACHE_1
  Set clauses:
    ip next-hop verify-availability 10.139.101.2 10 track 101  [up]
    ip next-hop 19.3.12.10
  Policy routing matches: 0 packets, 0 bytes

[Richard Burts]

You can highly doubt that the interface address must match the subnets in the acl and in this case you would be wrong. Consider the acl entries

    10 permit tcp 21.19.3.0 0.0.7.255 any eq www
    20 permit tcp 21.19.3.0 0.0.7.255 any gt 1024

These entries will match IP addresses 21.19.3.0 through 21.19.3.7

Then consider the interface configuration

 ip address 21.19.3.8 255.255.255.254

The addresses in this subnet are 21.19.3.8 and 21.19.3.9. So clearly traffic to or from these addresses will not match what is in the access list.

HTH

Rick

[Amos Kafwembe]

Hi Rick,

thanks for your time.

There is a large network below this interface, the two blocks are actually /21 and /19 respectively. according to what you are saying, it means my IP address on the interface should then be a /19 or /21 in order to encompass the whole subnet? suppose i had a 172.16.0.0 network below this interface which was reachable via an IGP, how then would i capture traffic from that subnet? am not sure about this..attached is the set up;

[Richard Burts]

Thanks for the picture which does help to clarify the environment. I still am not clear about the BW Mngr. What kind of device is this? Does it treat the link to your ASR as one subnet and the links to the address blocks as a separate subnet (which implies that it has some routing logic capability)? Or does it treat all the links as a common subnet (which implies that the routing logic would be in the ASR)? Without understanding how that device is working I can not answer the question about how the interface on the ASR should be configured.

HTH

Rick

[Amos Kafwembe]

Hi Rick,

basically it is a bandwidth manager. It is responsible for assigning bandwidth to IP addresses within the ranges, it is also responsible for permitting or denying IP addresses access to the internet. it is a transparent device although the link between it and the ASR is running OSPF, thereby "telling" the ASR about the networks below it.

[Richard Burts]

We still do not have a good understanding of the connected device. If the bandwidth manager is really a transparent device then it would be logical that you would need both address blocks with correct masks configured on the ASR interface. But if you are running OSPF and the device is advertising both subnets, then it sounds like you could treat it as a routed interface and not need the full blocks configured on the ASR interface.

Perhaps one way to investigate this is to check a couple of devices connected in those address blocks and see what is their default gateway. Is their default gateway on the bandwidth manager, on the ASR, somewhere else?

Another way to check would be to turn on debug for arp and look to see who is sending arp requests. If there are arp requests from devices in those address blocks then the bandwidth manager would seem to be operating as a transparent device and you would need the address blocks configured on the ASR interface.

HTH

Rick

[Amos Kafwembe]

Hi,

i've checked and have come to the conclusion that the BM is taking part in the routing. when i check the ARP I can only see the BM's IP address coming in and a few other unrelated IP's. how ever, I am also unable to capture traffic coming in from the internet! which is the same thing happening on the BM facing interface.

interface BDI3963
 ip address 19.3.12.10 255.255.255.252
 ip policy route-map CACHE_2

ACL capturing traffic from the internet;

     Extended IP access list CACHE_2

    10 permit tcp any eq www 21.19.3.0 0.0.7.255
    20 permit tcp any gt 1024 21.19.3.0 0.0.7.255
    30 permit tcp any eq www 4.21.6.0 0.0.31.255
    40 permit tcp any gt 1024 4.21.6.0 0.0.31.255


route-map CACHE_2, permit, sequence 10
  Match clauses:
    ip address (access-lists): CACHE_2
  Set clauses:
    ip next-hop verify-availability 10.139.102.2 10 track 102  [up]
    ip next-hop 21.19.3.8
  Policy routing matches: 0 packets, 0 bytes

[Richard Burts]

I have a few questions to try to clarify some aspects of this:

- am I correct in understanding that interface BDI3963 is the interface where traffic from the Internet is received?

- is there any address translation being done on this router for Internet traffic?

HTH

Rick

[Amos Kafwembe]

Hi Rick,

you are correct! and no, there is no NAT here.

[Richard Burts]

In looking through the route map logic there is something that I do not understand. You have this in the route map

 ip next-hop 21.19.3.8

But in previous posts that IP is assigned as an interface IP on the router.  Have IP addresses changed around or is this still the interface IP?

Is the problem perhaps that you are setting the next hop ip as the router itself and not as the actual next hop device?

HTH

Rick

[Amos Kafwembe]

Hi Rick,

the config is as below, the next hop is 10.139.102.2 which is being tracked by an SLA. if the SLA is "up" then the next hop is valid, if it is down, then the next hop is 21.19.3.8

   ip next-hop verify-availability 10.139.102.2 10 track 102  [up]
    ip next-hop 21.19.3.8