| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
 |
| Thread Tools |
|
Gary
Guest
Posts: n/a
|
"Yandy Ramirez" <> wrote in message news:C3E30B8C.8587%... > Simple, > > Policy based routing. Set ip next-hop. > This is done in conjuction with standard or extended acls and route-maps. > > Sample. > > Access-list 3 permit 200.1.1.0 0.0.0.255 > > Route-map POLICY-ROUTE permit 100 > match ip address 3 > set Ip next-hop 200.1.2.2 > > Interface f0/0 > desc outside > ip add 200.1.2.1 255.255.255.0 > ! > Inteface f0/1 > desc inside > ip add 200.1.1.1 255.255.255.0 > ip policy route-map POLICY-ROUTE > ! > > > On 2/21/08 10:21 AM, in article 2Ggvj.529$, "Gary" > <> wrote: > >> >> "Yandy Ramirez" <> wrote in message >> news:C3E27CEB.84F4%... >>> One method is not really superior over the other. >>> First I will say ( the network command under bgp is for wusses.. Lol >>> j/k ) >>> The only reason that advertising a /24 out of your 2 sessions that you >>> want >>> and only advertising a /19 out of all of them including the 2 that >>> advertise >>> the /24, the only reason this is considered best practice is because you >>> cannot count on your providers trusting your MED values, maybe someone >>> complains and they change their local-pref higher out one of the other 4 >>> sessions, oops their goes your MED. >>> >>> MED is useful in certain situations but my recommendation stays as it >>> was. >>> >>> >>> With both /24 and /19 you have full routing and high availability should >>> something fail. >>> >>> Now as far as the arp goes, as long as your internal routing is properly >>> configured the incoming traffic should not affect your firewall from >>> arping >>> for the correct subnet (The internet is hardly symmetrical to begin >>> with). >>> >>> Hope that helps. >>> >>> >>> On 2/21/08 12:32 AM, in article I18vj.3626$, "Gary" >>> <> wrote: >>> >>>> >>>> "Yandy Ramirez" <> wrote in message >>>> news:C3E24B4A.792A%... >>>>> One more thing, just make soure your transit provider opens up its >>>>> filter >>>>> and allows that /24 through. Should not be a big concern for them to >>>>> do >>>>> so. >>>>> >>>>> >>>>> On 2/20/08 8:41 PM, in article VE4vj.5556$, >>>>> "Gary" >>>>> <> wrote: >>>>> >>>>>> >>>>>> "Yandy Ramirez" <> wrote in message >>>>>> news:C3E12033.6CCE%... >>>>>>> Well having the customer with a separate x-connect and bgp sessions >>>>>>> directly >>>>>>> to the Transit providers should automatically have a shorter as-path >>>>>>> from >>>>>>> cust-to-provider. But the customer can set a higher local-pref on >>>>>>> the >>>>>>> routes >>>>>>> received from those two neighbors and a lower local-pref to the >>>>>>> prefixes >>>>>>> received from you. >>>>>>> >>>>>>> Now controlling inbound traffic is a bit trickier you can try >>>>>>> AS-PREPEND >>>>>>> (even though technically it should route automatically to his direct >>>>>>> connection) but that's beyond your control as the providers can set >>>>>>> LOCAL-PREF on their side and their goes that idea. So what you can >>>>>>> really >>>>>>> do >>>>>>> is. >>>>>>> >>>>>>> 1) BGP conditional advertisement (where you track a certain prefix) >>>>>>> maybe >>>>>>> a >>>>>>> loopback on the customer routers (2 in this case) and only advertise >>>>>>> the >>>>>>> customers prefixes to the providers through your link if and only if >>>>>>> both >>>>>>> loopbacks go down. That way the provider will really only see the >>>>>>> customers >>>>>>> prefixes through their link unless it goes down, then you start >>>>>>> advertising >>>>>>> The customers prefixes through your connection. >>>>>>> >>>>>>> cya >>>>>>> >>>>>>> >>>>>>> On 2/19/08 11:51 PM, in article >>>>>>> barmar-, "Barry >>>>>>> Margolin" >>>>>>> <> wrote: >>>>>>> >>>>>>>> In article <%6Luj.3489$>, >>>>>>>> "Gary" <> wrote: >>>>>>>> >>>>>>>>> We have a router connected to 2 x tier1 provider routers over a >>>>>>>>> single >>>>>>>>> x-connect and we run BGP to them no problems. We have taken on a >>>>>>>>> new >>>>>>>>> client >>>>>>>>> that wants their own dedicated cable and BGP session to the same 2 >>>>>>>>> routers >>>>>>>>> and a second x-connect is now in and 2 new BGP sessions are up to >>>>>>>>> what >>>>>>>>> are >>>>>>>>> actually the same tier1 routers. >>>>>>>>> >>>>>>>>> The client wants his address space routed over his cable to the >>>>>>>>> tier1 >>>>>>>>> provider unless that cable fails in which case the traffic should >>>>>>>>> failover >>>>>>>>> to our x-connect to the tier1 provider. >>>>>>>>> >>>>>>>>> The question is how do I get the customers traffic to ONLY leave >>>>>>>>> via >>>>>>>>> his >>>>>>>>> x-connect cable/BGP sessions while it is up but failover to ours >>>>>>>>> if >>>>>>>>> his >>>>>>>>> fails. Also how do I get the inbound traffic to ONLY come down one >>>>>>>>> set >>>>>>>>> of >>>>>>>>> BGP sessions (the clients) as opposed to our BGP sessions while >>>>>>>>> his >>>>>>>>> are >>>>>>>>> up. >>>>>>>> >>>>>>>> This should happen automatically. The routes through your >>>>>>>> x-connect >>>>>>>> should have your ASN in the AS path, which will make it longer than >>>>>>>> the >>>>>>>> routes directly to the tier1 providers. >>>>>>>> >>>>>>>>> >>>>>>>>> An ASCI Diagram would look like >>>>>>>>> >>>>>>>>> >>>>>>>>> Our Router A x------------our x-connect------------------------x >>>>>>>>> Tier1 >>>>>>>>> Router A & B - This carries to BGP sessions on a small subnet >>>>>>>>> which >>>>>>>>> we >>>>>>>>> use >>>>>>>>> for clients to transit generally >>>>>>>>> Our Router A x------------client x-connect----------------------x >>>>>>>>> Tier >>>>>>>>> 1 >>>>>>>>> Router A & B- This should only carry client subnet in and out >>>>>>>>> while >>>>>>>>> up >>>>>>>>> otherwise failover to our cable and BGP sessions >>>>>>>>> >>>>>>>>> Both cables carry 2 BGP peering sessions receivong full routing >>>>>>>>> tables >>>>>>>>> with >>>>>>>>> both Tier1 Router A and B so in total we now gave 4 full routing >>>>>>>>> tables >>>>>>>>> form >>>>>>>>> the same Tier1 provider on Our Router A. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hope this makes sense. >>>>>>>>> Thanks >>>>>>>>> Gary >>>>>>> >>>>>>> >>>>>> >>>>>> Maybee I explained this badly. We have 6 full BGP peering sessions to >>>>>> the >>>>>> same TIER1 Provider to different routers. We announce a /19 on all >>>>>> sessions >>>>>> and all works well. Now we want a particular /24 within that /19 to >>>>>> only >>>>>> come down 2 of the BGP Peering sessions. Should these 2 fail for any >>>>>> reason >>>>>> (cable break) we want the /24 to come in any of the remaining 4 BGP >>>>>> sessions. >>>>>> >>>>>> Hope that calrifies? >>>>>> Gary >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> Thanks. I will test that. I did try MED's and that seems ot have >>>> worked. >>>> When we check the advertised routes on the upstream provider the /24 >>>> has >>>> a >>>> Metric of zero for the preferred BGP session and all other sessions on >>>> the >>>> upstream are 50 which is the MED we applied and inbound routing looks >>>> good. >>>> It does come through the correct upstream router AND BGP session to us. >>>> >>>> Is your method superior - Why? >>>> >>>> Also how do I ensure that the locally connected /24 (A Cisco ASA5500 >>>> will >>>> arp the whole /24) only routes out through the same BGP session. 99.99% >>>> of >>>> traffic will be inbound and I assume will depart the way it came, but >>>> what >>>> about sessions initiated inside the firewall within the /24. I need to >>>> force >>>> that traffic to only go out one of the BGP sessions but failover should >>>> that >>>> BGP session fail. >>>> >>>> Thanks >>>> Gary >>>> >>>> >>> >>> >> I have confused this again. Only the /24 should use this dedicated >> peering >> to the upstream. That includes inbound and outbound traffic. I think now >> all >> sessions initiated externally will come doen the right connection so it >> can >> be easily metered and charged, but what about outbound connections from >> the >> /24. How do I force them to ONLY use a particular peering while is is up. >> >> It is almost like I want to VLAN then to a BGP session. >> Gary >> >> > Thanks. Would it simply be the same as setting the D/Gateway of the firewall protecting the /24 to the upstreams BGP session and a lower D/Gateway to the standby routers? Maybe I made this too complex. Would this do the same as the Policy Based Routing and leave less for the router to do? Gary |
|
|
|
|
|||
|
|||
| Gary |
|
|
|
| |
|
Yandy Ramirez
Guest
Posts: n/a
|
If your firewall lets you do that, then yes!
That's simpler cya On 2/21/08 6:58 PM, in article Qeovj.2682$, "Gary" <> wrote: > > "Yandy Ramirez" <> wrote in message > news:C3E30B8C.8587%... >> Simple, >> >> Policy based routing. Set ip next-hop. >> This is done in conjuction with standard or extended acls and route-maps. >> >> Sample. >> >> Access-list 3 permit 200.1.1.0 0.0.0.255 >> >> Route-map POLICY-ROUTE permit 100 >> match ip address 3 >> set Ip next-hop 200.1.2.2 >> >> Interface f0/0 >> desc outside >> ip add 200.1.2.1 255.255.255.0 >> ! >> Inteface f0/1 >> desc inside >> ip add 200.1.1.1 255.255.255.0 >> ip policy route-map POLICY-ROUTE >> ! >> >> >> On 2/21/08 10:21 AM, in article 2Ggvj.529$, "Gary" >> <> wrote: >> >>> >>> "Yandy Ramirez" <> wrote in message >>> news:C3E27CEB.84F4%... >>>> One method is not really superior over the other. >>>> First I will say ( the network command under bgp is for wusses.. Lol >>>> j/k ) >>>> The only reason that advertising a /24 out of your 2 sessions that you >>>> want >>>> and only advertising a /19 out of all of them including the 2 that >>>> advertise >>>> the /24, the only reason this is considered best practice is because you >>>> cannot count on your providers trusting your MED values, maybe someone >>>> complains and they change their local-pref higher out one of the other 4 >>>> sessions, oops their goes your MED. >>>> >>>> MED is useful in certain situations but my recommendation stays as it >>>> was. >>>> >>>> >>>> With both /24 and /19 you have full routing and high availability should >>>> something fail. >>>> >>>> Now as far as the arp goes, as long as your internal routing is properly >>>> configured the incoming traffic should not affect your firewall from >>>> arping >>>> for the correct subnet (The internet is hardly symmetrical to begin >>>> with). >>>> >>>> Hope that helps. >>>> >>>> >>>> On 2/21/08 12:32 AM, in article I18vj.3626$, "Gary" >>>> <> wrote: >>>> >>>>> >>>>> "Yandy Ramirez" <> wrote in message >>>>> news:C3E24B4A.792A%... >>>>>> One more thing, just make soure your transit provider opens up its >>>>>> filter >>>>>> and allows that /24 through. Should not be a big concern for them to >>>>>> do >>>>>> so. >>>>>> >>>>>> >>>>>> On 2/20/08 8:41 PM, in article VE4vj.5556$, >>>>>> "Gary" >>>>>> <> wrote: >>>>>> >>>>>>> >>>>>>> "Yandy Ramirez" <> wrote in message >>>>>>> news:C3E12033.6CCE%... >>>>>>>> Well having the customer with a separate x-connect and bgp sessions >>>>>>>> directly >>>>>>>> to the Transit providers should automatically have a shorter as-path >>>>>>>> from >>>>>>>> cust-to-provider. But the customer can set a higher local-pref on >>>>>>>> the >>>>>>>> routes >>>>>>>> received from those two neighbors and a lower local-pref to the >>>>>>>> prefixes >>>>>>>> received from you. >>>>>>>> >>>>>>>> Now controlling inbound traffic is a bit trickier you can try >>>>>>>> AS-PREPEND >>>>>>>> (even though technically it should route automatically to his direct >>>>>>>> connection) but that's beyond your control as the providers can set >>>>>>>> LOCAL-PREF on their side and their goes that idea. So what you can >>>>>>>> really >>>>>>>> do >>>>>>>> is. >>>>>>>> >>>>>>>> 1) BGP conditional advertisement (where you track a certain prefix) >>>>>>>> maybe >>>>>>>> a >>>>>>>> loopback on the customer routers (2 in this case) and only advertise >>>>>>>> the >>>>>>>> customers prefixes to the providers through your link if and only if >>>>>>>> both >>>>>>>> loopbacks go down. That way the provider will really only see the >>>>>>>> customers >>>>>>>> prefixes through their link unless it goes down, then you start >>>>>>>> advertising >>>>>>>> The customers prefixes through your connection. >>>>>>>> >>>>>>>> cya >>>>>>>> >>>>>>>> >>>>>>>> On 2/19/08 11:51 PM, in article >>>>>>>> barmar-, "Barry >>>>>>>> Margolin" >>>>>>>> <> wrote: >>>>>>>> >>>>>>>>> In article <%6Luj.3489$>, >>>>>>>>> "Gary" <> wrote: >>>>>>>>> >>>>>>>>>> We have a router connected to 2 x tier1 provider routers over a >>>>>>>>>> single >>>>>>>>>> x-connect and we run BGP to them no problems. We have taken on a >>>>>>>>>> new >>>>>>>>>> client >>>>>>>>>> that wants their own dedicated cable and BGP session to the same 2 >>>>>>>>>> routers >>>>>>>>>> and a second x-connect is now in and 2 new BGP sessions are up to >>>>>>>>>> what >>>>>>>>>> are >>>>>>>>>> actually the same tier1 routers. >>>>>>>>>> >>>>>>>>>> The client wants his address space routed over his cable to the >>>>>>>>>> tier1 >>>>>>>>>> provider unless that cable fails in which case the traffic should >>>>>>>>>> failover >>>>>>>>>> to our x-connect to the tier1 provider. >>>>>>>>>> >>>>>>>>>> The question is how do I get the customers traffic to ONLY leave >>>>>>>>>> via >>>>>>>>>> his >>>>>>>>>> x-connect cable/BGP sessions while it is up but failover to ours >>>>>>>>>> if >>>>>>>>>> his >>>>>>>>>> fails. Also how do I get the inbound traffic to ONLY come down one >>>>>>>>>> set >>>>>>>>>> of >>>>>>>>>> BGP sessions (the clients) as opposed to our BGP sessions while >>>>>>>>>> his >>>>>>>>>> are >>>>>>>>>> up. >>>>>>>>> >>>>>>>>> This should happen automatically. The routes through your >>>>>>>>> x-connect >>>>>>>>> should have your ASN in the AS path, which will make it longer than >>>>>>>>> the >>>>>>>>> routes directly to the tier1 providers. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> An ASCI Diagram would look like >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Our Router A x------------our x-connect------------------------x >>>>>>>>>> Tier1 >>>>>>>>>> Router A & B - This carries to BGP sessions on a small subnet >>>>>>>>>> which >>>>>>>>>> we >>>>>>>>>> use >>>>>>>>>> for clients to transit generally >>>>>>>>>> Our Router A x------------client x-connect----------------------x >>>>>>>>>> Tier >>>>>>>>>> 1 >>>>>>>>>> Router A & B- This should only carry client subnet in and out >>>>>>>>>> while >>>>>>>>>> up >>>>>>>>>> otherwise failover to our cable and BGP sessions >>>>>>>>>> >>>>>>>>>> Both cables carry 2 BGP peering sessions receivong full routing >>>>>>>>>> tables >>>>>>>>>> with >>>>>>>>>> both Tier1 Router A and B so in total we now gave 4 full routing >>>>>>>>>> tables >>>>>>>>>> form >>>>>>>>>> the same Tier1 provider on Our Router A. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hope this makes sense. >>>>>>>>>> Thanks >>>>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Maybee I explained this badly. We have 6 full BGP peering sessions to >>>>>>> the >>>>>>> same TIER1 Provider to different routers. We announce a /19 on all >>>>>>> sessions >>>>>>> and all works well. Now we want a particular /24 within that /19 to >>>>>>> only >>>>>>> come down 2 of the BGP Peering sessions. Should these 2 fail for any >>>>>>> reason >>>>>>> (cable break) we want the /24 to come in any of the remaining 4 BGP >>>>>>> sessions. >>>>>>> >>>>>>> Hope that calrifies? >>>>>>> Gary >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> Thanks. I will test that. I did try MED's and that seems ot have >>>>> worked. >>>>> When we check the advertised routes on the upstream provider the /24 >>>>> has >>>>> a >>>>> Metric of zero for the preferred BGP session and all other sessions on >>>>> the >>>>> upstream are 50 which is the MED we applied and inbound routing looks >>>>> good. >>>>> It does come through the correct upstream router AND BGP session to us. >>>>> >>>>> Is your method superior - Why? >>>>> >>>>> Also how do I ensure that the locally connected /24 (A Cisco ASA5500 >>>>> will >>>>> arp the whole /24) only routes out through the same BGP session. 99.99% >>>>> of >>>>> traffic will be inbound and I assume will depart the way it came, but >>>>> what >>>>> about sessions initiated inside the firewall within the /24. I need to >>>>> force >>>>> that traffic to only go out one of the BGP sessions but failover should >>>>> that >>>>> BGP session fail. >>>>> >>>>> Thanks >>>>> Gary >>>>> >>>>> >>>> >>>> >>> I have confused this again. Only the /24 should use this dedicated >>> peering >>> to the upstream. That includes inbound and outbound traffic. I think now >>> all >>> sessions initiated externally will come doen the right connection so it >>> can >>> be easily metered and charged, but what about outbound connections from >>> the >>> /24. How do I force them to ONLY use a particular peering while is is up. >>> >>> It is almost like I want to VLAN then to a BGP session. >>> Gary >>> >>> >> > > Thanks. Would it simply be the same as setting the D/Gateway of the firewall > protecting the /24 to the upstreams BGP session and a lower D/Gateway to the > standby routers? > > Maybe I made this too complex. Would this do the same as the Policy Based > Routing and leave less for the router to do? > > Gary > > |
|
|
|
|
|||
|
|
|||
| Yandy Ramirez |
|
|
|
| |
|
Yandy Ramirez
Guest
Posts: n/a
|
I guess I understood you wrong, I thought you wanted to route traffic to
that one specific session from a /24 not to a /24. On 2/21/08 6:58 PM, in article Qeovj.2682$, "Gary" <> wrote: > > "Yandy Ramirez" <> wrote in message > news:C3E30B8C.8587%... >> Simple, >> >> Policy based routing. Set ip next-hop. >> This is done in conjuction with standard or extended acls and route-maps. >> >> Sample. >> >> Access-list 3 permit 200.1.1.0 0.0.0.255 >> >> Route-map POLICY-ROUTE permit 100 >> match ip address 3 >> set Ip next-hop 200.1.2.2 >> >> Interface f0/0 >> desc outside >> ip add 200.1.2.1 255.255.255.0 >> ! >> Inteface f0/1 >> desc inside >> ip add 200.1.1.1 255.255.255.0 >> ip policy route-map POLICY-ROUTE >> ! >> >> >> On 2/21/08 10:21 AM, in article 2Ggvj.529$, "Gary" >> <> wrote: >> >>> >>> "Yandy Ramirez" <> wrote in message >>> news:C3E27CEB.84F4%... >>>> One method is not really superior over the other. >>>> First I will say ( the network command under bgp is for wusses.. Lol >>>> j/k ) >>>> The only reason that advertising a /24 out of your 2 sessions that you >>>> want >>>> and only advertising a /19 out of all of them including the 2 that >>>> advertise >>>> the /24, the only reason this is considered best practice is because you >>>> cannot count on your providers trusting your MED values, maybe someone >>>> complains and they change their local-pref higher out one of the other 4 >>>> sessions, oops their goes your MED. >>>> >>>> MED is useful in certain situations but my recommendation stays as it >>>> was. >>>> >>>> >>>> With both /24 and /19 you have full routing and high availability should >>>> something fail. >>>> >>>> Now as far as the arp goes, as long as your internal routing is properly >>>> configured the incoming traffic should not affect your firewall from >>>> arping >>>> for the correct subnet (The internet is hardly symmetrical to begin >>>> with). >>>> >>>> Hope that helps. >>>> >>>> >>>> On 2/21/08 12:32 AM, in article I18vj.3626$, "Gary" >>>> <> wrote: >>>> >>>>> >>>>> "Yandy Ramirez" <> wrote in message >>>>> news:C3E24B4A.792A%... >>>>>> One more thing, just make soure your transit provider opens up its >>>>>> filter >>>>>> and allows that /24 through. Should not be a big concern for them to >>>>>> do >>>>>> so. >>>>>> >>>>>> >>>>>> On 2/20/08 8:41 PM, in article VE4vj.5556$, >>>>>> "Gary" >>>>>> <> wrote: >>>>>> >>>>>>> >>>>>>> "Yandy Ramirez" <> wrote in message >>>>>>> news:C3E12033.6CCE%... >>>>>>>> Well having the customer with a separate x-connect and bgp sessions >>>>>>>> directly >>>>>>>> to the Transit providers should automatically have a shorter as-path >>>>>>>> from >>>>>>>> cust-to-provider. But the customer can set a higher local-pref on >>>>>>>> the >>>>>>>> routes >>>>>>>> received from those two neighbors and a lower local-pref to the >>>>>>>> prefixes >>>>>>>> received from you. >>>>>>>> >>>>>>>> Now controlling inbound traffic is a bit trickier you can try >>>>>>>> AS-PREPEND >>>>>>>> (even though technically it should route automatically to his direct >>>>>>>> connection) but that's beyond your control as the providers can set >>>>>>>> LOCAL-PREF on their side and their goes that idea. So what you can >>>>>>>> really >>>>>>>> do >>>>>>>> is. >>>>>>>> >>>>>>>> 1) BGP conditional advertisement (where you track a certain prefix) >>>>>>>> maybe >>>>>>>> a >>>>>>>> loopback on the customer routers (2 in this case) and only advertise >>>>>>>> the >>>>>>>> customers prefixes to the providers through your link if and only if >>>>>>>> both >>>>>>>> loopbacks go down. That way the provider will really only see the >>>>>>>> customers >>>>>>>> prefixes through their link unless it goes down, then you start >>>>>>>> advertising >>>>>>>> The customers prefixes through your connection. >>>>>>>> >>>>>>>> cya >>>>>>>> >>>>>>>> >>>>>>>> On 2/19/08 11:51 PM, in article >>>>>>>> barmar-, "Barry >>>>>>>> Margolin" >>>>>>>> <> wrote: >>>>>>>> >>>>>>>>> In article <%6Luj.3489$>, >>>>>>>>> "Gary" <> wrote: >>>>>>>>> >>>>>>>>>> We have a router connected to 2 x tier1 provider routers over a >>>>>>>>>> single >>>>>>>>>> x-connect and we run BGP to them no problems. We have taken on a >>>>>>>>>> new >>>>>>>>>> client >>>>>>>>>> that wants their own dedicated cable and BGP session to the same 2 >>>>>>>>>> routers >>>>>>>>>> and a second x-connect is now in and 2 new BGP sessions are up to >>>>>>>>>> what >>>>>>>>>> are >>>>>>>>>> actually the same tier1 routers. >>>>>>>>>> >>>>>>>>>> The client wants his address space routed over his cable to the >>>>>>>>>> tier1 >>>>>>>>>> provider unless that cable fails in which case the traffic should >>>>>>>>>> failover >>>>>>>>>> to our x-connect to the tier1 provider. >>>>>>>>>> >>>>>>>>>> The question is how do I get the customers traffic to ONLY leave >>>>>>>>>> via >>>>>>>>>> his >>>>>>>>>> x-connect cable/BGP sessions while it is up but failover to ours >>>>>>>>>> if >>>>>>>>>> his >>>>>>>>>> fails. Also how do I get the inbound traffic to ONLY come down one >>>>>>>>>> set >>>>>>>>>> of >>>>>>>>>> BGP sessions (the clients) as opposed to our BGP sessions while >>>>>>>>>> his >>>>>>>>>> are >>>>>>>>>> up. >>>>>>>>> >>>>>>>>> This should happen automatically. The routes through your >>>>>>>>> x-connect >>>>>>>>> should have your ASN in the AS path, which will make it longer than >>>>>>>>> the >>>>>>>>> routes directly to the tier1 providers. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> An ASCI Diagram would look like >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Our Router A x------------our x-connect------------------------x >>>>>>>>>> Tier1 >>>>>>>>>> Router A & B - This carries to BGP sessions on a small subnet >>>>>>>>>> which >>>>>>>>>> we >>>>>>>>>> use >>>>>>>>>> for clients to transit generally >>>>>>>>>> Our Router A x------------client x-connect----------------------x >>>>>>>>>> Tier >>>>>>>>>> 1 >>>>>>>>>> Router A & B- This should only carry client subnet in and out >>>>>>>>>> while >>>>>>>>>> up >>>>>>>>>> otherwise failover to our cable and BGP sessions >>>>>>>>>> >>>>>>>>>> Both cables carry 2 BGP peering sessions receivong full routing >>>>>>>>>> tables >>>>>>>>>> with >>>>>>>>>> both Tier1 Router A and B so in total we now gave 4 full routing >>>>>>>>>> tables >>>>>>>>>> form >>>>>>>>>> the same Tier1 provider on Our Router A. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hope this makes sense. >>>>>>>>>> Thanks >>>>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Maybee I explained this badly. We have 6 full BGP peering sessions to >>>>>>> the >>>>>>> same TIER1 Provider to different routers. We announce a /19 on all >>>>>>> sessions >>>>>>> and all works well. Now we want a particular /24 within that /19 to >>>>>>> only >>>>>>> come down 2 of the BGP Peering sessions. Should these 2 fail for any >>>>>>> reason >>>>>>> (cable break) we want the /24 to come in any of the remaining 4 BGP >>>>>>> sessions. >>>>>>> >>>>>>> Hope that calrifies? >>>>>>> Gary >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> Thanks. I will test that. I did try MED's and that seems ot have >>>>> worked. >>>>> When we check the advertised routes on the upstream provider the /24 >>>>> has >>>>> a >>>>> Metric of zero for the preferred BGP session and all other sessions on >>>>> the >>>>> upstream are 50 which is the MED we applied and inbound routing looks >>>>> good. >>>>> It does come through the correct upstream router AND BGP session to us. >>>>> >>>>> Is your method superior - Why? >>>>> >>>>> Also how do I ensure that the locally connected /24 (A Cisco ASA5500 >>>>> will >>>>> arp the whole /24) only routes out through the same BGP session. 99.99% >>>>> of >>>>> traffic will be inbound and I assume will depart the way it came, but >>>>> what >>>>> about sessions initiated inside the firewall within the /24. I need to >>>>> force >>>>> that traffic to only go out one of the BGP sessions but failover should >>>>> that >>>>> BGP session fail. >>>>> >>>>> Thanks >>>>> Gary >>>>> >>>>> >>>> >>>> >>> I have confused this again. Only the /24 should use this dedicated >>> peering >>> to the upstream. That includes inbound and outbound traffic. I think now >>> all >>> sessions initiated externally will come doen the right connection so it >>> can >>> be easily metered and charged, but what about outbound connections from >>> the >>> /24. How do I force them to ONLY use a particular peering while is is up. >>> >>> It is almost like I want to VLAN then to a BGP session. >>> Gary >>> >>> >> > > Thanks. Would it simply be the same as setting the D/Gateway of the firewall > protecting the /24 to the upstreams BGP session and a lower D/Gateway to the > standby routers? > > Maybe I made this too complex. Would this do the same as the Policy Based > Routing and leave less for the router to do? > > Gary > > |
|
|
|
|
|||
|
|
|||
| Yandy Ramirez |
|
Gary
Guest
Posts: n/a
|
I want inbound traffic to one /24 to only come down one BGP session and
MED's seem to do that plus I want traffic outbound from the /24 to use the same BGP session. Almost like a /24 on a stick with the upstream. Thx Gary "Yandy Ramirez" <> wrote in message news:C3E38C6A.85D9%... >I guess I understood you wrong, I thought you wanted to route traffic to > that one specific session from a /24 not to a /24. > > > On 2/21/08 6:58 PM, in article Qeovj.2682$, "Gary" > <> wrote: > >> >> "Yandy Ramirez" <> wrote in message >> news:C3E30B8C.8587%... >>> Simple, >>> >>> Policy based routing. Set ip next-hop. >>> This is done in conjuction with standard or extended acls and >>> route-maps. >>> >>> Sample. >>> >>> Access-list 3 permit 200.1.1.0 0.0.0.255 >>> >>> Route-map POLICY-ROUTE permit 100 >>> match ip address 3 >>> set Ip next-hop 200.1.2.2 >>> >>> Interface f0/0 >>> desc outside >>> ip add 200.1.2.1 255.255.255.0 >>> ! >>> Inteface f0/1 >>> desc inside >>> ip add 200.1.1.1 255.255.255.0 >>> ip policy route-map POLICY-ROUTE >>> ! >>> >>> >>> On 2/21/08 10:21 AM, in article 2Ggvj.529$, "Gary" >>> <> wrote: >>> >>>> >>>> "Yandy Ramirez" <> wrote in message >>>> news:C3E27CEB.84F4%... >>>>> One method is not really superior over the other. >>>>> First I will say ( the network command under bgp is for wusses.. Lol >>>>> j/k ) >>>>> The only reason that advertising a /24 out of your 2 sessions that you >>>>> want >>>>> and only advertising a /19 out of all of them including the 2 that >>>>> advertise >>>>> the /24, the only reason this is considered best practice is because >>>>> you >>>>> cannot count on your providers trusting your MED values, maybe someone >>>>> complains and they change their local-pref higher out one of the other >>>>> 4 >>>>> sessions, oops their goes your MED. >>>>> >>>>> MED is useful in certain situations but my recommendation stays as it >>>>> was. >>>>> >>>>> >>>>> With both /24 and /19 you have full routing and high availability >>>>> should >>>>> something fail. >>>>> >>>>> Now as far as the arp goes, as long as your internal routing is >>>>> properly >>>>> configured the incoming traffic should not affect your firewall from >>>>> arping >>>>> for the correct subnet (The internet is hardly symmetrical to begin >>>>> with). >>>>> >>>>> Hope that helps. >>>>> >>>>> >>>>> On 2/21/08 12:32 AM, in article I18vj.3626$, >>>>> "Gary" >>>>> <> wrote: >>>>> >>>>>> >>>>>> "Yandy Ramirez" <> wrote in message >>>>>> news:C3E24B4A.792A%... >>>>>>> One more thing, just make soure your transit provider opens up its >>>>>>> filter >>>>>>> and allows that /24 through. Should not be a big concern for them to >>>>>>> do >>>>>>> so. >>>>>>> >>>>>>> >>>>>>> On 2/20/08 8:41 PM, in article VE4vj.5556$, >>>>>>> "Gary" >>>>>>> <> wrote: >>>>>>> >>>>>>>> >>>>>>>> "Yandy Ramirez" <> wrote in message >>>>>>>> news:C3E12033.6CCE%... >>>>>>>>> Well having the customer with a separate x-connect and bgp >>>>>>>>> sessions >>>>>>>>> directly >>>>>>>>> to the Transit providers should automatically have a shorter >>>>>>>>> as-path >>>>>>>>> from >>>>>>>>> cust-to-provider. But the customer can set a higher local-pref on >>>>>>>>> the >>>>>>>>> routes >>>>>>>>> received from those two neighbors and a lower local-pref to the >>>>>>>>> prefixes >>>>>>>>> received from you. >>>>>>>>> >>>>>>>>> Now controlling inbound traffic is a bit trickier you can try >>>>>>>>> AS-PREPEND >>>>>>>>> (even though technically it should route automatically to his >>>>>>>>> direct >>>>>>>>> connection) but that's beyond your control as the providers can >>>>>>>>> set >>>>>>>>> LOCAL-PREF on their side and their goes that idea. So what you can >>>>>>>>> really >>>>>>>>> do >>>>>>>>> is. >>>>>>>>> >>>>>>>>> 1) BGP conditional advertisement (where you track a certain >>>>>>>>> prefix) >>>>>>>>> maybe >>>>>>>>> a >>>>>>>>> loopback on the customer routers (2 in this case) and only >>>>>>>>> advertise >>>>>>>>> the >>>>>>>>> customers prefixes to the providers through your link if and only >>>>>>>>> if >>>>>>>>> both >>>>>>>>> loopbacks go down. That way the provider will really only see the >>>>>>>>> customers >>>>>>>>> prefixes through their link unless it goes down, then you start >>>>>>>>> advertising >>>>>>>>> The customers prefixes through your connection. >>>>>>>>> >>>>>>>>> cya >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/19/08 11:51 PM, in article >>>>>>>>> barmar-, "Barry >>>>>>>>> Margolin" >>>>>>>>> <> wrote: >>>>>>>>> >>>>>>>>>> In article <%6Luj.3489$>, >>>>>>>>>> "Gary" <> wrote: >>>>>>>>>> >>>>>>>>>>> We have a router connected to 2 x tier1 provider routers over a >>>>>>>>>>> single >>>>>>>>>>> x-connect and we run BGP to them no problems. We have taken on a >>>>>>>>>>> new >>>>>>>>>>> client >>>>>>>>>>> that wants their own dedicated cable and BGP session to the same >>>>>>>>>>> 2 >>>>>>>>>>> routers >>>>>>>>>>> and a second x-connect is now in and 2 new BGP sessions are up >>>>>>>>>>> to >>>>>>>>>>> what >>>>>>>>>>> are >>>>>>>>>>> actually the same tier1 routers. >>>>>>>>>>> >>>>>>>>>>> The client wants his address space routed over his cable to the >>>>>>>>>>> tier1 >>>>>>>>>>> provider unless that cable fails in which case the traffic >>>>>>>>>>> should >>>>>>>>>>> failover >>>>>>>>>>> to our x-connect to the tier1 provider. >>>>>>>>>>> >>>>>>>>>>> The question is how do I get the customers traffic to ONLY leave >>>>>>>>>>> via >>>>>>>>>>> his >>>>>>>>>>> x-connect cable/BGP sessions while it is up but failover to ours >>>>>>>>>>> if >>>>>>>>>>> his >>>>>>>>>>> fails. Also how do I get the inbound traffic to ONLY come down >>>>>>>>>>> one >>>>>>>>>>> set >>>>>>>>>>> of >>>>>>>>>>> BGP sessions (the clients) as opposed to our BGP sessions while >>>>>>>>>>> his >>>>>>>>>>> are >>>>>>>>>>> up. >>>>>>>>>> >>>>>>>>>> This should happen automatically. The routes through your >>>>>>>>>> x-connect >>>>>>>>>> should have your ASN in the AS path, which will make it longer >>>>>>>>>> than >>>>>>>>>> the >>>>>>>>>> routes directly to the tier1 providers. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> An ASCI Diagram would look like >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Our Router A x------------our x-connect------------------------x >>>>>>>>>>> Tier1 >>>>>>>>>>> Router A & B - This carries to BGP sessions on a small subnet >>>>>>>>>>> which >>>>>>>>>>> we >>>>>>>>>>> use >>>>>>>>>>> for clients to transit generally >>>>>>>>>>> Our Router A x------------client >>>>>>>>>>> x-connect----------------------x >>>>>>>>>>> Tier >>>>>>>>>>> 1 >>>>>>>>>>> Router A & B- This should only carry client subnet in and out >>>>>>>>>>> while >>>>>>>>>>> up >>>>>>>>>>> otherwise failover to our cable and BGP sessions >>>>>>>>>>> >>>>>>>>>>> Both cables carry 2 BGP peering sessions receivong full routing >>>>>>>>>>> tables >>>>>>>>>>> with >>>>>>>>>>> both Tier1 Router A and B so in total we now gave 4 full routing >>>>>>>>>>> tables >>>>>>>>>>> form >>>>>>>>>>> the same Tier1 provider on Our Router A. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hope this makes sense. >>>>>>>>>>> Thanks >>>>>>>>>>> Gary >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Maybee I explained this badly. We have 6 full BGP peering sessions >>>>>>>> to >>>>>>>> the >>>>>>>> same TIER1 Provider to different routers. We announce a /19 on all >>>>>>>> sessions >>>>>>>> and all works well. Now we want a particular /24 within that /19 to >>>>>>>> only >>>>>>>> come down 2 of the BGP Peering sessions. Should these 2 fail for >>>>>>>> any >>>>>>>> reason >>>>>>>> (cable break) we want the /24 to come in any of the remaining 4 BGP >>>>>>>> sessions. >>>>>>>> >>>>>>>> Hope that calrifies? >>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Thanks. I will test that. I did try MED's and that seems ot have >>>>>> worked. >>>>>> When we check the advertised routes on the upstream provider the /24 >>>>>> has >>>>>> a >>>>>> Metric of zero for the preferred BGP session and all other sessions >>>>>> on >>>>>> the >>>>>> upstream are 50 which is the MED we applied and inbound routing looks >>>>>> good. >>>>>> It does come through the correct upstream router AND BGP session to >>>>>> us. >>>>>> >>>>>> Is your method superior - Why? >>>>>> >>>>>> Also how do I ensure that the locally connected /24 (A Cisco ASA5500 >>>>>> will >>>>>> arp the whole /24) only routes out through the same BGP session. >>>>>> 99.99% >>>>>> of >>>>>> traffic will be inbound and I assume will depart the way it came, but >>>>>> what >>>>>> about sessions initiated inside the firewall within the /24. I need >>>>>> to >>>>>> force >>>>>> that traffic to only go out one of the BGP sessions but failover >>>>>> should >>>>>> that >>>>>> BGP session fail. >>>>>> >>>>>> Thanks >>>>>> Gary >>>>>> >>>>>> >>>>> >>>>> >>>> I have confused this again. Only the /24 should use this dedicated >>>> peering >>>> to the upstream. That includes inbound and outbound traffic. I think >>>> now >>>> all >>>> sessions initiated externally will come doen the right connection so it >>>> can >>>> be easily metered and charged, but what about outbound connections from >>>> the >>>> /24. How do I force them to ONLY use a particular peering while is is >>>> up. >>>> >>>> It is almost like I want to VLAN then to a BGP session. >>>> Gary >>>> >>>> >>> >> >> Thanks. Would it simply be the same as setting the D/Gateway of the >> firewall >> protecting the /24 to the upstreams BGP session and a lower D/Gateway to >> the >> standby routers? >> >> Maybe I made this too complex. Would this do the same as the Policy Based >> Routing and leave less for the router to do? >> >> Gary >> >> > |
|
|
|
|
|||
|
|
|||
| Gary |
|
|
|
| |
|
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| To BGP or not to BGP (multihoming with ISPs over uneven links speed)?!? | papi | Cisco | 4 | 09-08-2009 02:45 AM |
| Odd behavior with odd code | Michael Speer | C Programming | 33 | 02-18-2007 07:31 AM |
| Difference between "bgp dampening" and "bgp bestpath dampening" | harald rüger | Cisco | 0 | 10-25-2004 04:07 PM |
| OSPF & BGP interaction.. Tricky problem? or just stupid.. | Kris | Cisco | 2 | 06-20-2004 04:01 PM |
| BGP and NAT... interesting problem | Gollum | Cisco | 3 | 12-17-2003 06:22 PM |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc..
SEO by vBSEO ©2010, Crawlability, Inc. |
