Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > odd BGP Problem

Reply
Thread Tools

odd BGP Problem

 
 
Gary
Guest
Posts: n/a
 
      02-21-2008

"Yandy Ramirez" <(E-Mail Removed)> wrote in message
news:C3E30B8C.8587%(E-Mail Removed)...
> 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$(E-Mail Removed), "Gary"
> <(E-Mail Removed)> wrote:
>
>>
>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>> news:C3E27CEB.84F4%(E-Mail Removed)...
>>> 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$(E-Mail Removed), "Gary"
>>> <(E-Mail Removed)> wrote:
>>>
>>>>
>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>> news:C3E24B4A.792A%(E-Mail Removed)...
>>>>> 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$(E-Mail Removed),
>>>>> "Gary"
>>>>> <(E-Mail Removed)> wrote:
>>>>>
>>>>>>
>>>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>>>> news:C3E12033.6CCE%(E-Mail Removed)...
>>>>>>> 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
>>>>>>> http://www.velocityreviews.com/forums/(E-Mail Removed), "Barry
>>>>>>> Margolin"
>>>>>>> <(E-Mail Removed)> wrote:
>>>>>>>
>>>>>>>> In article <%6Luj.3489$(E-Mail Removed)>,
>>>>>>>> "Gary" <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
Yandy Ramirez
Guest
Posts: n/a
 
      02-22-2008
If your firewall lets you do that, then yes!
That's simpler

cya


On 2/21/08 6:58 PM, in article Qeovj.2682$(E-Mail Removed), "Gary"
<(E-Mail Removed)> wrote:

>
> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
> news:C3E30B8C.8587%(E-Mail Removed)...
>> 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$(E-Mail Removed), "Gary"
>> <(E-Mail Removed)> wrote:
>>
>>>
>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>> news:C3E27CEB.84F4%(E-Mail Removed)...
>>>> 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$(E-Mail Removed), "Gary"
>>>> <(E-Mail Removed)> wrote:
>>>>
>>>>>
>>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>>> news:C3E24B4A.792A%(E-Mail Removed)...
>>>>>> 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$(E-Mail Removed),
>>>>>> "Gary"
>>>>>> <(E-Mail Removed)> wrote:
>>>>>>
>>>>>>>
>>>>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>>>>> news:C3E12033.6CCE%(E-Mail Removed)...
>>>>>>>> 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
>>>>>>>> (E-Mail Removed), "Barry
>>>>>>>> Margolin"
>>>>>>>> <(E-Mail Removed)> wrote:
>>>>>>>>
>>>>>>>>> In article <%6Luj.3489$(E-Mail Removed)>,
>>>>>>>>> "Gary" <(E-Mail Removed)> 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
>
>


 
Reply With Quote
 
 
 
 
Yandy Ramirez
Guest
Posts: n/a
 
      02-22-2008
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$(E-Mail Removed), "Gary"
<(E-Mail Removed)> wrote:

>
> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
> news:C3E30B8C.8587%(E-Mail Removed)...
>> 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$(E-Mail Removed), "Gary"
>> <(E-Mail Removed)> wrote:
>>
>>>
>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>> news:C3E27CEB.84F4%(E-Mail Removed)...
>>>> 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$(E-Mail Removed), "Gary"
>>>> <(E-Mail Removed)> wrote:
>>>>
>>>>>
>>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>>> news:C3E24B4A.792A%(E-Mail Removed)...
>>>>>> 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$(E-Mail Removed),
>>>>>> "Gary"
>>>>>> <(E-Mail Removed)> wrote:
>>>>>>
>>>>>>>
>>>>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>>>>> news:C3E12033.6CCE%(E-Mail Removed)...
>>>>>>>> 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
>>>>>>>> (E-Mail Removed), "Barry
>>>>>>>> Margolin"
>>>>>>>> <(E-Mail Removed)> wrote:
>>>>>>>>
>>>>>>>>> In article <%6Luj.3489$(E-Mail Removed)>,
>>>>>>>>> "Gary" <(E-Mail Removed)> 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
>
>


 
Reply With Quote
 
Gary
Guest
Posts: n/a
 
      02-22-2008
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" <(E-Mail Removed)> wrote in message
news:C3E38C6A.85D9%(E-Mail Removed)...
>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$(E-Mail Removed), "Gary"
> <(E-Mail Removed)> wrote:
>
>>
>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>> news:C3E30B8C.8587%(E-Mail Removed)...
>>> 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$(E-Mail Removed), "Gary"
>>> <(E-Mail Removed)> wrote:
>>>
>>>>
>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>> news:C3E27CEB.84F4%(E-Mail Removed)...
>>>>> 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$(E-Mail Removed),
>>>>> "Gary"
>>>>> <(E-Mail Removed)> wrote:
>>>>>
>>>>>>
>>>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>>>> news:C3E24B4A.792A%(E-Mail Removed)...
>>>>>>> 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$(E-Mail Removed),
>>>>>>> "Gary"
>>>>>>> <(E-Mail Removed)> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> "Yandy Ramirez" <(E-Mail Removed)> wrote in message
>>>>>>>> news:C3E12033.6CCE%(E-Mail Removed)...
>>>>>>>>> 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
>>>>>>>>> (E-Mail Removed), "Barry
>>>>>>>>> Margolin"
>>>>>>>>> <(E-Mail Removed)> wrote:
>>>>>>>>>
>>>>>>>>>> In article <%6Luj.3489$(E-Mail Removed)>,
>>>>>>>>>> "Gary" <(E-Mail Removed)> 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
>>
>>

>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


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



Advertisments