Description

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.

Symptoms

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.

Solution



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.