This article explains how to configure BOOTP helper for VR to VR functionality using rib-groups. This is useful when the client-facing interface is in one virtual-router and the external DHCP server is reachable through a different virtual-router. There are a couple of ways to have BOOTP helper handle this type of configuration, but this article will use rib-groups to accomplish this.
This article provides a configuration example to assist customers having DHCP clients in one virtual-router and access to the DHCP server is through a different virtual-router. This can be accomplished using rib-groups to leak routes from the DHCP server routing-instance (RI) and the Client RI.
Noted below is a configuration example showing that DHCP clients in RI "CLIENT" will be able to receive a leased IP address from a DHCP server which is located externally from RI "SERVER" using Rib-Groups.
Topology:
Client facing Interface: ge-1/3/9.100
Server facing interface: ge-1/0/0.0
Interface configuration:
lab@MX80-brevaz# run show configuration interfaces ge-1/3/9
vlan-tagging;
unit 100 {
description BOOTP-CLIENT;
vlan-id 100;
family inet {
address 25.25.25.1/24;
}
}
lab@MX80-brevaz# show interfaces ge-1/0/0
unit 0 {
description TO-DHCP-SERVER;
family inet {
address 150.150.150.1/24;
}
}
RIB-GROUP Configuation (leak routes from CLIENT.inet0 to SERVER.inet.0)
lab@MX80-brevaz# run show configuration routing-options rib-groups
CLIENT {
import-rib [ SERVER.inet.0 CLIENT.inet.0 ];
}
SERVER {
import-rib [ CLIENT.inet.0 SERVER.inet.0 ];
}
ROUTING-INSTANCE Configuration:
lab@MX80-brevaz# run show configuration routing-instances
CLIENT {
instance-type virtual-router;
interface ge-1/3/9.100;
interface lo0.100;
routing-options {
interface-routes {
rib-group inet SERVER;
}
static {
route 41.41.41.0/24 next-hop 39.39.39.1;
}
}
}
SERVER {
instance-type virtual-router;
interface ge-1/0/0.0;
interface lo0.200;
routing-options {
interface-routes {
rib-group inet CLIENT;
}
static {
route 40.40.40.0/24 next-hop 39.39.39.2;
}
}
}
Routing-Table for both RI:
CLIENT.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
25.25.25.0/24 *[Direct/0] 00:26:26
> via ge-1/3/9.100
25.25.25.1/32 *[Local/0] 00:26:26
Local via ge-1/3/9.100
40.40.40.1/32 *[Direct/0] 2d 21:51:58
> via lo0.100
41.41.41.1/32 *[Direct/0] 2d 20:05:19
> via lo0.200
150.150.150.0/24 *[Direct/0] 00:25:34
> via ge-1/0/0.0
150.150.150.1/32 *[Local/0] 00:25:34
Local via ge-1/0/0.0
SERVER.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
25.25.25.0/24 *[Direct/0] 00:26:26
> via ge-1/3/9.100
25.25.25.1/32 *[Local/0] 00:26:26
Local via ge-1/3/9.100
40.40.40.1/32 *[Direct/0] 2d 20:05:19
> via lo0.100
41.41.41.1/32 *[Direct/0] 2d 21:51:58
> via lo0.200
150.150.150.0/24 *[Direct/0] 00:25:34
> via ge-1/0/0.0
150.150.150.1/32 *[Local/0] 00:25:34
Local via ge-1/0/0.0
Helper bootp configuration:
[edit]
lab@MX80-brevaz# run show configuration forwarding-options helpers
bootp {
relay-agent-option;
interface {
ge-1/3/9.100 {
server 150.150.150.2 routing-instance CLIENT;
}
}
}
Please note that the routing-instance statement typically notes which RI the DHCP server is accessible from. Typically, the client-facing interface and reachablitly to the DHCP server are in the same RI. Since there are 2 RI's, one defines the client-facing RI since it technically has reachability to the DHCP server via the rib-group configuration. Also BOOTP helper will not be able to route the DHCP offers back to the client without having the relay-agent option enabled. The relay-agent knob will tag the option-82 of the client-facing interface. This will be stored internally and help in routing the DHCP OFFER back to the client-facing interface. Without this knob enabled, this configuration will fail. If the DHCP server does not support option-82 then the DHCP OFFERs will be dropped.