cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1150
Views
0
Helpful
11
Replies

Question regarding bgp/mpls

jonesl1
Level 1
Level 1

I have a couple questions regarding MPLS circuits.    Currently we have an ASR 1002.   There is a spa card

in this ASR that provides us a DS3 connection.  We use BGP as our routing protocol to the phone company's MPLS cloud.   We have

numerous remote agencies on the other end of this DS3, approximately 200 if i were to guess.   All of which use the DS3

to come in on.  

So with that said,  This DS3 provides us only one physical interface.   We would like to put some sort of access-list inbound on this

interface to prevent just anything from the MPLS/BGP cloud from coming into our network.   We would like to have some control over this.

I just want to know how others go about doing this, because it seems like this ACL will be super large being i have 200 agencies coming in

through that interface.   And in addition, with all those packets coming in.....will this hinder the performance of that interface if it has to

analyze each packet coming inbound? 

What is the best route to go about doing something like this?

1 Accepted Solution

Accepted Solutions

jonesl1 wrote:

Please don't apologize for a lengthy response.   Believe me, I dont care how long it is as long as I can get a grasp on the logic of it.  Btw, I do appreciate

you taking the time to explain this to me. 

Ok....so I think I kinda understand what your doing with that config, but I do have a couple questions and I just wanted to sound them out against you to make sure my logic and thinking is occurring correctly with this process.

So if i understand this corrctly...  Lets say router R is the remote site router and router H is the Host side (original i know )    

Lets say Router R is sending traffic to the cloud with a destination of Router H.  When traffic is generated and goes through it's serial interface and out using bgp, through the route map to-vpn, its going to append basically a sub-AS number onto the end of the AS number thats already there (so it will go from 55555 to 55555:28534)?  Basically marking the traffic so that I have something to look for on my other end to verify it's truly coming from my agencies.   Is that sounding right so far?  

Exactly correct.

Once that same traffic hits router H's serial interface coming inbound, He will check the first route-map and determine if that AS number matches whats in community-list 200.   If it doesn't match....it falls all the way through that route map and begins checking the other route-map (90) and then automatically forwards him to the NULL0 route which drops the packet.    And as long as I put this same thing on all my routers (minus the internet), It should verify that I'm only receiving traffic from my agencies.  

Again, you are exactly correct.  You are understanding exactly what is happening.

Does it seem like i'm processing this in my little brain correctly?   Is there any significance in setting the metric or the igp part?  Also, in the first incoming route-map, you set the ip to next-hop peer address.   Is that basically just dropping it off in that router itself or what is that actually doing?

Regarding the IGP and metric, I entered those more out of habit, then anything else.  Those BGP attributes are mostly related to how BGP interacts with other routing protocols and are mostly relevant if you are turning around and redistributing those routes dynamically into another routing protocol (such as EIGRP) towards the local LAN.

Regarding the "set next-hop peer address".  This one is important.  Make sure that you are implementing this.  In the normal BGP peering process, a BGP router will receive a list of prefixs from it's BGP neighbor.  It will then turn around and install those prefixs in it's route table and set the next-hop for those routes as the BGP peer address from who it learned those routes from.  In this route-map, you are essentially saying, "Do you match my extended BGP community list?  Yes?  OK, I'm going to install the route in my route table and set the next hop to whoever I learned the route from.".  You are basically telling BGP to go ahead and do it's job.  In plain english, the flow is ...

route-map 10

match my BGP community?

install the route normally and set the next hop to whoever I learned the route from

route-map 90

don't match my BGP community?

install the route, but set the next hop to 192.0.2.1, which is forwarded to the Null interface.  In other words, blackhole the route.

Again thank you for all your help, you have no idea what it means to me that your taking the time to explain it.   Thanks a ton in advance!

I hope all this helps.  Please feel free to post any futher follow-up or questions.  BGP has more knobs to turn and more options to customize than almost any other routing protocol.  It can get confusing in a hurry.

View solution in original post

11 Replies 11

vmiller
Level 7
Level 7

Depending on who your provider is, and the terms of your service, you may just be seeing the routes from those locations in your VRF.

It depends on how ther carrier manages their piece.

If your remote clients are all addressed out of the same block, thats a starting point for any acl.

Take a look at what routes appear in your VRF first.

Edison Ortiz
Hall of Fame
Hall of Fame

GETVPN would be something you should explore.

dlstokes
Level 1
Level 1

