BGP Challenge with traffic between VRFs

Answered Question
Jul 28th, 2010
User Badges:

We have a production network utilizing a couple of core switches running BGP AS 65000.  There are distributions switches running AS's 65001-65003 which each run VRFs (vrf-lite). The core switches do NOT run VRFs. There is address aggregation to limit the number of routes being sent to the core from each "block." These /12 aggregates (chunks of 10/8) are advertised from the core to all of the "blocks" so that they have more specific routes than just default. Each block has a 10/8 null route to keep it from forwarding traffic to the core which is destined for unkown 10.x addresses. All is working OK. Here is the problem:


In our lab, I am trying to mock up everything as much as possible because we have a lot of migrating to do as we move to this new network and I want to be able to thoroughly test each stage. Due to space and equipment restrictions,  I consolidated all of the 3 "blocks" into one. There is a 4th block (AS 65004) which mocks up the internet and generates the default, which is separate equipment. I have all of the VRFs and address families configured, separate fiber uplinks, etc.


But because one can only have 1 instance of BGP, all of the routes have to source from AS 65001. the core receives them fine. but of course, the VRFs don't see each other's routes because they are all from the same AS. But since we are currently employing those null routes, VRFs can't communicate with each other.


An ideal solution would be to somehow change the source AS being advertised. I'm expecting to be disappointed but is there any way to do this?


Another solution is to remove the null routes and move that function to the core, letting traffic follow the default there. This moves me another step further from the production configuration but maybe we could do that in production too.


Any thoughts? Is this clear as mud?

Correct Answer by milan.kulik about 6 years 10 months ago

Hi,


your topology is not clear, one diagram would say more than hundreds words.


Generally, you could use the neighbor x.x.x.x remove-private-as command on your core routers, see

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f27.shtml

Possibly with some sophisticated as-prepending or communities used to keep the info from which VRF the original prefix was sent?


Or you could use neighbor ip-address allowas-in [number]

(http://www.cisco.com/en/US/customer/docs/ios/12_2/switch/command/reference/xrfscmd4.html#wp1034011 )

command to permit the local as number within the incoming prefix attributes on your distribution routers.


Or neighbor as-override possibly?


Those commands are designed for PE routers, but might work in VRF-lite environment, too.


You should always be careful when using them and test in your lab before configuring your productive network.


HTH,

Milan

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
milan.kulik Thu, 07/29/2010 - 02:39
User Badges:
  • Red, 2250 points or more

Hi,


your topology is not clear, one diagram would say more than hundreds words.


Generally, you could use the neighbor x.x.x.x remove-private-as command on your core routers, see

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f27.shtml

Possibly with some sophisticated as-prepending or communities used to keep the info from which VRF the original prefix was sent?


Or you could use neighbor ip-address allowas-in [number]

(http://www.cisco.com/en/US/customer/docs/ios/12_2/switch/command/reference/xrfscmd4.html#wp1034011 )

command to permit the local as number within the incoming prefix attributes on your distribution routers.


Or neighbor as-override possibly?


Those commands are designed for PE routers, but might work in VRF-lite environment, too.


You should always be careful when using them and test in your lab before configuring your productive network.


HTH,

Milan

mbernhardt Wed, 08/04/2010 - 16:22
User Badges:

Actually, that was very helpful. As this is ALL private AS, I can't use remove-private-as. But what I can do is either as-prepend or local-as, combined with allowas-in and appropriate filtering with tags or community strings, to make it work. It's not perfect but it will do.


thanks!

milan.kulik Wed, 08/04/2010 - 22:52
User Badges:
  • Red, 2250 points or more

Hi,


I'm glad it helped.


Just to be precise:

remove-private-as requires all AS numbers in the AS-PATH to be private ones to work.

The trick is it is used when the prefix is sent out.

See http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080093f29.shtml for an example.

So my idea was to use  remove-private-as on the core router when the prefix is sent from the core to the distribution router.

And to prepend some other AS numbers using prepending (you don't have to prepend only the router's own AS number although all examples are showing just that.)


BR,

Milan

mbernhardt Thu, 08/05/2010 - 08:58
User Badges:

Thanks for clarification. That might work too- I was planning to set tags on routes going to the core to identify which  I'll have to play with it.

AS they came from, so I could prepend the correct AS by matching on the tag... Lots of options now!

Actions

This Discussion