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 <[email protected]> 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 <[email protected]> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
