ā10-21-2020 01:05 PM - edited ā10-21-2020 01:18 PM
Hello guys,
Here we have a small scenario you might be interested to participate in:
Imagine we have 2 MLS with a number of SVI on each.
SW1:
SVI:
VLAN 100: 100.100.100.1/24
VLAN 110: 110.110.110.1/24
VLAN 50 : 50.50.50.1/252
Routing Table:
S 0.0.0.0 0.0.0.0 via Site1-Edge-Router
D 200.200.200.0/24 via VLAN 50
D 220.220.220.0/24 via VLAN 50
C 100.100.100.0
C 110.110.110.0
ACL:
ip access-list 100 permit 100.100.100.0 0.0.0.255 any (internet)
PBR:
route-map test permit 10
match ip address 100
set ip default next-hop 50.50.50.2
SW2:
SVI:
VLAN 200: 200.200.200.1/24
VLAN 220: 220.220.220.1/24
VLAN 50 : 50.50.50.2/252
Routing Table:
S 0.0.0.0 0.0.0.0 via EdgeRouter
D 100.100.100.0/24 via VLAN 50
D 110.110.110.0/24 via VLAN 50
C 200.200.200.0
C 220.220.220.0
ACL:
ip access-list 100 permit 100.100.100.0 0.0.0.255 any (internet)
PBR:
route-map test permit 10
match ip address 100
set ip default next-hop Site2-Edge-Router
In this scenario, SW1 is supposed to pass traffic from 100.100.100.0/24 to any destination ( Except existed ones in routing table) to SW2 for using the internet. So, packets to exist destinations in routing table must be routed based on this table and if the destination is not exist, they must be policed. But after applying the route-map to the SVI vlan 100, traffics to internal networks will be timed out( Clients even can not ping the gateway (SVI100); however Traceroute is complated successfully! For solving this problem, I have to deny internal network in IP access-list ; however, SET IP DEFAULT NEXT-HOP is supposed to use Routing Table and then policy the traffic if it could not find a route in the table.
For clarification:
It is supposed to not policy traffic to destinations within routing tables. But it seems to policy all packets.
I mean, it is working like SET IP NEXT-HOP
ā10-21-2020 02:29 PM
R-MLS1-MLS2
you want internal VLAN to route in each MLS and if other then use edge router?
use one vlan
vlan connect R1-MLS1 -access or trunk -MLS2
config default toward next hop R
this way if traffic is route internal it ok if not then the packet will forward to R.
please try this design and send me result.
ā10-21-2020 09:54 PM
Thanks for replying,
Both MLS1,2 has their own Edge router and a default route to it. MLS1 sends internet traffic to Edge1 and MLS2 sends internet traffic to Edge2. But, we have a specific VLAN connected to MLS1 which is supposed to use the ISP connected to Edge2. So, for making an exception in routing we used an ACL to distinguish the traffic (Permit ip VLAN X to ANY) and also a PBR to set the next hop which is MLS2( Set ip DEFAUL next-hop MLS2). This command is designed to: first, check the Routing table and if there was a route to the destination(Internal networks) not policy that. Then, applys the policy if couldn't find a route in table.
After applying the policy to SVI, clients are able to access the internet through Edge2( this part of scenario is working fine). But, they are not able to access and ping internal networks incluing their defaul-gateway!(normal routing); however Tracert completes successfully! (How does it happen? they are not able to ping the gateway but have internet access!!!). After removing the policy from the interface, clients are able to access internal netwoks but the internet traffic is routed through Edge1 (Different than what we need)
ā10-21-2020 11:59 PM
route-map test deny 10
match ip address 110
Route-map test permit 20
Match ip address 100
set ip default next-hop Site2-Edge-Router
For acl 110 make it match subnet to other subnet internal
Try this way and send me result later
ā10-22-2020 01:25 AM
Dear MHM,
I know it and I've already configured Deny statements to address the issue. The problem is with the concept.
set ip default next-hop is supposed to firstly check the routing table and do the normal routing (So there shouldn't be any need to deny statement for internal routes because it has a higher priority). If we need to Deny internal traffic with ACL, why we have to use DEFAULT keyword in the set command? we can use set ip next-hop .
Cisco says set ip default next-hop check routing table first, then goes for PBR.
ā10-22-2020 01:49 AM
Hello
"set ip default next-hop is supposed to firstly check the routing table and do the normal routing"
This is correct however it would depend on the topology which at present you are not being clear on, Please post a topology of this network so we can better understand it.
ā10-22-2020 02:14 AM
Hi Paul,
Great to have you here,
Well, it is not possible to copy the configuration here for some reasons. But I can say:
1. All VLANs are shown in MLS1 routing table as Connected
2. Connected networks to MLS2 are propagated using EIGRP, So MLS1 has a summarized route to MLS2 .
Same situation for MLS2.
You can ignore MLS2 from the scenario. Why PBR is applying even on traffic to directly connected destinations :
MLS1: int vlan 100 ip add 100.100.100.1 255.255.255.0 int vlan 110 ip add 110.110.110.1 255.255.255.0 int vlan 120 ip add 120.120.120.1 255.255.255.0 ip policy route-map test ip access-list 100 permit ip 120.120.120.0 0.0.0.255 any route-map test permit 10 match ip add 100 set ip default next-hop MLS2_IP router eigrp 1 network 100.100.100.1 network 110.110.110.1 network 120.120.120.1 ip route 0.0.0.0 0.0.0.0 Edge1_IP
In this scenario, traffic from 120.120.120.0/24 to any destination (Except those existing ones in routing table) are supposed to be normally routed. But after applying policy to vlan interface, clients can't ping any internal address; however they can access internet through MLS2.
ā10-22-2020 02:19 AM - edited ā10-22-2020 02:50 AM
Hello
I can see you have a default route set, and when you have a default route in the rib and you apply set ip default next-hop it will be policy routed with the ip default next-hop as its overriding the current default route.
ā10-22-2020 02:36 AM
Of curse it is. As I said, traffic from clients in VLAN 120 is passing through MLS2 to internet successfully. The problem is with traffic to internal networks(which are directly connected to MLS1 or learnt from other neighbors)
* Everything would be great by Denying internal traffic in first sequences of ACL. But I am looking for a logical answer to justify DEFAULT keyword
ā10-22-2020 03:05 AM - edited ā10-22-2020 05:35 AM
Hello
You are at present telling the router to policy route all traffic from vlan 200 towards the set ip default next-hop ip address, now if you want to negate certain traffic to be policy routed say between vlan 200 and vlan 100-110 then you will need a deny ace statement before the permit ace statement in your acl
no ip access-list 100 permit ip 120.120.120.0 0.0.0.255 any
ip access-list 100 deny ip any 100.100.100.0 0.0.255
ip access-list 100 deny ip any 110.110.110.0 0.0.255
ip access-list 100 permit ip any any
And the logical answer is set ip default next hop when used inconjunction with a default route existing in the rtrs rib table is that the traffic in the Policy statement will be policy routed
ā10-22-2020 08:21 AM
Thanks a million for the time you're spending on this topic.
So, I am wrong about definition of set ip default next-hop. Because I thought it doesn't matter weather we have or have not default route and it only check RIB for normal routing and then goes for PBR. But as you said, when we have a default route, this command means overriding the default route (Just it). Something like a separate default route for specific traffic.
So, there is no difference between set ip next-hop and set ip default next-hop in my scenario. Right?
I was looking for a way to do the job without denying other traffic. What about the scenario without default route? That wouldn't need Deny lines. Right?
ā10-22-2020 09:59 AM - edited ā10-22-2020 10:16 AM
Hello
In your scenario it looks like you have a default route and are also receiving eigrp routes, so if you specify the set ip default nexthop/interface at this point no policy routing will occur on the pbr rtr as there would be more specific routes to the destination via eigrp ( rib check ā just as you stated), However if the PBR rtr wasnāt receiving any specific routes but was receiving or had only default routes then your PBR statement with set ip default next hop/interface will work.
Lastly if you add a recursive statement which also will check the rib first for forwarding to the specified recursive ip however this time irrelevant even if you had default routes or specific routes policy routing via the rib will occur as the recursive will take precedence over set ip default next-hop/interface,
ā10-22-2020 11:52 AM
So far we do not know much about the switches being used. And that might be significant. I know that on some switches (and perhaps some versions of code) that set ip default next-hop does not work - or does not work correctly. What can you tell us about these switches? What model of switch? What version of code? Are these real switches or is this in some emulator?
I am also concerned about the statement that hosts in the subnet being policy routed can not ping their gateway but that tracert does work.
As I understand the discussion I believe that conceptually you are correct. With the access list that you are using every packet from a host in vlan 100 should be evaluated for PBR. When using set ip default next-hop they should use normal routing for other connected networks and for networks learned via EIGRP and only traffic to destination using the default route should be changed. That fact that this appears to be not working makes me wonder if something in the actual configuration is different from what we expect or that these particular switches have an issue with this feature. Perhaps output from debug for PBR might provide some insight?
ā10-24-2020 08:10 AM
Hello Rechard,
Thanks for joining us.
Maybe it is a bug and maybe is not!(Check Paul's last reply about the existence of default roue in our scenario). Although I am a bit angry with Cisco and its logic behind this justification and I am not hundred percent satisfied. Because I think the instruction behind the code should be kept the same(Whether we have default route and learnt route from neighbors or not)
ā10-21-2020 11:51 PM
Hello,
something doesn't look right in your routing tables: if you have an SVI for Vlan 50 on both switches, there should be a 'C' (connected) entry for that Vlan in your routing tables ?
Post a schematic drawing of your topology showing how everything is connected.
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