[c-nsp] route-map behavior with policy routing

[Paul Stewart]

Relating to this same post...

I have been trying to get PBR running with a multi-homed BGP setup
here....

route-map inbound-trio permit 5
 match as-path 100
 set ip next-hop 67.29.145.1
!
route-map inbound-trio permit 10
 match as-path 21
 set local-preference 150
!
route-map inbound-trio permit 20
 set local-preference 100

AS-PATH 100 is setup to match one particular AS like this:

ip as-path access-list 100 permit ^23252$

AS-PATH 21 statement works great to match "close to us" AS's and give
them a higher local-pref .. But I want to explicitly prefer our path to
AS23252 using AS-PATH 100 via our BGP peer (67.29.145.1 is far side of
the point to point to the BGP peer we want to prefer).

Why does this not work and is there a better way to do this?

Thanks,

Paul Stewart
Network Administrator
Nexicom Inc.
http://www.nexicom.net/ 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Thomas Renzy
Sent: Thursday, August 24, 2006 1:19 PM
To: Shaikh, Nasir; cisco-nsp at barriejonescook.com;
cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] route-map behavior with policy routing

Actually, with PBR, doesn't use the regular routing table if there isn't
a match? This isn't a route map for route filtering, so I don't think
the permit at the end is needed. 

Thomas


Thomas Renzy
IT Global Network Services
Symantec Corporation
Office: +650-527-4734
Mobile: +650-248-1099
Fax: +650-527-2034

"Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former." - Albert Einstein

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Shaikh, Nasir
Sent: Thursday, August 24, 2006 5:42 AM
To: cisco-nsp at barriejonescook.com; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] route-map behavior with policy routing

Barrie,
Route-maps also have an implicit deny at the end.
Add another permit statement in the route-map to avoid being cut off
from the network.

route-map PBR permit 10
 match ip address 90
 set ip next-hop Y.Y.Y.Y Z.Z.Z.Z
route-map PBR permit 20

regards

Nash




-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Barrie Jones Cook
Sent: woensdag 23 augustus 2006 22:24
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] route-map behavior with policy routing


Hi all,

I'm helping out on a network that has Cisco 3750s as core and
distribution routers/switches.  For various reasons, policy routing is
used to direct traffic to different interfaces on the core routers.  I'm
not too familiar with policy routing, so this may turn out to be a silly
question, but I can't find an answer no matter how many google queries I
come up with, so please bear with me.  

Anyway, it's a pretty standard architecture of:

     core1---core2
       | \   / |
       |  \ /  |
       |   X   |
       |  / \  |
     dist1   dist2
     / | \     | \
    a1 a2 a3   a4 a5   

On the dist routers, "ip policy route-map PBR" is applied to the access
switch, or a[n], interfaces like
this:

interface Vlan16
 description a2
 ip address X.X.X.X 255.255.255.252
 ip policy route-map PBR

route-map PBR permit 10
 match ip address 90
 set ip next-hop Y.Y.Y.Y Z.Z.Z.Z

where Y.Y.Y.Y is the other end of the link to core1, and Z.Z.Z.Z is the
other end of the link to core2.

On core1 and core2, it's very similar; the same route-map is applied to
the incoming vlan interfaces for dist1, dist2 and the opposite core.  On
core1, the set ip next hop addresses are first the far end IP of the
desired outbound connection, and then a backup in case the primary is
down, and finally the IP of the other end of the link to core2.  On
core2, the next hop is set to the ip of the other end of the core1 link,
and then the ip of a backup interface on core2.

Unfortunately, I have no console access to this network (yet) and when I
make a change, I log in from a server off of a2.  I lose my connection
when I try to change access-list 90 on core2 as follows:

core2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
core2(config)#no access-list 90
core2(config)#access-list 90 denyRead from remote host
core2: Connection timed out

I still have my connection to core1, but core1 cannot ssh to core2, and
customers start complaining about network problems at this point.  Then,
I get someone who has a connection to a server somewhere else inside the
network to log onto core2, he pastes the new access-list 90 in for me
(which includes that first deny and then several permits), and voila,
we're back in business.

Now, if a route-map permit statement matches an access-list and there is
no access-list (which I had always assumed meant that the implicit deny
any came into effect), shouldn't the route-map just move on and not
match anything, meaning that the next-hop is unchanged on *all* traffic,
and it's all routed normally?  I'm sure it would be interesting to see
exactly what interfaces are unreachable during this issue, but
unfortunately with customers complaining, there is little time to do so.

Thanks,
Barrie


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/