[j-nsp] dhcp relay fail between VRFs

[Aaron1]

Dang typos... 

Did you apply local prefix leaking feature using auto-export to get multiple vrfs talking on same PE ?

https://www.juniper.net/documentation/en_US/release-independent/nce/topics/concept/auto-export-overview.html

Aaron

> On Dec 19, 2018, at 1:13 PM, Aaron1 <aaron1 at gvtc.com> wrote:
> 
> aside from proper RT import/export...
> 
> Auto export to get multiple vrfs taking on some PE ?
> 
> Aaron
> 
>> On Dec 19, 2018, at 12:57 PM, Chris Cappuccio <chris at nmedia.net> wrote:
>> 
>> I have no trouble with dhcp relay between VRFs across MPLS PE routers,
>> but across VRFs on the same router, the relay daemon fud fails.
>> 
>> If I turn on debugging, I am always getting:
>> 
>> Dec 18 19:49:06 FUD_RTSOCK_MSG_FAILURE: Unable to get prefix match: No such file or directory
>> Dec 18 19:49:06 reply from 192.168.200.2 no interface for 192.168.204.69
>> Dec 18 19:49:10 FUD_RTSOCK_MSG_FAILURE: Unable to get prefix match: No such file or directory
>> Dec 18 19:49:10 reply from 192.168.200.2 no interface for 192.168.204.69
>> 
>> The DHCP server at 192.168.200.2 is assigning 192.168.204.69 and the fud
>> program is trying to reply directly to it, EVEN THOUGH the dhcp server
>> is replying to the router's gateway address in the destination subnet, not
>> directly to the unreachable layer 2 device. fud is trying to resolve
>> the layer 2 interface based on the assigned IP?? When this happens on
>> other PE routers, the DHCP server replies to the gateway address and
>> fud doesn't get involved, the packet just gets forwarded to the remote
>> router and the relay is completed properly.
>> 
>> The thing is, inet.0 has routes for both 192.168.200.0/24 and 192.168.204.0/24
>> leaked from their respective VRFs. Routes for each VRF are also leaked to each
>> other. fud should be able to look up the interface for 192.168.204.69 with no
>> problem. 
>> 
>> inet.0: 724201 destinations, 1445332 routes (722565 active, 0 holddown, 3213 hidden)
>> + = Active Route, - = Last Active, * = Both
>> 
>> 192.168.204.64/26  *[Direct/0] 16:05:50
>>> via ge-5/1/6.8
>> ...
>> pub-vrf.inet.0: 168 destinations, 169 routes (168 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>> 
>> 192.168.204.64/26  *[Direct/0] 16:05:50
>>> via ge-5/1/6.8
>> ...
>> serv1-vrf.inet.0: 530 destinations, 544 routes (530 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>> 
>> 192.168.204.64/26  *[Direct/0] 16:05:50
>>> via ge-5/1/6.8
>> 
>> Can anyone help give me a clue about how and where fud looks for interfaces and
>> routes? It can't be inet.0 that it's looking at. The serv1 vrf is where the
>> DHCP server lives. The pub vrf is where the client lives. Both vrfs have
>> routes to the client.
>> 
>> On this same router, any relays within the same VRF work just fine. fud
>> can find the route, no matter what the VRF is. 
>> 
>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp