This has been talked about before on this list but I'd like to bring it up again for my particular situation.
I have a pair of border routers, 1 with 2 upstream connection and the other with a single connection. I'm pulling down full tables from each provider and have iBGP between the border routers and the core routers. Each border router has a static default pointed to the outgoing interface for the local upstream connections (2 on one router and 1 on the other). As expected the router with 2 default routes flops back and forth between the 2 interfaces every second or two. 35578126: Aug 16 10:20:22.385 CDT: RT: SET_LAST_RDB for 0.0.0.0/0 OLD rdb: is directly connected, GigabitEthernet0/3 NEW rdb: is directly connected, ATM1/0.1 35578127: Aug 16 10:20:23.645 CDT: RT: SET_LAST_RDB for 0.0.0.0/0 OLD rdb: is directly connected, ATM1/0.1 NEW rdb: is directly connected, GigabitEthernet0/3 I know that this forces an ARP query every time a packet falls back on the default route. That isn't desirable of course. However if I don't hardcode the default route each border router will learn the default from the other border router thanks to the IGP (both borders originate the default for the benefit of the rest of the network behind it). Given that these routers have full tables the only time I can think of that a packet should not find its destination in the RIB is if it's for a route that I'm dampening or it's a bogon (which I'm catching with ingress/egress filters anyway). However routing these packets to the other border router results in less than optimal routing. I would like to implement uRPF on the upstream interfaces though so the default routes will have to be removed for that to work. So a question would be how I remove the static default without learning the default from the IGP (distribute-list?)? What would be the proper configuration for this scenario? Besides the frequent ARPs and my uRPF desires, is this really a big problem? Or am I missing something obvious again? :-) Thanks Justin _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
