Thanks Bryan, I'm trying it in GNS right now. On Wed, Aug 19, 2009 at 9:50 PM, Bryan Bartik <[email protected]> wrote:
> Vikas, > > Not sure if this will work in a non-mpls vpn environment, but cost > community can be used to prefer the cloud over the backdoor link. Read more > here: > > > http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpcc.html#wp1067175 > > Would be interesting to lab... > > > On Tue, Aug 18, 2009 at 6:52 PM, Vikas Sharma <[email protected]> wrote: > >> Hi Adrian, >> >> Answers to your questions. >> >> 1. No, ISP is not running MPLS within this cloud. >> >> 2. No, it's just one ISP. >> >> 3. We have 2 sites with high speed dark fibre connectivity between them >> and this is the best path. There are multiple redundant paths between the >> core switches at each site. The ISP has its routers at each location that >> connect to the core switch. >> >> 4. No we won't be running BGP within the sites, only EIGRP. >> >> At each site are subnets, no 2 subnets span the other site so they are >> exclusive to that site only. >> >> The route map is configured to look at the access list for site A (HQ). >> This access list contains a list of networks within Site A. For routes that >> do not match the subnets in that access list we set tag to 300. This route >> map is then applied and the ISPs router sees only specific routes that have >> a tag of 300 on them and other routes with no tags. The same thing is done >> on Site B where the route map looks at an acl which contains networks only >> at Site B and does nothing. But the 2nd statement sets tag to 200, meaning >> all routes other than those specified in the acl are to be tagged as 200. >> >> What we want is for the ISP to match tag 300 and then make it more >> expensive within their BGP cloud. The ISP redistributes EIGRP to BGP. Hence >> the question, when redistributing from one protocol to another, are the tags >> maintained or lost? >> >> The purpose of this exercies is that if remote sites want to access a >> subnet at Site B they are correctly routed to the ISPs router at Site B and >> do not go via their router at Site A and then via the dark fibre. This is >> what we would like to achieve. >> >> Regards, >> >> Vikas. >> >> On Wed, Aug 19, 2009 at 10:25 AM, Adrian Brayton <[email protected]>wrote: >> >>> Thats a loaded question without enough detail... >>> >>> 1. Is the SP running MPLS where your EIGRP route's are added to a VRF? >>> >>> 2. Do you have multiple ISPs that you connect to? >>> >>> 3. Why do you want to make those routes more expensive in there cloud? >>> >>> 4. Are you running or going to be running BGP? >>> >>> Just a few more details would sure make answering this question a little >>> easier!! >>> >>> >>> >>> On Aug 18, 2009, at 7:18 PM, Vikas Sharma wrote: >>> >>> Hi Everyone, >>>> >>>> I need some help regarding redistribution of tagged routes. Issue is as >>>> follows. >>>> >>>> I have a core switch on which is configured EIGRP. The ISP's router >>>> connects into the core switch also runs EIGRP. The ISP in turn runs BGP >>>> within their cloud. >>>> >>>> I have a distribute list on my core switch that sets a tag of 300 for >>>> routes going towards the ISP router. That is fine and the ISP's router can >>>> see them. >>>> >>>> The question I have is when they redistribute EIGRP into BGP are the >>>> tags maintained? I want them to apply a route-map to match tag 300 and then >>>> use the as-prepend command within the route-map to make those routes more >>>> expensive within their cloud. The route-map then gets applied in the >>>> outbound direction from within the router bgp (AS-Number). >>>> >>>> I would like to think there is no need to apply the route map in the >>>> EIGRP config on the ISP router. Rather, first they redistribute EIGRP into >>>> BGP and then apply this route-map in BGP. Please advice. >>>> >>>> Regards, >>>> >>>> -- >>>> Vikas Sharma >>>> Network Specialist >>>> Fujitsu Australia >>>> (M): 0421 052 117 >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, >>>> please visit www.ipexpert.com >>>> >>> >>> >> >> >> -- >> Vikas Sharma >> Network Specialist >> Fujitsu Australia >> (M): 0421 052 117 >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> > > > -- > Bryan Bartik > CCIE #23707 (R&S), CCNP > Sr. Support Engineer - IPexpert, Inc. > URL: http://www.IPexpert.com > -- Vikas Sharma Network Specialist Fujitsu Australia (M): 0421 052 117
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
