cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1728
Views
0
Helpful
6
Replies

PBR issue on GNS3

kapilade
Level 1
Level 1

hi,

Anyone has comment, why this PBC is not working ?

interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip policy route-map PM1
duplex auto
speed auto
!
interface Serial1/0
ip address 200.1.1.1 255.255.255.0
serial restart-delay 0
clock rate 2016000
!
interface Serial1/1
ip address 201.1.1.1 255.255.255.0
serial restart-delay 0
clock rate 2016000
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router eigrp 10
network 192.168.1.0
network 200.1.1.0
network 201.1.1.0
no auto-summary
!
no ip http server
no ip http secure-server
!
!
!
!
ip access-list standard PC20
permit 192.168.1.20
!
ip access-list extended PC21
permit tcp host 192.168.1.21 any eq telnet
permit tcp host 192.168.1.21 any eq 448
no cdp log mismatch duplex
!
route-map PM1 permit 10
match ip address PC20
set ip next-hop 201.1.1.2
!
route-map PM1 permit 20
match ip address PC21
set ip next-hop 200.1.1.2
!
route-map PM1 permit 30
set ip next-hop 201.1.1.2
!

thanks.

KD

1 Accepted Solution

Accepted Solutions

Hi,

I do not see anything obviously wrong with your configuration (apart from a typo in the HTTPS port), and as gpauwen noted, route-maps used in PBR are not used to deny trafic, rather to steer it in different directions based on criteria you define.

Your PBR is currently configured as follows:

  1. If the sender is PC20 (192.168.1.20), forward the traffic through 201.1.1.2
  2. If the sender is PC21 and the traffic is destined to TCP ports 23 (telnet) or 448 (wrong, should have been 443 for HTTPS), forward the traffic through 200.1.1.2
  3. Otherwise forward the traffic through 201.1.1.2

Perhaps the problem is in the method you are using to test your PBR. Note that pinging from PC21 is not going to match the ACL where you are matching traffic toward TCP ports 23 and 448 - ICMP is a different type of traffic. Even pinging 200.1.1.2 from PC20 might be successful even if the PBR is working, as I see you're running EIGRP, and so the ISP1 and ISP2 may simply forward the pings to each other, making them succeed.

The easiest way of verifying in GNS3 whether your PBR works as intended is to simply capture the traffic on the interfaces from your router to ISP1 and ISP2, and generate exactly the type of traffic that should be matched by your individual route-map blocks:

  1. To test PM1 block 10, ping 1.1.1.1 from PC20
  2. To test PM2 block 20, try telnetting to 1.1.1.1 from PC21, either to port 23 or to port 448 (note once again that for HTTPS, the port should be 443)
  3. To test PM3 block 30, try pinging 1.1.1.1 from PC21

The captures should show that your router has forwarded the packets appropriately.

Would this make sense? Please feel welcome to ask further!

Best regards,
Peter

View solution in original post

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hi,

Welcome to Cisco Support Community! :)

May I ask you two questions to clarify our understanding of your problem?

  1. What do you mean by "this PBR not working"? Can you clarify this in more detail?
  2. What evidence do you have to prove that this PBR is truly not working as expected?

Thanks!

Best regards,
Peter

hi Peter,

not working mean it is not filtering PC - 20 to access the 200.1.1.2, PC - 21 to access normal traffic to 200.1.1.2.

when I ping PC-20 to 200.1.1.2, I can ping it.it is not rejecting.

when I ping PC-21 to 200.1.1.2, I can ping it.it is not rejecting.

Thanks.

KD

Hello,

your route maps are not denying anything. Route maps are matched in sequence, your first sequence is:

route-map PM1 permit 10
match ip address PC20
set ip next-hop 201.1.1.2

That simply means that all traffic from 192.168.1.20 is allowed and the next hop is 201.1.1.2. Nothing else will be checked further down the route map.

hi,

thanks for your reply.

my objective is PC21 telnet and HTTPS traffic going through ISP1  and other all the traffic from PC-20 and PC 21 going through ISP2.

Thanks.

KD

Hi,

I do not see anything obviously wrong with your configuration (apart from a typo in the HTTPS port), and as gpauwen noted, route-maps used in PBR are not used to deny trafic, rather to steer it in different directions based on criteria you define.

Your PBR is currently configured as follows:

  1. If the sender is PC20 (192.168.1.20), forward the traffic through 201.1.1.2
  2. If the sender is PC21 and the traffic is destined to TCP ports 23 (telnet) or 448 (wrong, should have been 443 for HTTPS), forward the traffic through 200.1.1.2
  3. Otherwise forward the traffic through 201.1.1.2

Perhaps the problem is in the method you are using to test your PBR. Note that pinging from PC21 is not going to match the ACL where you are matching traffic toward TCP ports 23 and 448 - ICMP is a different type of traffic. Even pinging 200.1.1.2 from PC20 might be successful even if the PBR is working, as I see you're running EIGRP, and so the ISP1 and ISP2 may simply forward the pings to each other, making them succeed.

The easiest way of verifying in GNS3 whether your PBR works as intended is to simply capture the traffic on the interfaces from your router to ISP1 and ISP2, and generate exactly the type of traffic that should be matched by your individual route-map blocks:

  1. To test PM1 block 10, ping 1.1.1.1 from PC20
  2. To test PM2 block 20, try telnetting to 1.1.1.1 from PC21, either to port 23 or to port 448 (note once again that for HTTPS, the port should be 443)
  3. To test PM3 block 30, try pinging 1.1.1.1 from PC21

The captures should show that your router has forwarded the packets appropriately.

Would this make sense? Please feel welcome to ask further!

Best regards,
Peter

hi Peter,

Thank you so much....

it worked......

appreciated your assistant.

kD