Source route on C5110

[thedub412]

Hi -
We have a C5110 that I want to put a source route or next hop on the l3 interface -
For example Vlan 1 serves dhcp for 10.10.0.0/21 - however, we did not want the l3 interface to live on the core, so it is only on the controller. I wanted to route to the next hop of vlan 2 that has an l3 interface on the controller of 10.10.1.3 and it's l3 interface on the core is 10.10.1.1. Is there a way to do a source route for this traffic on the controller we have? I looked into doing a PBR but the way I have done them in the past is passing on dscp markings to the core and putting the route map on the l3 interface that lives there.

[Gareth_Mitchell]

Hello

If the topology you are using is routed, you can use the next hop routing field within the DHCP definition for the DHCP service which will direct all traffic from this topology to this hop, does this achieve what you want?

From the manual:
Next-hop routing — Use next-hop routing to specify a unique gateway to which traffic on aVNS is forwarded. Defining a next-hop for a VNS forces all the traffic in the VNS to be forwarded to the indicated network device, bypassing any routing definitions of the controller's route table.

Best regards

-Gareth

[Gareth_Mitchell]

The next hop needs to be in a different topology to the routed topology, that's correct. How this next hop is reached is down to the egress topology on the controller, so if for example the next hop is a physical interface on esa0 then you can tag or untag as you choose. I hope that makes sense?

[thedub412]

I could Gareth - but the issue that I run into is that when choosing the routed interface option, traffic across the vlan is untagged and not tagged - as this port is a trunk port on a cisco switch, wouldn't that need to be tagged traffic? Also when creating the interface it states that the remote ip needs to be on a separate subnet?

[Gareth_Mitchell]

Hi

Firstly, route at the controller is also tunnelled, the difference is that the traffic ingressing or egressing this topology does so via routing, rather than via an l2 bridge. For this reason, next-hop-routing on the controller is only supported in routed topologies.

In a bridge at controller environment you would need to use PBR on connected routers to intercept this traffic as it leaves the tunnel into the l2 world and forward it just as you would any other traffic in the wired world, but this doesn't seem to fit quite with your requirement?

Could you switch to a routed topology instead?

-Gareth