From your topic header, I assume that you are using BGP to exchange routes with your Carrier?  If that is true, you can use route-maps (which you really should be using anyway to control what is sent and received) to (1) set an extended BGP community on your outgoing routes and then (2) check for that community as they arrive at your other routers.  If the extended community is not there, then you can dump the routes to the NULL interface and blackhole them.  It's very efficient and considerably easier than lengthy ACL's.  It is unlikely that you are going to have foreign routes in your VRF in the first place, but it is extremely unlikely (virtually impossible) that those foreign routes are going to happen to have an extended community set and then actually have it match the community that you are validating against.

Are you using a unique BGP AS number for each site?  Or are you using one common AS?

Daniel

You are correct in your assumption regarding exchanging BGP routes with the carrier.  That's exactly what we are doing.   And we

are using the same AS number on all routers both remote and local.

Can you explain a little more what you mean regarding the route maps?  Possibly an example.   I'm pretty new to the bgp routing protocol and i'm still trying to get my hands around it.  The more I delve into this stuff, the more I realize how small my hands are apparently   

Here is a thread covering the same question.

https://supportforums.cisco.com/thread/2036900

This should get you started. I would look at just deailing with the incoming routes.

You can use the following example to use the route-map method that I described previously.  Obviously, you will need to ensure that these configuration examples do not conflict with your existing configuration.

Add the following route to all of your routers (add this route literally...this is not an 'example' address)....

   ip route 192.0.2.1 255.255.255.255 Null0

Enable BGP community new-format

   ip bgp-community new-format

Add the following BGP community list to all of your routers

   ip community-list 200 permit 55555:28534 <-- replace '55555' with your real BGP AS number

Add the following route-maps to your routers.  Note that '55555' is an example BGP AS number.  Replace 55555 with your real BGP AS number.  Notice that there are two route-maps, one called 'to-vpn' and one called 'from-vpn'.

-------------------------------------------------------
route-map from-vpn permit 10
match community 200
set ip next-hop peer-address
!
route-map from-vpn permit 90
set ip next-hop 192.0.2.1

-------------------------------------------------------

route-map to-vpn permit 10
set metric 100
set origin igp
set community 55555:28534 <-- replace '55555' with your real AS number
-------------------------------------------------------

Here is the somewhat tricky part.  You will need to update the configuration for your BGP neighbors to start using the route-maps.  The reason I say that it is tricky, is that you have to be careful about the order that you apply this, as you do not want to start systematically cutting off your sites from the WAN.

First .... (do this to all routers)

router bgp 55555                                           <-- replace 55555 with your real BGP AS number

neighbor 192.168.1.1 send-community           <-- use real neighbor ID

neighbor 192.168.1.1 route-map to-vpn out     <-- use real neighbor ID

Unfortunately, you will have to reset the BGP peer for this route-map to take affect.  It will cause a short outage (could be as long as 120 seconds, but should be faster than that).

Second (now that everyone is marking their routes with their extended community, you can begin checking for it on the 'other side' as they arrive at other routers)......

router bgp 55555                                           <-- replace 55555 with your real BGP AS number

neighbor 192.168.1.1 route-map from-vpn in     <-- use real neighbor ID

Again, unfortunately, you will need to reset the BGP peer for this update to take affect.  One more quick outage.  But then you're done.

Sorry for the length of this reply.  If you look strictly at the configuration commands and remove my comments, you'll see that it's really not that much configuration.

I hope this helps.  Please feel free to post any questions if you would like clarification on any of these configurations.

One final thought to my previous configuration example ...

If you have a BGP peer with your ISP for Internet access, do NOT apply these route-maps to that ISP peer.  You will be very distressed by the results. 

The only BGP peers that you should be using the route-maps and extended bgp communities with are your "private" MPLS peers.

Just want to make sure you understand that.

Please don't apologize for a lengthy response.   Believe me, I dont care how long it is as long as I can get a grasp on the logic of it.  Btw, I do appreciate

you taking the time to explain this to me. 

Ok....so I think I kinda understand what your doing with that config, but I do have a couple questions and I just wanted to sound them out against you to make sure my logic and thinking is occurring correctly with this process.

So if i understand this corrctly...  Lets say router R is the remote site router and router H is the Host side (original i know )    

Lets say Router R is sending traffic to the cloud with a destination of Router H.  When traffic is generated and goes through it's serial interface and out using bgp, through the route map to-vpn, its going to append basically a sub-AS number onto the end of the AS number thats already there (so it will go from 55555 to 55555:28534)?  Basically marking the traffic so that I have something to look for on my other end to verify it's truly coming from my agencies.   Is that sounding right so far?  

