01-01-2017 11:37 AM - edited 03-05-2019 07:46 AM
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
Solved! Go to Solution.
01-01-2017 01:34 PM
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:
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:
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
01-01-2017 12:05 PM
Hi,
Welcome to Cisco Support Community! :)
May I ask you two questions to clarify our understanding of your problem?
Thanks!
Best regards,
Peter
01-01-2017 12:17 PM
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
01-01-2017 12:30 PM
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.
01-01-2017 12:43 PM
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
01-01-2017 01:34 PM
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:
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:
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
01-01-2017 02:46 PM
hi Peter,
Thank you so much....
it worked......
appreciated your assistant.
kD
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide