Other than breaking up the LAN prefix that R3 advertises, I can't think of a practical way to do this offhand. Load sharing between IBGP and EBGP isn't possible to my knowledge, though someone else may be able to correct me. Load sharing among EBGP paths has been available for a while, and load sharing among IBGP paths was introduced recently, but I don't recall ever seeing anything about load sharing between IBGP and EBGP paths.
What I mean by breaking up the prefix is this. Assume the LAN prefix is 10.1.1.0/24. You could have R3 advertise 10.1.1.0/25 to R1 and 10.1.1.128/25 to R2, which R2 would also advertise to R1. R1 would then send traffic destined to 10.1.1.0/25 directly to R3 and traffic destined to 10.1.1.128/25 would be routed via R2.
You'd want R3 to continue announcing the entire prefix (10.1.1.0/24) to both R1 and R2 (like it is currently) for redundancy purposes. So if the R1 <-> R2 link fails, traffic for 10.1.1.128/25 will follow the 10.1.1.0/24 route directly to R3.
Whether or not this type of load sharing is possible in your environment depends on the traffic patterns. The LAN prefix can be broken up any way you want, even into /32's if necessary. But if all or most traffic is sourced from or destined to a single host on the LAN, this won't do you any good.
So, I wouldn't count on it helping you out here.... Configuring the multihop eBGP session seems to be your best bet, if that will work. You have to know about the next hop through both R2 and the connected link, and the igp path has to have the same cost.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...