How do I create DHCP-destined routes?

[btarratt]

I have a TA908E G3 running R10.9.4, and I'd like to point a route to the gateway I've learned from dhcp.  On a cisco, I can do, for example,

ip route 192.0.2.0 255.255.255.0 dhcp

I need traffic to one subnet to only ever exit by way of the interface learning it's address via DHCP, and I do not know the address of the gateway the DHCP client will learn.  Is there a way to do this in AOS?

[Anonymous]

Hi btarratt:

The default gateway learned via DHCP will be the only available route unless you add a static route.  All routed traffic will forward to that gateway so there should be nothing more you need to do.  Are you observing a different behavior in your AOS unit?

Best,

Chris

[btarratt]

I've increased the administrative distance of the route learned from DHCP to 10, because I want to use a different route for default.

int eth 0/1
  ip address dhcp 10
ip route 0.0.0.0 0.0.0.0 10.10.10.1

I wish to add a specific route to this one destination (in my example, 192.0.2.0/24) by way of the gateway I learned from DHCP (which I don't know ahead of time).

[Anonymous]

Got it--thanks for clarifying.  I'm unable to think of a concise way to handle that scenario.  Perhaps the use of Multi-VRF (see Configuring Multi-VRF in AOS for more info) could open up more flexibility, but I'm not certain.  VRF is not something with which I'm proficient.

Another approach could be Policy-Based Routing (PBR).  See Configuring Policy Based Routing in AOS for complete info.  I think you could leave DHCP at administrative distance zero in this approach and remove the static default route.  Build an ACL to match all traffic except 192.0.2.0/24.  Create a route-map to use 10.10.10.1 as the next hop for traffic to that subnet.  Maybe like this:

!

ip local policy route-map PreferredGateway

!

!

interface eth 0/1

  description LAN

  ip address dhcp

  ip policy route-map PreferredGateway

  no shutdown

!

!

route-map PreferredGateway permit 10

  match ip address GeneralTraffic

  set ip next-hop 10.10.10.1

!

!

ip access-list extended GeneralTraffic

  remark General Traffic

  deny ip any  192.0.2.0 0.0.0.255

  permit ip any any

!

What do you think?

Chris

Edited to correct syntax mistake in ACL (deny not discard).

Edit 2 to correct syntax mistake in ACL (permit not match).  Duh!

[btarratt]

I do not believe PBR will work, as I have my other default route tracking a probe, like so:

ip route 0.0.0.0 0.0.0.0 10.10.10.1 track cable-track

Should have mentioned that in my previous example.  Sorry.  I don't think you can make PBR track probes, can you?

I'm not sure how you'd do it with VRFs - VRFs are just virtual routing tables, they let you break a router into multiple virtual routers in the same way VLANs allow you to break a switch into multiple virtual switches (to put it simply).

[Anonymous]

In that case you'd want to make the ACL used in the route-map track-dependent, like this:

!

ip access-list extended GeneralTraffic

  remark General Traffic

  deny ip any  192.0.2.0 0.0.0.255

  permit ip any  any  track cable-track

!

When the track fails, the match statement will cease matching general traffic, and so the route-map will have no valid traffic on which to act.  Packets will be forwarded according to the route table in that case (which will contain the learned default gateway from DHCP) until the track flips back to the pass state.

Note that it is important to avoid ending up with an empty ACL.  In AOS, empty ACLs are considered an implicit 'match any' and this would cause PBR to always be in effect, since it would match all traffic.  I believe the deny statement should be enough to keep the ACL from matching any.  But I have encountered a case where this did not function properly.  I modified my ACL something like this and it functioned properly:

!

ip access-list extended GeneralTraffic

  remark General Traffic

  deny ip any  192.0.2.0 0.0.0.255

  permit ip any  any  track cable-track

  permit ip host 1.1.1.1  host 1.1.1.2

!

Thanks for the clarification about VRF.  I have some learning to do in that area.  Let us know what you think about this approach with PBR.  Anyone have a more elegant solution?

Chris

Edited to correct syntax mistake in ACL (permit not match).

[btarratt]

I don't see a "match" command under acl config.

router(config-ext-nacl)# ?
deny                   - Specify criteria for packets that should not match 
                         this ACL
do                     - Execute a root command
exit                   - Exit from configure mode
no                     - Negate a command or set its defaults
permit                 - Specify criteria for packets that should match this ACL
remark                 - Access-list entry comment

[Anonymous]

Forgive me, it's permit.  I'll update the examples right away in case this thread is referenced in the future.

Chris

[btarratt]

Oooh, now you've got my attention.  ACL entries dependent on tracks.  Most interesting.  Not as clean in this case as "ip route x.x.x.x x.x.x.x dhcp", but I see possibilities for sure.  Ciscos certainly can't do that (at least not in IOS 12.4-15 T11), and that looks like it opens numerous doors.  Into the rabbit hole I go!

[btarratt]

Hmm, if I'm reading correctly, PBR is subject to the same limitation on Adtrans that it is on Ciscos - it's applied to an interface that the traffic must enter.  So traffic from the router itself is not subject to PBR.  The specific route I'm trying to add is specifically for router-generated traffic.  If my understanding is correct, this won't work for me.

[Anonymous]

Router self-sourced traffic can be policy-routed when you set the local policy, like this:

!

ip local policy route-map PreferredGateway

!

The document Configuring Policy Based Routing in AOS explains in better detail.

Chris

[Anonymous · Accepted solution]

btarratt‌:

Thank you for asking this question in the support community forum.  There are ways to accomplish this, but cj!‌ is right, this is typically done with a route-map.  Within the route-map, you would use the set interface command to use the interface where the DHCP route/gateway is received.  From the Configuring Policy Based Routing in AOS guide cj!‌ referenced, on the top of page 16:

The set interface ethernet command and the set interface vlan  command can be used only when DHCP is utilized so the router will forward traffic to the default gateway learned on that particular interface.

The example configuration would be similar to the following:

ip access-list extended DHCP-PBR-ACL

permit ip any 192.0.2.0 0.0.0.255

!

route-map DHCP-PBR permit 10

match ip address DHCP-PBR-ACL

set interface ethernet 0/1

I hope that makes sense, but please do not hesitate to reply to this post with any additional questions or information.  I will be happy to help in any way I can.

Levi

[Anonymous]

btarratt‌:

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Levi