Sample transit BGP core configuration

I will be doing a a series of labs exploring BGP and MPLS, how they could or could not work together, what problems MPLS solves and causes, and how its configuration and maintenance are done. I will start with a simulated segment of a sample ISP, running BGP on all routers, and will move to an environment running MPLS on the core devices and BGP on the provider edges. I will further explore the different options presented after the MPLS migration, like VPNs, Traffic Engineering and VPLS.

This post covers the first lab, about bringing the sample BGP core up, and will give me an option to practice some BGP related stuff, including hierrarchical route reflectors with (just a bit of ) redundancy, route filtering with prefix-lists, as-paths and route-maps, and some very basic stuff with BGP communities.

Contents

Topology
Addressing
Configuration
- Internal routing within ISP1
- iBGP sessions
- eBGP sessions and route filters
- Inbound route filters
- Outbound route filters
- Route tagging with BGP community strings
- BGP configuration on PE devices
- Complete configurations

This is the simple topology we are starting with:

Sample ISP BGP core

We have a sample ISP environment, significantly simplified for lab purposes (that was the total number of routers I was able to run in dynamips in my current configuration). The provider is running BGP on all devices, for AS65001. The physical links in the toplogy could change as we go along, and at the start are exactly following the BGP sessions - we are running a pair of redundant core route reflectors in the backbone (Core_RR1 and Core_RR2), to reflect routes between the POPs. There are a total of three POPs - two for customer connectivity and one, called IXP, to represent an external peering point, similar to a real-world Internet Exchange Point. To limit the number of devices we need to run in dynamips, the BGP design is significantly simplified - each client POP is consisting of a single POP route reflector (POP_RRCS), fully meshed with iBGP to the core route reflectors, and running iBGP sessions to the PE routers in the POP. The POP route reflector routers are clients to the core route reflectors and servers for the PE routers. The PE routers are running eBGP to the customers - there are two customers, each of them having two locations, each of which is connected to a different POP. We will use this further to run MPLS VPNs between the individual customer locations. To limit the number of devices we need to run on dynamips, the IXP POP is consisting of a single edge router only, running iBGP as a client to the core route reflectors and eBGP to the external peer EXT_PE in AS65002.

In the real world, and depending on the scale of the provider network, such a design could be much more redundant, with a pair of route reflectors in each POP, including the IXP POPs, or running confederations in some places, instead of hierrarchical route reflectors. However, the presented limited topology should be enough to illustrate the main things MPLS is used for in an ISP core environment.

The addressing scheme is documented in the topology, including the addresses for the internal core interconnections, the address space delegated to each POP, and the address space used by the customers internally. Loopbacks on the customer edge routers are used to inject some customer routes from both locations into the network, simulating some internal customer network connectivity.

Addressing
(back to top)

ISP1 will own the following networks:
172.19.0.0/16:

172.19.1.0/24 - assigned to POP 1 for internal POP connections and connectons to customers;
172.19.2.0/24 - assigned to POP 2 for internal POP connections and connectons to customers;
172.19.253.0/24 - assigned to IXP POP, connecting to external peer(s);
172.19.254.0/24 - used for internal interconnections within the ISP1 core;
172.19.255.0/24 - used for loopbacks within the ISP1 network;

We will assume the following networks are part of ISP1, our core route reflectors have routing for them, but they are not directly used in our segment of the network. We will just announce them from the core route reflectors, just to have some more networks to the topology:

172.25.0.0/16 - injected into the network by Core_RR1;
172.26.0.0/16 - injected into the network by Core_RR1;
172.27.0.0/16 - injected into the network by Core_RR1;
172.28.0.0/16 - injected into the network by Core_RR1;
172.29.0.0/16 - injected into the network by Core_RR1;
172.30.0.0/16 - injected into the network by Core_RR1;

Customer 1has two separate locations connected to ISP1 with different AS numbers, respectively connecting to POP1 and POP2, and having the following addressing assigned:

172.17.0.0/24 - 172.17.7.0/24 - these networks are held on loopbacks on the customer edge router in location 1 (CE1_1), and they are summarized as 172.17.0.0/21 when announced to the ISP1 provider-edge routers;
172.17.8.0/24 - 172.17.15.0/24 - held on loopbacks on the customer edge router in location 2 (CE1_2), these networks announced as a 172.17.8.0/21 aggregate route by the customer edge.

Customer2 also has two locations, with addresses from 172.18.0.0/16.

172.18.0.0/24 - 172.18.7.0/24 - held on loopbacks on CE2_1, the customer edge in location 1, announced as a 172.18.0.0/21 aggregate route to ISP1.
172.18.8.0/24 - 172.18.15.0/24 - held on loopbacks on the location 2 customer edge CE2_2, announced as a 172.18.8.0/21 aggregate to ISP1.

There is one external peer in the topology, just represented by its provider edge device, in order to have another transit AS to play with in terms of route filters. The networks assigned to this peer are:

172.20.0.0/16 - 172.23.0.0/16 - all held on loopbacks on EXT_PE;

Configuration
(back to top)

Note: If you would just like to look at the complete configurations for all devices, without reading the complete description below, you can find them in the “Complete configurations” section at the end of this document.

Internal routing withing ISP1
(back to top)

We will run EIGRP as an IGP protocol within the ISP1 network, to hold our internal infrastructure together and provide routing for the loopbacks, which willbe used as a source for BGP updates for every iBGP session within the ISP1 network.

iBGP sessions
(back to top)

We will have a hierrarchical route-reflector design within the ISP1 network. The core route reflectors, Core_RR1 and Core_RR2, will be responsible for reflecting routes to/from the POPs and other (assumed) parts of the network. The core route reflectors will have an iBGP session between them, and both of them will run iBGP sessions with every client. Each POP will contain a route reflector, having iBGP sessions with the PE routers in the same POP, and being a client to the core route reflectors.In order to limit the amount of routers I needed to run in dynamips, the POP route reflectors are not redundant, and the IXP POP does not contain a route reflector, only a client of the core reflectors, directly peering with the external peer in AS65002.

On the route reflectors, we will have a peer group defined for our clients (POP route reflectors and normal clients) Here’s the BGP configuraiton for the core route reflectors and the POP route reflectors.

Core_RR1:

router bgp 65001 no synchronization bgp router-id 172.19.255.1 bgp cluster-id 1 bgp log-neighbor-changes network 172.19.0.0 network 172.25.0.0 network 172.26.0.0 network 172.27.0.0 network 172.28.0.0 network 172.29.0.0 network 172.30.0.0 neighbor CUSTOMER_POPs peer-group neighbor CUSTOMER_POPs remote-as 65001 neighbor CUSTOMER_POPs update-source Loopback0 neighbor CUSTOMER_POPs route-reflector-client neighbor CUSTOMER_POPs next-hop-self neighbor CUSTOMER_POPs send-community neighbor IXP_POPs peer-group neighbor IXP_POPs remote-as 65001 neighbor IXP_POPs update-source Loopback0 neighbor IXP_POPs route-reflector-client neighbor IXP_POPs next-hop-self neighbor IXP_POPs send-community neighbor 172.19.255.2 remote-as 65001 neighbor 172.19.255.2 update-source Loopback0 neighbor 172.19.255.2 next-hop-self neighbor 172.19.255.2 send-community neighbor 172.19.255.2 soft-reconfiguration inbound neighbor 172.19.255.3 peer-group CUSTOMER_POPs neighbor 172.19.255.3 description POP1_RRCS neighbor 172.19.255.3 soft-reconfiguration inbound neighbor 172.19.255.6 peer-group IXP_POPs neighbor 172.19.255.6 description EXT_PE_RRC neighbor 172.19.255.6 soft-reconfiguration inbound neighbor 172.19.255.7 peer-group CUSTOMER_POPs neighbor 172.19.255.7 description POP2_RRCS neighbor 172.19.255.7 soft-reconfiguration inbound no auto-summary

Core_RR2:

router bgp 65001 no synchronization bgp router-id 172.19.255.2 bgp cluster-id 1 bgp log-neighbor-changes network 172.19.0.0 network 172.25.0.0 network 172.26.0.0 network 172.27.0.0 network 172.28.0.0 network 172.29.0.0 network 172.30.0.0 neighbor CUSTOMER_POPs peer-group neighbor CUSTOMER_POPs remote-as 65001 neighbor CUSTOMER_POPs update-source Loopback0 neighbor CUSTOMER_POPs route-reflector-client neighbor CUSTOMER_POPs next-hop-self neighbor CUSTOMER_POPs send-community neighbor IXP_POPs peer-group neighbor IXP_POPs remote-as 65001 neighbor IXP_POPs update-source Loopback0 neighbor IXP_POPs route-reflector-client neighbor IXP_POPs next-hop-self neighbor IXP_POPs send-community neighbor 172.19.255.1 remote-as 65001 neighbor 172.19.255.1 update-source Loopback0 neighbor 172.19.255.1 next-hop-self neighbor 172.19.255.1 send-community neighbor 172.19.255.1 soft-reconfiguration inbound neighbor 172.19.255.3 peer-group CUSTOMER_POPs neighbor 172.19.255.3 description POP1_RRCS neighbor 172.19.255.3 soft-reconfiguration inbound neighbor 172.19.255.6 peer-group IXP_POPs neighbor 172.19.255.6 description EXT_PE_RRC neighbor 172.19.255.6 soft-reconfiguration inbound neighbor 172.19.255.7 peer-group CUSTOMER_POPs neighbor 172.19.255.7 description POP2_RRCS neighbor 172.19.255.7 soft-reconfiguration inbound no auto-summary

There are not many interesting parts in this configuration, and the few that are, are in bold typeface. When configuring redundant route reflectors in BGP, we have to use the command

bgp cluster-id <cluster-id>

to make sure that both the route reflectors are part of the same cluster. If they are not part of the same cluster, and still both route reflectors have iBGP sessions with the same clients, some problems can occur. Say POP1_RRCS sends a prefix to both the route reflectors. The reflectors then, advertise it to each other as they would to any non-client iBGP peer. If the original source of the route (POP1_RRCS) becomes unavailable, then we might end-up with a situation where the route reflectors will still route for this prefix through each other. The cluster-id solves this, by making sure the two route-reflectors are part of the same cluster, and therefore receive the same updates from both clients, and ignore updates between themselves, thus preventing loops.

Another interesting part is the use of peer-groups with route-reflectors. Before IOS 12.0, you could run into some issues when using route-reflectors and peer-groups for clients. Say we have another peer for Core_RR1, a non-client peer. Let’s say this non-client peer advertises a route to Core_RR1, and also a client router advertises the same route, and Core_RR1’s best path for this route is via the client peer. Being a route reflector, Core_RR1 will reflect this route to all the other clients, in the same peer group. Now, because the best path for this route is via the client peer, Core_RR1 needs to send a withdrawal for this route to the client (as a split-horizon measure), but it will also send this withdrawal of the route to all the other clients in the same peer-group, because all routers in a peer-group assume the same outgoing policies and updates. This is resolved in IOS later than 12.0. The route reflector will not send the withdrawal to the client, but it will send the best path to all the clients. The client-peer, who with recent IOS versions will understand the originator-id field, will see its own originator-id there and will discard this route.

Here’s the configuration for the other routers in the core. We have used different cluster-id values for the POPs, but this is not really needed when there is only one route reflector in a cluster - the default cluster-id for the cluster is the router ID of the route-reflector. Still, if we decide to add another route reflector to the clusters in the POPs, we can leave the cluster-id command in the configuration.

POP1_RRCS:

router bgp 65001 no synchronization bgp router-id 172.19.255.3 bgp cluster-id 2 bgp log-neighbor-changes neighbor PE_ROUTERS peer-group neighbor PE_ROUTERS remote-as 65001 neighbor PE_ROUTERS update-source Loopback0 neighbor PE_ROUTERS route-reflector-client neighbor PE_ROUTERS next-hop-self neighbor PE_ROUTERS send-community neighbor 172.19.255.1 remote-as 65001 neighbor 172.19.255.1 description Core_RR1 neighbor 172.19.255.1 update-source Loopback0 neighbor 172.19.255.1 next-hop-self neighbor 172.19.255.1 send-community neighbor 172.19.255.1 soft-reconfiguration inbound neighbor 172.19.255.2 remote-as 65001 neighbor 172.19.255.2 description Core_RR2 neighbor 172.19.255.2 update-source Loopback0 neighbor 172.19.255.2 next-hop-self neighbor 172.19.255.2 send-community neighbor 172.19.255.2 soft-reconfiguration inbound neighbor 172.19.255.4 peer-group PE_ROUTERS neighbor 172.19.255.4 description 1PE1_RRC neighbor 172.19.255.4 soft-reconfiguration inbound neighbor 172.19.255.5 peer-group PE_ROUTERS neighbor 172.19.255.5 description 1PE2_RRC neighbor 172.19.255.5 soft-reconfiguration inbound no auto-summary

POP2_RRCS:

router bgp 65001 no synchronization bgp router-id 172.19.255.7 bgp cluster-id 3 bgp log-neighbor-changes neighbor PE_ROUTERS peer-group neighbor PE_ROUTERS remote-as 65001 neighbor PE_ROUTERS update-source Loopback0 neighbor PE_ROUTERS route-reflector-client neighbor PE_ROUTERS next-hop-self neighbor PE_ROUTERS send-community neighbor 172.19.255.1 remote-as 65001 neighbor 172.19.255.1 description Core_RR1 neighbor 172.19.255.1 update-source Loopback0 neighbor 172.19.255.1 next-hop-self neighbor 172.19.255.1 send-community neighbor 172.19.255.1 soft-reconfiguration inbound neighbor 172.19.255.2 remote-as 65001 neighbor 172.19.255.2 description Core_RR2 neighbor 172.19.255.2 update-source Loopback0 neighbor 172.19.255.2 next-hop-self neighbor 172.19.255.2 send-community neighbor 172.19.255.2 soft-reconfiguration inbound neighbor 172.19.255.8 peer-group PE_ROUTERS neighbor 172.19.255.8 description 2PE1_RRC neighbor 172.19.255.8 soft-reconfiguration inbound neighbor 172.19.255.9 peer-group PE_ROUTERS neighbor 172.19.255.9 description 2PE2_RRC neighbor 172.19.255.9 soft-reconfiguration inbound no auto-summary

EXT_PE_RRC will be discussed in the next section because it is not a route reflector, just a client to the core route reflectors and a PE for the external peering between AS65001 and AS65002.

eBGP sessions and route filters
(back to top)

In every POP, we have the POP route reflector run iBGP sessions with the PE devices, which in turn run eBGP sessions to customers, and other ISPs. As we said before, if the POPs are big enough and house more PE devices and more customers, a more resilient BGP design should be chosen and redundant route reflectors should also be implemented in the POPs. In our case, to limit the number of devices we simulate, we are only running a single route reflector in each POP.

As a transit AS, we have to take care about what routes we accept and what routes we advertise on the eBGP sessions. We also need to protect our core infrastructure from route hijacks and spoofing so we have to deploy some inbound filtering on the routes we receive from external sources.

Inbound route filters
(back to top)

Prefix-lists

As an inbound filter, we will only accept the prefixes that have been agreed with the customers, so on every PE device we will have an inbound prefix-list filter, permitting only the prefixes that have been assigned to the customer and that the customer has agreed to advertise to us.

AS-Path filters

Also, the customers should not be providing transit to any other ASes, in case they are multihomed. Even though in our situation the customers are not multihomed, and even though some might say this is a customer responsibility, this is a good opportunity to practice as-path access-lists so we will use an inbound as-path filter to only accept routes that originated in the customer AS. However, to give the customer the needed flexibility on their own route advertisements, we have to also accept prepended routes.
We also want to make sure we protect ourselves from receiving excessively prepended as-paths, because of the issues that AS-Paths longer than 255 can cause with older IOS versions - BGP sessions can start flapping continuously and cause quite a bad impact with global significance, as it actually happened earlier this year. Some more details about this can be found on the Renesys blog here, and on Ivan Pepelnjiak’s Cisco IOS hints and tricks here. You can always set your “bgp max-as limit” to protect yourself from such a scenario, especially if you are running an older IOS version, but still having such a filter will ensure you stop this at the network edge, evne if you have not implemented the max-as limit.
In our case, we are setting a filter to deny any prefix that contains an AS number repeating more than 10 times in it (the _[0-9]+ is matching any number, and then we take it as an atom by putting it in brackets, and we match on it 9 more times, referring to the first match with \1).

The as-path access-list that does this is the following:

ip as-path access-list 2 deny _(_[0-9]+)_\1_\1_\1_\1_\1_\1_\1_\1_\1_ ip as-path access-list 2 permit ^(ASNUM_)+$
ip as-path access-list 2 deny .*

The regular expression used in the example is looking matching for ASNUM and then any single whitespace, one or more times in the beginning of the string, and then it expects the end of the string. So in essence, it would match any one of the following AS-PATHS:
ASNUM
ASNUM ASNUM
ASNUM ASNUM ASNUM
So it would accept prepended and unprepended prefixes. In the inbound filters at the PE devices, we will substitute ASNUM for the actual customer AS number, and apply this as-path filter inbound to the customer-edge neighbor router.

Below are the inbound filters for all PE routers.

On 1PE1_RRC - peering with customer 1, location 1, AS65101:

ip prefix-list CE1_1 seq 5 permit 172.17.0.0/16 le 21 ... ip as-path access-list 2 deny _(_[0-9]+)_\1_\1_\1_\1_\1_\1_\1_\1_\1_ ip as-path access-list 2 permit ^(65101_)+$ ip as-path access-list 2 deny .*

On 1PE2_RRC - peering with customer 2, location 1, AS65201:

ip as-path access-list 2 deny _(_[0-9]+)_\1_\1_\1_\1_\1_\1_\1_\1_\1_ ip as-path access-list 2 permit ^(65201_)+$ ip as-path access-list 2 deny .* … ip prefix-list CE2_1 seq 5 permit 172.18.0.0/16 le 21

On 2PE1_RRC - peering with customer 1, location 2, AS65102:

ip as-path access-list 2 deny _(_[0-9]+)_\1_\1_\1_\1_\1_\1_\1_\1_\1_ ip as-path access-list 2 permit ^(65102_)+$ ip as-path access-list 2 deny .* … ip prefix-list CE1_2 seq 5 permit 172.17.0.0/16 le 21

On 2PE2_RRC - peering with customer 2, location 2, AS65202:

ip as-path access-list 2 deny _(_[0-9]+)_\1_\1_\1_\1_\1_\1_\1_\1_\1_ ip as-path access-list 2 permit ^(65202_)+$ ip as-path access-list 2 deny .* … ip prefix-list CE2_2 seq 5 permit 172.18.0.0/16 le 21

On EXT_PE_RRC, peering with AS65002 as a transit AS:

ip as-path access-list 2 deny _(_[0-9]+)_\1_\1_\1_\1_\1_\1_\1_\1_\1_ ip as-path access-list 2 permit ^(65002_)+(_[0-9]+)*$ ip as-path access-list 2 deny .* … ip prefix-list EXT_PE seq 5 permit 172.0.0.0/8 ge 14 le 16

Outbound route filters
(back to top)

In our outbound route filters, we need to make sure:
- we advertise our own locally originated networks - unprepended;
- we advertise our own locally originated networks - prepended;
- we advertise transit networks that we have received from other external peers;

AS-Path filters

We can do what we described above with a simple as-path access-list that we will apply outbound to our external peers.
This as-path access-list that looks like this:

ip as-path access-list 1 permit ^(ASNUM_)*(_[0-9]+)*$
ip as-path access-list 1 deny .*

The regular expression used in the example is looking matching for ASNUM and then any single whitespace, one or more times in the beginning of the string, then any whitespace and numbers (_[0-9]+), zero or more times (to catch both prepended and unprepended transit prefixes), and then it expects the end of the string. So in essence, it would match any one of the following AS-PATHS:
ASNUM
ASNUM ASNUM
ASNUM ASNUM ASNUM1
ASNUM ASNUM ASNUM1 ASNUM1
It would accept prepended and unprepended prefixes. In the outbound filters at the PE devices, we will substitute ASNUM for our own AS number, and apply this as-path filter inbound to the customer-edge neighbor router.

Here’s a brief sumary of the filtering done on the ISP1 provider edge routers.

On 1PE1_RRC - peering with customer 1, location 1, AS65101:

ip as-path access-list 1 deny 65101
ip as-path access-list 1 permit ^(65001_)*(_[0-9]+)*$
ip as-path access-list 1 deny .*

On 1PE2_RRC - peering with customer 2, location 1, AS65201:

ip as-path access-list 1 deny 65201
ip as-path access-list 1 permit ^(65001_)*(_[0-9]+)*$
ip as-path access-list 1 deny .*

On 2PE1_RRC - peering with customer 1, location 2, AS65102:

ip as-path access-list 1 deny 65102
ip as-path access-list 1 permit ^(65001_)*(_[0-9]+)*$
ip as-path access-list 1 deny .*

On 2PE2_RRC - peering with customer 2, location 2, AS65202:

ip as-path access-list 1 deny 65202
ip as-path access-list 1 permit ^(65001_)*(_[0-9]+)*$
ip as-path access-list 1 deny .*

On EXT_PE_RRC, peering with AS65002 as a transit AS:

ip as-path access-list 1 deny 65002
ip as-path access-list 1 permit ^(65001_)*(_[0-9]+)*$
ip as-path access-list 1 deny .*

Route tagging with BGP community strings
(back to top)

This is not really nessecary for our scenario, but if we want to do some stuff with different customer routes within our backbones, like some form of traffic engineering, or anything else, its useful to mark them with a community that we will later use in our AS, or we will do selective advertisements/selective prepends/whatever else we need;) .. The important thing is that we also strip the communities from our outgoing route advertisements so we do not pollute routes we advertise out.

In our scenario, we are just doing a simple marking - we mark routes originated in the neighbor AS with a community-string of ASNUM:1000 and we are marking routes that are just passing through the neighbor AS with a community-string of ASNUM:2000, where ASNUM is out neighbor autonomous system number.

We do this with two route-maps - COLORIZE_IN, that we apply inbound to our external neighbors, and STRIP_COLORS_OUT, that we apply outbound to our external neighbors. On PE devices, in the COLORIZE_IN route-map, we are matching the locally originated prefixes with a prefix-list (the same one we use for inbound route filtering), and then we set the community. On PE devices that peer to other transit ASes, we are matching the transit routes with an as-path access-list, that matches only the transit AS-paths.

Following are the actual configurations for this.

On 1PE1_RRC - peering with customer 1, location 1, AS65101

ip prefix-list CE1_1 seq 5 permit 172.17.0.0/16 le 21 route-map COLORIZE_IN permit 10 match ip address prefix-list CE1_1 set community 65101:1000 ! route-map COLORIZE_IN deny 300 ! route-map STRIP_COLORS_OUT permit 10 set community none !

On 1PE2_RRC - peering with customer 2, location 1, AS65201:

ip prefix-list CE2_1 seq 5 permit 172.18.0.0/16 le 21 route-map COLORIZE_IN permit 10 match ip address prefix-list CE2_1 set community 65201:1000 ! route-map COLORIZE_IN deny 300 ! route-map STRIP_COLORS_OUT permit 10 set community none !

On 2PE1_RRC - peering with customer 1, location 2, AS65102:

ip prefix-list CE1_2 seq 5 permit 172.17.0.0/16 le 21 route-map COLORIZE_IN permit 10 match ip address prefix-list CE1_2 set community 65102:1000 ! route-map COLORIZE_IN deny 300 ! route-map STRIP_COLORS_OUT permit 10 set community none !

On 2PE2_RRC - peering with customer 2, location 2, AS65202:

ip prefix-list CE2_2 seq 5 permit 172.18.0.0/16 le 21 route-map COLORIZE_IN permit 10 match ip address prefix-list CE2_2 set community 65202:1000 ! route-map COLORIZE_IN deny 300 ! route-map STRIP_COLORS_OUT permit 10 set community none !

On EXT_PE_RRC, peering with AS65002 as a transit AS:

ip prefix-list EXT_PE seq 5 permit 172.0.0.0/8 ge 14 le 16 route-map COLORIZE_IN permit 10 match ip address prefix-list EXT_PE set community 65002:1000 ! route-map COLORIZE_IN permit 20 match as-path 3 set community 65002:2000 additive ! route-map COLORIZE_IN deny 300 ! route-map STRIP_COLORS_OUT permit 10 set community none !

We can see that there is one statement more in the COLORIZE_IN route-map on the EXT_PE_RRC router - this is because we are using an as-path access-list to identify transit prefixes, as mentioned before. The AS-path access-list is the following:

ip as-path access-list 3 permit ^(65002_)+([0-9]+)+$ ip as-path access-list 3 deny .*

This regular expression is matching our neighbor AS 65002 followed by a whitespace, one or more times (to allow for prepending), and then it matches one or more numbers, at least once, and then expects the end of the line. This way we can match only transit as-paths, such as the following:
65002 65003 65004
65002 65002 65002 65003 65004
because all of them will have at least once AS number 65002, followed by the number of the other ASes the prefix traversed.

Note: to display the community value as a pair of 2-byte numbers, i.e. AA:NN, instead of the cisco default of one 32 bit number, use the command “ip bgp-community new-format”.

BGP Configuration on PE devices
(back to top)

This has pretty much been all explained so the only thing left is the actual neighbor definitions on the PE devices, where the filters from above are applied to the neighbors.

1PE1_RRC:

router bgp 65001 no synchronization bgp router-id 172.19.255.5 bgp log-neighbor-changes neighbor 172.19.1.2 remote-as 65101 neighbor 172.19.1.2 next-hop-self neighbor 172.19.1.2 send-community neighbor 172.19.1.2 soft-reconfiguration inbound neighbor 172.19.1.2 prefix-list CE1_1 in neighbor 172.19.1.2 route-map COLORIZE_IN in neighbor 172.19.1.2 filter-list 2 in neighbor 172.19.1.2 route-map STRIP_COLORS_OUT out neighbor 172.19.1.2 filter-list 1 out neighbor 172.19.255.3 remote-as 65001 neighbor 172.19.255.3 update-source Loopback0 neighbor 172.19.255.3 next-hop-self neighbor 172.19.255.3 send-community neighbor 172.19.255.3 soft-reconfiguration inbound no auto-summary

1PE2_RRC:

router bgp 65001 no synchronization bgp router-id 172.19.255.4 bgp log-neighbor-changes neighbor 172.19.1.6 remote-as 65201 neighbor 172.19.1.6 next-hop-self neighbor 172.19.1.6 send-community neighbor 172.19.1.6 soft-reconfiguration inbound neighbor 172.19.1.6 prefix-list CE2_1 in neighbor 172.19.1.6 route-map COLORIZE_IN in neighbor 172.19.1.6 filter-list 2 in neighbor 172.19.1.6 route-map STRIP_COLORS_OUT out neighbor 172.19.1.6 filter-list 1 out neighbor 172.19.255.3 remote-as 65001 neighbor 172.19.255.3 update-source Loopback0 neighbor 172.19.255.3 next-hop-self neighbor 172.19.255.3 send-community neighbor 172.19.255.3 soft-reconfiguration inbound no auto-summary

2PE1_RRC:

router bgp 65001 no synchronization bgp router-id 172.19.255.8 bgp log-neighbor-changes neighbor 172.19.2.2 remote-as 65102 neighbor 172.19.2.2 next-hop-self neighbor 172.19.2.2 send-community neighbor 172.19.2.2 soft-reconfiguration inbound neighbor 172.19.2.2 prefix-list CE1_2 in neighbor 172.19.2.2 route-map COLORIZE_IN in neighbor 172.19.2.2 filter-list 2 in neighbor 172.19.2.2 route-map STRIP_COLORS_OUT out neighbor 172.19.2.2 filter-list 1 out neighbor 172.19.255.7 remote-as 65001 neighbor 172.19.255.7 update-source Loopback0 neighbor 172.19.255.7 next-hop-self neighbor 172.19.255.7 send-community neighbor 172.19.255.7 soft-reconfiguration inbound no auto-summary

2PE2_RRC:

router bgp 65001 no synchronization bgp router-id 172.19.255.9 bgp log-neighbor-changes neighbor 172.19.2.6 remote-as 65202 neighbor 172.19.2.6 next-hop-self neighbor 172.19.2.6 send-community neighbor 172.19.2.6 soft-reconfiguration inbound neighbor 172.19.2.6 prefix-list CE2_2 in neighbor 172.19.2.6 route-map COLORIZE_IN in neighbor 172.19.2.6 filter-list 2 in neighbor 172.19.2.6 route-map STRIP_COLORS_OUT out neighbor 172.19.2.6 filter-list 1 out neighbor 172.19.255.7 remote-as 65001 neighbor 172.19.255.7 update-source Loopback0 neighbor 172.19.255.7 next-hop-self neighbor 172.19.255.7 send-community neighbor 172.19.255.7 soft-reconfiguration inbound no auto-summary

EXT_PE_RRC:

router bgp 65001 no synchronization bgp router-id 172.19.255.6 bgp log-neighbor-changes neighbor 172.19.253.2 remote-as 65002 neighbor 172.19.253.2 next-hop-self neighbor 172.19.253.2 send-community neighbor 172.19.253.2 soft-reconfiguration inbound neighbor 172.19.253.2 route-map COLORIZE_IN in neighbor 172.19.253.2 filter-list 2 in neighbor 172.19.253.2 route-map STRIP_COLORS_OUT out neighbor 172.19.253.2 filter-list 1 out neighbor 172.19.255.1 remote-as 65001 neighbor 172.19.255.1 description Core_RR1 neighbor 172.19.255.1 update-source Loopback0 neighbor 172.19.255.1 next-hop-self neighbor 172.19.255.1 send-community neighbor 172.19.255.1 soft-reconfiguration inbound neighbor 172.19.255.2 remote-as 65001 neighbor 172.19.255.2 description Core_RR2 neighbor 172.19.255.2 update-source Loopback0 neighbor 172.19.255.2 next-hop-self neighbor 172.19.255.2 send-community neighbor 172.19.255.2 soft-reconfiguration inbound no auto-summary

The only other thing we can add is the complete configurations of all devices, archived and accessible over the links below.

Complete configurations

(back to top)

Tags: as-path filters, BGP, BGP Communities, eBGP, iBGP, prefix-lists, route reflectors, route-maps

Tuesday, November 3rd, 2009 EGPs, Routing

No comments yet.

Българска версия

NetNotes

Data/Voice/Video networking, TCP/IP Routing/Switching, Cisco networking

Sample transit BGP core configuration

Leave a comment

Chat

Recent Posts

Recent Comments

Categories

Pages

Archives

November 2009
M	T	W	T	F	S	S
« Oct
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30