Gaurav wins! Unless it says "dont do it this way" you can. Just be aware of what one way of doing something will break elsewhere in the network.
Which is why (as Gaurav says) you must know multiple ways of doing things. Cheers, Matt CCIE #22386 CCSI #31207 On 20 August 2010 00:52, GAURAV MADAN <[email protected]> wrote: > Mate .. > > First .. Lemme tell u that if u know of more than one way of doing > things .. U r on track :) It certainly helps in exam .. > Coming to your point .. Read the instructions very very carefully .. > They will answer your query most of times .. In case u still have > doubt .. Proctor is there to help you .. Go and tell that u know of > these these ways to perform the task .. If he thinks that he shd > answer your query .. he will definitely do .. > If he doesn't .. there is something hidden in question and try > figuring that out .. > > Remember CCIE is not the exam to just do the task .. It is exam to do > task ; the way they want :) > > Just my 2 cents .. > > Good Luck ! > > Gaurav Madan > CCIE # 23863 > > On Thu, Aug 19, 2010 at 7:33 AM, Cody Cook <[email protected]> wrote: >> I have a question for everyone. I'm using a variety of vendors' >> workbooks to work on labs and have run across something that has been >> bothering me. Not so much a question about any lab but more of a >> general thing. If the lab you are working on doesn't expressly forbid >> a solution, is it okay to use it? More specifically the use of >> tunnels to solve some issues. >> >> Here is an example of what I mean. You have two routers that you are >> told to set up as EBGP peers. Router 1 (R1) is in AS 100 and router 2 >> (R2) is in AS 200. Let's assume that they are connected to a common >> vlan using f0/1. R1 has an ip of 10.0.0.1/24 with a secondary ip of >> 10.1.1.1/24. R1 has an ip of 10.1.1.2/24 with a secondary ip of >> 10.0.0.2/24. You are told to set up the peering without using the >> secondary addresses. >> >> R1 >> int f0/1 >> ip address 10.0.0.1 255.255.255.0 >> ip address 10.1.1.1 255.255.255.0 secondary >> >> R2 >> int f0/1 >> ip address 10.1.1.2 255.255.255.0 >> ip address 10.0.0.2 255.255.255.0 secondary >> >> One way to do this would be to set your neighbor statements within BGP >> to point to each of the primary addresses. In order to get the peer >> to come up you will need to add "update-source f0/1" for one of the >> neighbor statements. >> >> R1 >> router bgp 100 >> neighbor 10.1.1.2 remote-as 200 >> neighbor 10.1.1.2 update-source f0/1 >> >> R2 >> router bgp 200 >> neighbor 10.0.0.1 remote-as 100 >> >> This works well. Another way would be create a tunnel, assign it some >> addresses and set the peering relationship through it. While not the >> best solution, it would work. Probably not a good example, but it one >> that comes to mind. >> >> So I guess the gist of my question is this, if for some reason you >> can't get something to work for you and for what ever reason you can't >> come up with another solution. In the example above, say for whatever >> reason you just didn't think of using update-source on one of the ends >> and the tunnel was the only way you could get it to work, would this >> be acceptable in the lab. While obviously not the optimal solution, >> it does work and it doesn't violate any of the rules of the scenario. >> Is it cool to use something like this in the lab? >> >> Like I said, not a big deal, just something that's been bugging me. I >> have had a couple of instances where I have noticed that you could >> come up with a similar soluton. Hopefully hs makes sense. >> >> Thanks. >> Cody >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
