Your explanation about the load sharing in the IGP is correct. Like I said, if you are peering with the loopback address, and your IGP has 2 equal cost paths to that loopback address it will load balance behind the scenes BUT I would be very careful with this in the real lab...they are probably looking for (as in this task) load balancing within BGP ...so in other words, they want to actually see 2 different next hop addresses like you said one for ODDS , one for EVENS, which will require 2 different peerings. As far as that Cisco example, I agree you need maximum-paths in both examples, I do not think the first one is correct. What I was trying to get at Carlos was to allow you to understand the difference between load balancing in BGP and load balancing behind the scenes because your IGP has equal cost paths to the next hop
Regards, Joe Astorino CCIE #24347 (R&S) Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com <http://www.ipexpert.com/> _____ From: Carlos Valero [mailto:[email protected]] Sent: Monday, June 08, 2009 3:18 PM To: 'Bryan Bartik'; Joe Astorino Cc: [email protected] Subject: RE: [OSL | CCIE_RS] IPE Vol3 Lab 4 Task 4.1 Thank you for your reply! You are right. Task 4.2 in fact would require to have separate links in order to send ODD routes one way and EVEN routes the other way. I guess I keep forgetting to always "look ahead". That's difficult to do! Regarding the first part of your email, let me see if I understand correctly. You wrote: "lets talk about load balancing. I think you might have the wrong idea here ..." I don't know why I would have a wrong idea here. These Serial Links are in OSPF areas 96 & 97. So the IGP for them is the same and therefore the Cost Metric should be the same in this case. If the Cost is the same (and it is the same in this case), then there should do Load Balancing. I think I don't understand why this could be wrong. Would you please let me know? Finally, you also mentioned the maximum-paths command. But I'm a bit confused about this as well. I hope you can explain a little bit more. I was reading this Cisco Tutorial about Load Sharing: http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example0918 6a00800945bf.shtml Here, the first example is very similar to the situation we have in Task 4.1 That is, 2 links between a pair of Routers: Link 1: From Router A to Router B Link 2: From Router A to Router B The only difference is the fact that in Task 4.1 both Routers are in the same AS, while in the Cisco's example Routers are in different AS's. But here they do NOT use maximum-paths in this case. However, they do use maximum-paths in the next example, in which the Links are not between the Routers. That is, there are 2 links: Link 1: From Router A to Router B Link 2: From Router A to Router C Frankly, I don't see the difference. I would agree with you that maximum-paths should be needed in both cases! But then I don't understand why it is not use in the first example! Should we use maximum-paths in both cases? Thank you again! --- On Mon, 6/8/09, Joe Astorino <[email protected]> wrote: From: Joe Astorino <[email protected]> Subject: RE: [OSL | CCIE_RS] IPE Vol3 Lab 4 Task 4.1 To: "'Carlos Valero'" <[email protected]>, "'Edward''Bodnar'" <[email protected]>, "'Bryan Bartik'" <[email protected]> Cc: [email protected] Date: Monday, June 8, 2009, 1:54 PM Hi Carlos, First off, I apologize if you have not had questions answered in a timely fashion in the past. I know that since I came on board I try to answer everybody's questions as soon as I can. With that being said, lets look at your question. OK first of all, lets talk about load balancing. I think you might have the wrong idea here. If you have 2 links, say like you have between R6 and R9 and you peer using the loopback address, you won't have load balancing from a BGP perspective. Remember BGP will only select the 1 best path by default...so in this case, if you did peer using the loopback, your best path would always be via that loopback address, which would be looked up in your IGP...now if your IGP has equal cost metrics to that loopback address, yes it will load balance. Looking ahead to 4.2 you are asked to make sure certain traffic goes through 1 link and certain traffic goes through the other link. To do this in BGP they are looking for load balancing actually within BGP. To do that you need to have more than 1 path first of all...so you need to have 2 seperate peerings. Secondly, you need to modify BGP to make sure you tell it to use more than 1 path with the max-paths command. When you look at the routing table you should see the next hop via the links it specifies. Does this help? If you have any more questions don't hesitate to post back. Regards, Joe Astorino CCIE #24347 (R&S) Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com <http://www.ipexpert.com/> _____ From: Carlos Valero [mailto:[email protected]] Sent: Monday, June 08, 2009 1:48 PM To: Edward''Bodnar; 'Bryan Bartik'; Joe Astorino Cc: [email protected] Subject: Re: [OSL | CCIE_RS] IPE Vol3 Lab 4 Task 4.1 I have not had any luck with my questions so far. That is, nobody answers them. So I quit wasting my time sending questions. But I hope I have better luck this time, because I would like to get an explanation for this one. I don't quite understand part of the answer to Task 4.1 Specifically, I'm referring to the BGP session between R6 & R9. Both Serial Links are active in this case: R6 interface Serial0/0 ip address 144.44.60.6 255.255.255.0 ! interface Serial0/1 ip address 144.44.61.6 255.255.255.0 R9 interface Serial0/0 ip address 144.44.60.9 255.255.255.0 ! interface Serial0/1 ip address 144.44.61.9 255.255.255.0 And are being asked to configure a IBGP session between these two. Since we have 2 links between this pair of Routers, then it would make a lot more sense to establish the BGP session using the Loopbacks, so that we get Load Balancing, correct? Load Bal. is not a requirement in this case, but as far as I know, that's always the Best Practice anyway. However, the solution does NOT do that. Instead, it just creates 2 separate sessions: R6 router bgp 96 neigh 144.44.60.9 remote 96 neigh 144.44.61.9 remote 96 R9 router bgp 200 neigh 144.44.60.6 remote 96 neigh 144.44.61.6 remote 96 Question is: Is there any VALID reason why you are doing this here? Thank you! --- On Mon, 6/8/09, Joe Astorino <[email protected]> wrote: From: Joe Astorino <[email protected]> Subject: Re: [OSL | CCIE_RS] IPE vol2 lab 3 To: "'Bodnar, Edward'" <[email protected]>, "'Bryan Bartik'" <[email protected]> Cc: [email protected] Date: Monday, June 8, 2009, 11:48 AM Hey Ed, 1) You need to use this command if you are using Auto-RP in a sparse-mode environment 2) Basically here is the idea -- OK, think about how Auto-RP works, it uses dense mode to propogate the RP information using 224.0.1.39 and 224.0.1.40.....so by design the information is propogated throughout the entire multicast domain. When you use sparse mode, it basically breaks this concept...because you are not requesting the groups you will not get them. What the command does is sort of a "hack." It allows you to use Auto-RP even though you are using sparse mode. Essentially it says "For 224.0.1.39 and 224.0.1.40 I am allowed to use dense mode, for everything else use sparse mode" HTH, Regards, Joe Astorino CCIE #24347 (R&S) Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com <http://www.ipexpert.com/> _____ From: [email protected] [mailto:[email protected]] On Behalf Of Bodnar, Edward Sent: Sunday, June 07, 2009 8:30 PM To: 'Bryan Bartik' Cc: [email protected] Subject: Re: [OSL | CCIE_RS] IPE vol2 lab 3 I have a question about "ip pim autorp listener" 1. When do I need to use this sparce-mode only ? sparce-dense-mode 2. What does this command do. I take it off my configuration and it seems to be working without it. ED, No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.54/2158 - Release Date: 06/08/09 06:01:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.54/2158 - Release Date: 06/08/09 06:01:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.54/2158 - Release Date: 06/08/09 06:01:00
