Hello, Perhaps you should just try and combine the graphs in whatever graphing software you are using and police them to their commit on both ports. Then the customer is responsable for controlling the active/backup and the BW usage. You just bill them on what they use since you don’t care how they use it.
The other option I read up on for a different situation was redundant trunk groups. Ive never used them in production so YMMV, I’m also not sure if your platform supports it. [http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/cfm-redundant-trunk-groups-understanding.html <http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/cfm-redundant-trunk-groups-understanding.html>] Cheers, Max > On Jul 14, 2016, at 9:14 AM, Cydon Satyr <cydonsa...@gmail.com> wrote: > > Hi, > > I understand, but if you are forcing customer to always use primary link if > it is up, and customer advertises his routes over backup link ONLY, then he > can go around uRPF restriction. > With uRPF you are assuming he advertises all of his routes over primary > link where router can prioritize them. Correct? > > @Alan > > I'll have a look at at MC-LAG. Looks like this might work (customer must > not enable lacp). > > And yes, I agree 95th percentile metering both primary/backup works best. > What we have here is unfortunate case of trying to put band-aid over > something which is supposed to work differently. > > Regards > > On Thu, Jul 14, 2016 at 9:48 AM, Harald F. Karlsen <elf...@gmail.com> wrote: > >> On 14.07.2016 01:43, Cydon Satyr wrote: >> >>> uRPF check doesn't work since customer can just advertise his routes over >>> backup link. >>> I had some hopes for conditional bgp advertisement and SCU/DCU but I don't >>> think it works not to mention it's like trying to kill a bee with a >>> hammer. >>> >>> I'm talking about uRPF *strict* mode, not loose. >> >> uRPF strict should work. The customer will advertise his routes over both >> the primary and the backup link, but you will decide to use only the >> primary (using local pref) and with no active route in the forwarding table >> toward the customers backup link, uRPF strict will deny any traffic on that >> link. >> >> If the primary link goes down, the routes in the forwarding table are >> moved to the backup link and uRPF strict will start accepting traffic on >> that link. >> >> To me this seems like the simplest and most secure solution. >> >> -- >> Harald >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