Once that same traffic hits router H's serial interface coming inbound, He will check the first route-map and determine if that AS number matches whats in community-list 200.   If it doesn't match....it falls all the way through that route map and begins checking the other route-map (90) and then automatically forwards him to the NULL0 route which drops the packet.    And as long as I put this same thing on all my routers (minus the internet), It should verify that I'm only receiving traffic from my agencies.  

Does it seem like i'm processing this in my little brain correctly?   Is there any significance in setting the metric or the igp part?  Also, in the first incoming route-map, you set the ip to next-hop peer address.   Is that basically just dropping it off in that router itself or what is that actually doing?

Again thank you for all your help, you have no idea what it means to me that your taking the time to explain it.   Thanks a ton in advance!

Hi Jonesl1,

Not entirelly.. The community attribute is used to group prefixes, meaning subnets... not the real traffic. BGP protocol is kinda different because it advertises prefixes only... get the picture?

So, when you group prefixes with community attributes, that enables you to filter the in and/or out at any boundary... meaning that any prefixes you receive at H that don't conform to the route-map gets discarded. Likewise at the R's ...

I'm assuming that your carrier (ISP) is providing you with a VRF or L2VPN of some sort which enables you to have a MPLS/VPN across the territory where the branches are ...

Cheers,

Pedro

jonesl1 wrote:

Please don't apologize for a lengthy response.   Believe me, I dont care how long it is as long as I can get a grasp on the logic of it.  Btw, I do appreciate

you taking the time to explain this to me. 

Ok....so I think I kinda understand what your doing with that config, but I do have a couple questions and I just wanted to sound them out against you to make sure my logic and thinking is occurring correctly with this process.

So if i understand this corrctly...  Lets say router R is the remote site router and router H is the Host side (original i know )    

Lets say Router R is sending traffic to the cloud with a destination of Router H.  When traffic is generated and goes through it's serial interface and out using bgp, through the route map to-vpn, its going to append basically a sub-AS number onto the end of the AS number thats already there (so it will go from 55555 to 55555:28534)?  Basically marking the traffic so that I have something to look for on my other end to verify it's truly coming from my agencies.   Is that sounding right so far?  

Exactly correct.

Once that same traffic hits router H's serial interface coming inbound, He will check the first route-map and determine if that AS number matches whats in community-list 200.   If it doesn't match....it falls all the way through that route map and begins checking the other route-map (90) and then automatically forwards him to the NULL0 route which drops the packet.    And as long as I put this same thing on all my routers (minus the internet), It should verify that I'm only receiving traffic from my agencies.  

Again, you are exactly correct.  You are understanding exactly what is happening.

Does it seem like i'm processing this in my little brain correctly?   Is there any significance in setting the metric or the igp part?  Also, in the first incoming route-map, you set the ip to next-hop peer address.   Is that basically just dropping it off in that router itself or what is that actually doing?

Regarding the IGP and metric, I entered those more out of habit, then anything else.  Those BGP attributes are mostly related to how BGP interacts with other routing protocols and are mostly relevant if you are turning around and redistributing those routes dynamically into another routing protocol (such as EIGRP) towards the local LAN.

Regarding the "set next-hop peer address".  This one is important.  Make sure that you are implementing this.  In the normal BGP peering process, a BGP router will receive a list of prefixs from it's BGP neighbor.  It will then turn around and install those prefixs in it's route table and set the next-hop for those routes as the BGP peer address from who it learned those routes from.  In this route-map, you are essentially saying, "Do you match my extended BGP community list?  Yes?  OK, I'm going to install the route in my route table and set the next hop to whoever I learned the route from.".  You are basically telling BGP to go ahead and do it's job.  In plain english, the flow is ...

route-map 10

match my BGP community?

install the route normally and set the next hop to whoever I learned the route from

route-map 90

don't match my BGP community?

install the route, but set the next hop to 192.0.2.1, which is forwarded to the Null interface.  In other words, blackhole the route.

Again thank you for all your help, you have no idea what it means to me that your taking the time to explain it.   Thanks a ton in advance!

I hope all this helps.  Please feel free to post any futher follow-up or questions.  BGP has more knobs to turn and more options to customize than almost any other routing protocol.  It can get confusing in a hurry.

Thank you all for your responses and help.   I have to admit, I find this forum extremely helpful. Many times more helpful than TAC.   I just wish I knew how you all became so smart with all this stuff.  I feel like every time I think I get a hold on things, something else kicks me in the teeth and says 'WRONG AGAIN'.

dlstokes,Thank you so much for breaking that down to me in an 'understandable' format.  It definitely made a ton more sense once you broke it down for me.   Do you know of any good tutorials relating to BGP I could read up on to further understand this protocol?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco