Posts from ‘BGP’
Riddle me this BGP man…
Our BGP class is coming up! This class is for learners who are pursuing the CCIP track, or simply want to really master BGP. I have been working through the slides, examples and demos that we’ll use in class, and it is going to be excellent. 
If you can’t make the live event, we are recording it, so it will be available as a class on demand, after the live event. More information, can be found by clicking here.
One of the common questions that comes up is “Why does the router choose THAT route?
We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the “best” path.
So now for the question. Take a look at the partial output of the show command below: Continue Reading
Last week we wrapped up the MPLS bootcamp, and it was a blast! A big shout out to all the students who attended, as well as to many of the INE staff who stopped by (you know who you are ). Thank you all.
Here is the topology we used for the class, as we built the network, step by step.
The class was organized and delivered in 30 specific lessons. Here is the “overview” slide from class: Continue Reading
It isn’t my fault, they configured it that way before I got here! That was the entry level technician’s story Monday morning, and he was sticking to it.
Here is the rest of the story. Over the weekend, some testing had been done regarding a proposed BGP configuration. The objective was simple, R1 and R3 needed to ping each others loobacks at 1.1.1.1 and 3.3.3.3 respectively, with those 2 networks, being carried by BGP. R2 is performing NAT. The topology diagram looks like this:
The ping between loopbacks didn’t work, but R1 and R3 had these console messages:
R1# %TCP-6-BADAUTH: No MD5 digest from 10.0.0.3(179) to 10.0.0.1(28556) (RST) Continue Reading
One of our students in the INE RS bootcamp today, asked about an OSPF sham-link. I thought it would make a beneficial addition to our blog, and here it is. Thanks for the request Christian!
Reader’s Digest version: MPLS networks aren’t free. If a customers is using OSPF to peer between the CE and PE routers, and also has an OSPF CE to CE neighborship, the CE’s will prefer the Intra-Area CE to CE routes (sometimes called the “backdoor” route in this situation), instead of using the Inter-Area CE to PE learned routes that use the MPLS network as a transit path. OSPF sham-links correct this behavior.
This blog post walks through the problem and the solution, including the configuration steps to create and verify a sham-link.
To begin, MPLS is set up in the network as shown with R2 and R4 acting as Provider Edge (PE) routers, and MPLS is enabled throughout R2-R3-R4.
R1 and R5 are Customer Edge (CE) routers, and the Serial0/1.15 interfaces of R1 and R5 are temporarily shut down, (this means the backdoor route isn’t in place yet, and at the moment, there is no problem).
Currently, R1 and R5 see the routes to each others local networks through the VPNv4 MPLS network, and the routes show up as Inter-Area OSPF routes with the PE routers as the next hop. Continue Reading
Having a blast in Chicago with the RS bootcamp students. Thanks for all the hard work you are doing this week!
A student from a past Reno class, named Michal, asked if I would create a blog post regarding BGP proportional load balancing based on the bandwidth of the links to EBGP peers. It has been on my list of things to do, and here it is. Thanks for the request Michal.
The secret to this trick is to pay attention to the links between directly connected external BGP neighbors, (in this case between R6-R5 and R2-R3), and send the link bandwidth extended community attribute to iBGP peer R1. It is enabled by entering the bgp dmzlink-bw command and using extended communities to share the information. To summarize: routes learned from directly connected external neighbor are advertised to IBGP peers including the bandwidth of the external link where the routes were learned, and then the IBGP router (R1) can proportionally load balance between the two paths.
Here is the diagram we will use.
We’ll use loobpacks for our IBGP connections, so let’s verify that we have connectivity between loopbacks in AS 123. Continue Reading
Introduction
In this series of posts, we are going to review some interesting topics illustrating unexpected behavior of the BGP routing protocol. It may seem that BGP is a robust and stable protocol, however the way it was designed inherently presents some anomalies in optimal route selection. The main reason for this is the fact that BGP is a path-vector protocol, much like a distance-vector protocol with optimal route selection based on policies, rather than simple additive metrics.
The fact that BGP is mainly used for Inter-AS routing results in different routing policies used inside every AS. When those different policies come to interact, the resulting behavior might not be the same as expected by individual policy developers. For example, prepending the AS_PATH attribute may not result in proper global path manipulation if an upstream AS performs additional prepending.
In addition to that, BGP was designed for inter-AS loop detection based on the AS_PATH attribute and therefore cannot detect intra-AS routing loops. Optimally, intra-AS routing loops could be prevented by ensuring a full mesh of BGP peering between all routers in the AS. However, implementing full-mesh is not possible for a large number of BGP routers. Known solutions to this problem – Route Reflectors and BGP Confederations – prevent all BGP speakers from having full information on all potential AS exit points due to the best-path selection process. This unavoidable loss of additional information may result in suboptimal routing or routing loops, as illustrated below.
Tags: anomalies, bgp, ccie, CCNP, routing loops
Abstract:
Inter-AS Multicast VPN solution introduces some challenges in cases where peering systems implement BGP-free core. This post illustrates a known solution to this problem, implemented in Cisco IOS software. The solution involves the use of special MP-BGP and PIM extensions. The reader is assumed to have understanding of basic Cisco’s mVPN implementation, PIM-protocol and Multi-Protocol BGP extensions.
Abbreviations used
mVPN – Multicast VPN
MSDP – Multicast Source Discovery Protocol
PE – Provider Edge
CE – Customer Edge
RPF – Reverse Path Forwarding
MP-BGP – Multi-Protocol BGP
PIM – Protocol Independent Multicast
PIM SM – PIM Sparse Mode
PIM SSM – PIM Source Specific Multicast
LDP – Label Distribution Protocol
MDT – Multicast Distribution Tree
P-PIM – Provider Facing PIM Instance
C-PIM – Customer Facing PIM Instance
NLRI – Network Layer Rechability Information
Inter-AS mVPN Overview
Tags: bgp, ccie sp, mdt safi, multicast vpn, rpf proxy
Hi Brian,
I’m having a problem with Workbook Volume 1 Version 4.1. ORF (Outbound Route Filtering) isn’t working for me. Any help would be appreciated.
Thank you,
JoeT
Hi Joe,
First off let’s talk a little bit about what BGP ORF (Outbound Route Filtering) is designed to do for us, and then we’ll take a look at some implementation examples.
From a customer’s point of view there are typically a limited amount of choices for what routes you can receive from your Service Provider via BGP. Usually the Service provider will give the customer the option of sending them a full table view (currently about 260,000 prefixes), just a default route, or some specific subset of the table such as a default route and the Service Provider’s locally originated prefixes. In other words a BGP Service Provider generally will not implement a complex outbound filtering policy for the customer. Instead, if the customer wants to receive just a subset view of the BGP table, the Customer Edge (CE) router has to filter prefixes inbound as they are received from the upstream Provider Edge (PE) router.
From the SP’s point of view this is the optimal design for administration. They don’t need to worry about change requests constantly coming from the customer about what routes they want to see and what routes they don’t want to see. Likewise from the customer’s point of view this is the optimal administrative design, as they do not need to send change control requests to the provider, and can arbitrarily change their filtering design on the fly. However from a device resource point of view this is not optimal from both the PE and CE routers’ perspective. The SP’s PE router must still send the full BGP table to the customer, even if the CE router filters out 99% of it. Likewise the CE router must still process all of the BGP UPDATE messages, even if the majority of them are ultimately filtered out.
Let’s take this a look at the result of this in the context of the following design:
AS100 — AS200
(PE) -– (CE)
AS 200 has an upstream peering to its Service Provider, AS 100. The BGP table of AS 200 appears as follows:
AS200_CE#show ip bgp
BGP table version is 12, local router ID is 10.0.0.200
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.0.0.100 0 0 100 i
*> 28.119.16.0/24 10.0.0.100 0 100 54 i
*> 28.119.17.0/24 10.0.0.100 0 100 54 i
*> 112.0.0.0 10.0.0.100 0 100 54 50 60 i
*> 113.0.0.0 10.0.0.100 0 100 54 50 60 i
*> 114.0.0.0 10.0.0.100 0 100 54 i
*> 115.0.0.0 10.0.0.100 0 100 54 i
*> 116.0.0.0 10.0.0.100 0 100 54 i
*> 117.0.0.0 10.0.0.100 0 100 54 i
*> 118.0.0.0 10.0.0.100 0 100 54 i
*> 119.0.0.0 10.0.0.100 0 100 54 i
Let’s suppose that from AS 200’s perspective the only routes that they want to receive from AS 100 are the default route plus the networks 28.119.16.0/24 and 28.119.17.0/24. Traditional filtering would dictate that on the CE router a prefix-list would be configured and applied as follows:
router bgp 200 neighbor 10.0.0.100 remote-as 100 neighbor 10.0.0.100 prefix-list AS_100_INBOUND in ! ip prefix-list AS_100_INBOUND seq 5 permit 0.0.0.0/0 ip prefix-list AS_100_INBOUND seq 10 permit 28.119.16.0/24 ip prefix-list AS_100_INBOUND seq 15 permit 28.119.17.0/24
The result of this configuration in AS 200’s BGP table is as follows:
AS200_CE#show ip bgp
BGP table version is 4, local router ID is 10.0.0.200
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.0.0.100 0 0 100 i
*> 28.119.16.0/24 10.0.0.100 0 100 54 i
*> 28.119.17.0/24 10.0.0.100 0 100 54 i
Although the filtering goal is achieved, efficiency is not. From the below debug output we can see exactly how AS 200’s CE router processes the updates from the upstream PE and makes a decision on what to install:
AS200_CE#debug ip bgp updates BGP updates debugging is on for address family: IPv4 Unicast AS200_CE#clear ip bgp 100 %BGP-5-ADJCHANGE: neighbor 10.0.0.100 Down User reset %BGP-5-ADJCHANGE: neighbor 10.0.0.100 Up BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100 BGP(0): 10.0.0.100 rcvd 0.0.0.0/0 BGP(0): Revise route installing 1 of 1 routes for 0.0.0.0/0 -> 10.0.0.100(main) to main IP table BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54 BGP(0): 10.0.0.100 rcvd 115.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): 10.0.0.100 rcvd 114.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54 BGP(0): 10.0.0.100 rcvd 119.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): 10.0.0.100 rcvd 118.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): 10.0.0.100 rcvd 117.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): 10.0.0.100 rcvd 116.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54 BGP(0): 10.0.0.100 rcvd 28.119.17.0/24 BGP(0): 10.0.0.100 rcvd 28.119.16.0/24 BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54 50 60 BGP(0): 10.0.0.100 rcvd 113.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): 10.0.0.100 rcvd 112.0.0.0/8 -- DENIED due to: distribute/prefix-list; BGP(0): Revise route installing 1 of 1 routes for 28.119.16.0/24 -> 10.0.0.100(main) to main IP table BGP(0): Revise route installing 1 of 1 routes for 28.119.17.0/24 -> 10.0.0.100(main) to main IP table AS200_CE#
Note that the AS200_CE router generates the log message “DENIED due to: distribute/prefix-list;” for every prefix that is filtered. This means that if this were the public BGP table of 260,000+ routes this router would have to process every update message just to discard it. This is where BGP Outbound Route Filtering (ORF) comes in.
Outbound Route Filtering Capability for BGP-4 is currently an IETF draft (http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-16.txt) that describes an optimization on how prefix filtering can occur between a Customer Edge (CE) router and a Provider Edge (PE) router that are exchanging IPv4 unicast BGP prefixes. In the design we saw above the upstream PE router sent the full BGP table downstream to the CE router, and filtering was applied inbound on the downstream CE. With BGP ORF the downstream CE router dynamically tells the upstream PE router what routes to filter *outbound*. This means that the downstream CE router will only receive update messages about the prefixes that it wants.
Implementation wise the first step of this feature is for the BGP neighbors to negotiate that they both support the BGP ORF capability. Configuration-wise this looks as follows:
AS100_PE# router bgp 100 neighbor 10.0.0.200 remote-as 200 ! address-family ipv4 neighbor 10.0.0.200 capability orf prefix-list receive neighbor 204.12.25.254 activate exit-address-family AS200_CE# router bgp 200 neighbor 10.0.0.100 remote-as 100 ! address-family ipv4 neighbor 10.0.0.100 capability orf prefix-list send neighbor 10.0.0.100 prefix-list AS_100_INBOUND in exit-address-family !
The result of this configuration on AS 200’s CE is the same, however the behind the scenes mechanism by which it is accomplished is different. First, AS100_PE and AS200_CE negotiate the BGP ORF capability during initial BGP peering establishment. The success of this negotiation can be seen as follows.
AS100_PE#show ip bgp neighbors 10.0.0.200 | begin AF-dependant capabilities:
AF-dependant capabilities:
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: received
Receive-mode: advertised
Outbound Route Filter (ORF): received (3 entries)
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 2 0
Prefixes Total: 2 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
ORF prefix-list: 8 n/a
Total: 8 0
Number of NLRIs in the update sent: max 4, min 2
*OUTPUT OMITTED*
AS200_CE#show ip bgp neighbors 10.0.0.100 | begin AF-dependant capabilities:
AF-dependant capabilities:
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: advertised
Receive-mode: received
Outbound Route Filter (ORF): sent;
Incoming update prefix filter list is AS_100_INBOUND
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 3 (Consumes 156 bytes)
Prefixes Total: 0 4
Implicit Withdraw: 0 1
Explicit Withdraw: 0 0
Used as bestpath: n/a 3
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Suppressed duplicate: 0 1
Bestpath from this peer: 3 n/a
Total: 3 1
Number of NLRIs in the update sent: max 0, min 0
*OUTPUT OMITTED*
Next, AS 200’s CE router tells AS 100’s PE router which prefixes it wants to receive. The logic of this configuration is that AS 200 is “sending” a prefix-list of what routes it wants, while AS 100 is “receiving” the prefix-list of what the downstream neighbor wants. The reception of the prefix-list by the upstream PE can be verified as follows.
AS100_PE#show ip bgp neighbors 10.0.0.200 received prefix-filter Address family: IPv4 Unicast ip prefix-list 10.0.0.200: 3 entries seq 5 permit 0.0.0.0/0 seq 10 permit 28.119.16.0/24 seq 15 permit 28.119.17.0/24 AS100_PE#show ip prefix-list
Note that AS 100’s PE router received the list from AS 200’s CE, but the prefix-list does not show up locally in the running config. AS 100’s PE router then turns around and uses the prefix-list as an outbound filter towards the downstream CE. This can be verified two ways, by viewing the UPDATE messages on the downstream CE, and by looking at what the upstream PE is sending.
AS100_PE#show ip bgp neighbors 10.0.0.200 advertised-routes
BGP table version is 11, local router ID is 10.0.0.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Originating default network 0.0.0.0
Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 204.12.25.254 0 0 54 i
*> 28.119.17.0/24 204.12.25.254 0 0 54 i
Total number of prefixes 2
AS100_PE#
AS200_CE#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
AS200_CE#clear ip bgp 100
AS200_CE#
BGP(0): no valid path for 0.0.0.0/0
BGP(0): no valid path for 28.119.16.0/24
BGP(0): no valid path for 28.119.17.0/24
%BGP-5-ADJCHANGE: neighbor 10.0.0.100 Down User reset
BGP(0): nettable_walker 0.0.0.0/0 no best path
BGP(0): nettable_walker 28.119.16.0/24 no best path
BGP(0): nettable_walker 28.119.17.0/24 no best path
%BGP-5-ADJCHANGE: neighbor 10.0.0.100 Up
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100
BGP(0): 10.0.0.100 rcvd 0.0.0.0/0
BGP(0): Revise route installing 1 of 1 routes for 0.0.0.0/0 -> 10.0.0.100(main) to main IP table
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54
BGP(0): 10.0.0.100 rcvd 28.119.17.0/24
BGP(0): 10.0.0.100 rcvd 28.119.16.0/24
BGP(0): Revise route installing 1 of 1 routes for 28.119.16.0/24 -> 10.0.0.100(main) to main IP table
BGP(0): Revise route installing 1 of 1 routes for 28.119.17.0/24 -> 10.0.0.100(main) to main IP table
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100
BGP(0): 10.0.0.100 rcvd 0.0.0.0/0...duplicate ignored
AS200_CE#
Note that the above output is different from the previous debug of AS 200’s CE, because now it does not receive the extra update messages. AS 200 instead now receives only the routes that it has requested of the upstream PE.
If edits of the filter are required the downstream CE can change the prefix-list, and then through the BGP Route Refresh capability, advertise the new prefix-list upstream to the PE to be used as a new downstream filter. Configuration wise this is accomplished as follows.
AS200_CE#conf t Enter configuration commands, one per line. End with CNTL/Z. AS200_CE(config)#ip prefix-list AS_100_INBOUND permit 114.0.0.0/8 AS200_CE(config)#end AS200_CE# %SYS-5-CONFIG_I: Configured from console by console AS200_CE#clear ip bgp 100 in prefix-filter AS200_CE# BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54 BGP(0): 10.0.0.100 rcvd 114.0.0.0/8 BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54 BGP(0): 10.0.0.100 rcvd 28.119.17.0/24...duplicate ignored BGP(0): 10.0.0.100 rcvd 28.119.16.0/24...duplicate ignored BGP(0): Revise route installing 1 of 1 routes for 114.0.0.0/8 -> 10.0.0.100(main) to main IP table BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100 BGP(0): 10.0.0.100 rcvd 0.0.0.0/0...duplicate ignored AS200_CE#
From the “debug ip bgp updates” output we can now see that the upstream PE added the update 114.0.0.0/8, in addition to the previous three prefixes that were installed. Upstream verification on the PE also indicates this.
AS100_PE#show ip bgp neighbors 10.0.0.200 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 10.0.0.200: 4 entries
seq 5 permit 0.0.0.0/0
seq 10 permit 28.119.16.0/24
seq 15 permit 28.119.17.0/24
seq 20 permit 114.0.0.0/8
AS100_PE#show ip bgp neighbors 10.0.0.200 advertised-routes
BGP table version is 11, local router ID is 10.0.0.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Originating default network 0.0.0.0
Network Next Hop Metric LocPrf Weight Path
*> 28.119.16.0/24 204.12.25.254 0 0 54 i
*> 28.119.17.0/24 204.12.25.254 0 0 54 i
*> 114.0.0.0 204.12.25.254 0 54 i
Total number of prefixes 3
AS100_PE#
For more information on this feature:
Outbound Route Filtering Capability for BGP-4
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-16.txt
BGP Prefix-Based Outbound Route Filtering
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11borf.html
Tags: filtering, iewb, orf, prefix-list, sample
Sometimes people need to conditionally advertise routes into BGP table based on time of day. Say, we may want to adversite IGP prefix 150.1.1.0/24 with community 1:100 during daytime and with community 1:200 at the other time. Back in days, the procedure was easy – you had to create time based ACL, and use it in route-map to set communities:
time-range DAY periodic daily 9:00 to 18:00 access-list 101 permit ip any any time-range DAY route-map SET_COMMUNITY 10 match ip address 101 set community 1:100 ! route-map SET_COMMUNITY 20 set community 1:200
This construct worked fine back in days with 12.2T and 12.3 IOSes up to 12.3(17)T. However, since 12.3(17)T, BGP scanner behavior has changed significally. Up to the new version, redistribution into BGP table was based on BGP scanner periodically polling the IGP routes every scan-interval (one minute by default). With the new IOS code, redistribution is purely event driven: a new route is added/deleted from BGP table based on event, signaled by IGP (e.g. IGP route withdrawn, next-hop change etc). This change in BGP scanner behavior was not clearly documented, unlike the related BGP support for next-hop address tracking feature. Ovbsiously, a change in time-range is not treated as an IGP event, hence the filter does not work anymore.
Still, there is a number of workarounds. Here is one of them: we use time-based ACL to filter or permit ICMP packets, and advertise routers based on that virtual “reachability” info.
First, we create time-range and time-based access-list:
time-range DAY periodic daily 9:00 to 18:00 ! access-list 101 permit ip any any time-range DAY
Next we create a special loopback interface, which is used send ICMP echo packets to “ourself” and attach the ACL to the interface to filter incoming (looped back) packets:
interface Loopback0 ip address 150.1.1.1 255.255.255.255 ip access-group 101 in
We create a new IP SLA monitor, to send ICMP echo packets over loopback interface. If the time-based ACL permit pings, the monitor state will be “reachable”
ip sla monitor 1 type echo protocol ipIcmpEcho 150.1.1.1 timeout 100 frequency 1
Next we track our “pinger” state. The first tracker is “on” when the loopback is “open” by packet filter, the second one is active when the time-based ACL filters packets:
track 1 rtr 1 reachability ! ! Inverse logic ! track 2 list boolean and object 1 not
The we create two static routes, bound to the mentioned trackets. That is, the static route with tag 100 is only active when loopback is “open”, i.e. time-based ACL permits packets. The other static route is active only when time-range is inactive (the second tracker tells that the destination is “reachable”):
ip route 150.1.1.0 255.255.255.0 Loopback0 150.1.1.254 tag 100 track 1 ip route 150.1.1.0 255.255.255.0 Loopback0 150.1.1.253 tag 200 track 2
Now we redistribute static routes into BGP, based on tag values, and also set communities based on the tags:
router bgp 1 redistribute static route-map STATIC_TO_BGP ! route-map STATIC_TO_BGP permit 10 match tag 100 set community 1:100 ! route-map STATIC_TO_BGP permit 20 match tag 200 set community 1:200
This is also a funny example of how you can tie up together multiple IOS features at the same time.
For inbound updates the order of preference is:
1. route-map
2. filter-list
3. prefix-list, distribute-list
For outbound updates the order of preference is:
1. prefix-list, distribute-list
2. filter-list
3. route-map
Loading ...
