- 1 Introduction
- 2 BGP States
- 3 BGP Messages
- 4 BGP Tables
- 5 Attributes
- 6 Filter with Route Maps
- 7 Route Reflector?
- 8 Confederation
- 9 Route Aggregation
- 10 Routing Information Base (RIB)
- 11 Community
- 12 Synchronization
- 13 Auto-Summarization
- 14 Next Hop Processing
- 15 BGP Split Horizon
- 16 Peer Groups
- 17 MED vs Local Preference vs Weight
- 18 ASPath Prepend
- 19 BGP Route Dampening
- 20 EBGP vs IBGP
- 21 Config Commands
- 22 Monitoring
- 23 Troubleshooting
- 24 R&S Quick Notes
- 25 LAB
- 26 References
- Protocol Specifications
|Protocol Type||Path vector|
|Peering mechanism||Manual peering between neighbors|
|Supported protocols||IPv4, IPv6|
|Update mode||Triggered(Internal 5s, External 30s)|
|Timers||Hello (60 sec)|
- Usage applications
BGP is needed for redundancy of servers. BGP is not used for providing redundancy to users for internet access. Customer connected to multiple Internet service providers (ISPs). Service provider networks (Transit autonomous system). Network cores of very large enterprise networks (distribution or core layer)as a backup or redundant routing protocol due to its stability.
- Customer's Network will become a Transit Autonomous system if ISP traffic passes through your AS.
- Session Establishment facts
BGP neighbors are not discovered. They must be configured manually on both sides of the connection. TCP port 179 is used. Only one session remains if both connection attempts succeed.
- Without tuning behaves like RIP, considers AS as a Hop.
- BGP is an advanced Path Vector Protocol and has following advantages:
Reliable updates (using TCP) Triggered updates only Rich metric (Path attributes) Scalable to massive networks Updates are Incremental and Triggered
- Only 1 instance of BGP can be run on a router. It will show an error if running it with another AS Number.
Idle Neighbor is not responding/Verifying Route to neighbor Active Attempting to connect Connect TCP session established OpenSent Open message sent OpenConfirm Neighbor replied with Open Message Active(2nd) Neighbor failed to reply or Mismatched Parameter Established Adjacency established
Open Starts the Session Update Network Reachability Exchanges Keepalive Sent every 60 seconds Notification Always indicate something is wrong
Neighbor Table Configured/Connected BGP Peers BGP Table List of All BGP Routes(Can be Huge) Routing Table List of Best Routes
- Full Internet BGP routing table is more than 300K routes and a BGP router can receive multiple copies of that routing table from multiple providers, router has to compare those multiple entries and select only the best route for the routing table.
- It uses the BGP Best Path Selection Algorithm to do this.
- Routes installed by different BGP instances are compared by the general algorithm, i.e. route distances are compared and the route with lower distance is preferred.
Well known BGP attribute types:
Well-known mandatory: Attributes of this type must be understood by all BGP implementations and must EXIST in the BGP update messages. Well-known discretionary: Attributes of this type must be understood by all BGP implementations but they don’t have to exist in all BGP updates to all neighbors.
Optional BGP attribute types:
Optional transitive: optional BGP attributes as the name implies don’t need to be understood by all BGP implementations, but since the transitive flag is set they will be passed to other neighbors. Optional non-transitive: Attributes of this type are also optional as the name implies and will not be passed to other neighbors.
|Attribute||Which is better|
|Next Hop reachable||Route cannot be used if next hop is unreachable||Well-known Mandatory|
|Local Preference||Bigger||Well-known discretionary|
|Locally Injected||Locally injected is better than iBGP/eBGP learned|
|AS Path Length||Smaller||Well-known mandatory|
|Origin||Prefer IGP(network cmd) > EGP > ?(reditributed)||Well-known Mandatory|
|Neighbor Type||Prefer eBGP over iBGP|
|IGP Metric to Next Hop||Smaller|
- Origin - Prefer Internal(advertised by network cmd - 'i') over External(advertised by redistribe cmd -'?')
Aspath prepend: Applied outwardly. Impacts incoming path. Shorter the as-path length higher the preference As-path prepend is the way to add AS number to the list of subnet u want to advertise. This is a way to route poisoning. Tell the outside world not to follow the path.
Local preference: Applied while the traffic coming inside. Impacts traffic while going out. Non transitive. Propagates within the same as-path. Higher the local preference value higher the preference
MED: Multiexitdescriptor When your router has connection with two other routers with same AS. Let's say you have 2 subnets behind your router. You can use MED value to mention which networks should be accessed through which links. It is advertised outwards. Impacts the incoming traffic. Semi transitive. Propagates to one AS. Lower the MED value higher the preference. MED should be used carefully as it reduces network resiliency.
Filter with Route Maps
- Route maps are very powerful filtering tools, they can be used to accomplish the following tasks:
Filter on IP prefixes coming from a specific autonomous system Filter on other BGP attributes Modify BGP attributes
- Match clauses in the BGP route map can be based on the following:
IP network numbers and subnet masks (prefix list or access list) Route originator Next hop Origin code Tag value attached to an Interior Gateway Protocol (IGP) route Autonomous system path Community IGP route type
- With a route map, the following can be set:
Origin Next hop Weight Community Local preference MED
- You can apply a route map on incoming or outgoing routing information for a neighbor.
- The routing information must be permitted by the route map to be accepted.
- If the route map has no statement explicitly permitting a route, the route is implicitly denied and dropped.
- The syntax required is as follows:
Router(config-router)# neighbor ip-address route-map name in|out
- Any route received from an iBGP neighbor must not be advertised to any other iBGP neighbor.
- This requires all iBGP routers be connected in logical full mesh topology, which is not scalable.
Two solution possible:
BGP confederations Route reflectors
- A route reflector is BGP router that is allowed to break the iBGP loop avoidance rule.
- Route reflectors can advertise updates received from an iBGP peer to another iBGP peer.
- This allow for building iBGP networks that scale easily.
- IBGP routers are divided into:
Route Reflectors Route Reflector Clients Non-Client Peers
- Routes received from:
RR-client is reflected to other clients and non-client neighbors Non-client neighbors are reflected to Route-Reflector-client neighbors only
- An RR reflecting the route received from a RR-Client adds:
Originator ID - Router ID of the originator of the route in the local AS. If the update comes back to the originator, it ignores the update. Cluster List - Router ID of RR. A list of Cluster IDs that an update has traversed. When a RR sends a route received from a client to a non-client, it appends the local Cluster ID. If a RR receives a route whose Cluster List contains the local Cluster ID, it ignores the update.
- RR reflects routes considered as best routes only.
- If more than one update is received for the same destination only the BGP best route is reflected.
- RR is not allowed to change any attributes of the reflected routes including the next-hop attribute.
- Loop Prevention:
If a router received an iBGP route with the Originator-ID attribute set to its own router-id, the route is discarded. If a route reflector receives a route with a cluster-list attribute containing its cluster-id, the route is discarded.
- RR1 router
router bgp 100 neighbor 172.16.1.2 remote-as 100 neighbor 172.16.1.2 route-reflector-client neighbor 172.16.1.2 description Client1
- Client1 router
router bgp 100 neighbor 172.16.1.1 remote-as 100 neighbor 172.16.1.1 description RR1 network 184.108.40.206 mask 255.255.255.255 --> Route to be reflected
- RR does not require major changes to existing configuration
- It implies choosing routers that will act as a focal point for iBGP sessions within a single AS, running a single IGP.
- Confederations needs quite a config change and architecture.
- Confederations may contain different IGPs, adding more flexibility to scaling your network.
- In case your IGP is exceeding its scalability limit and becomes unmanageable, use Confederation.
- A method to subdivide a single AS into multiple internal sub-AS's, yet still advertise as a single AS to external peers.
- The intent is to reduce iBGP mesh size, scalable approach for a large autonomous system.
- Each of Sub-AS has its own AS number.
- Reduces the total number of iBGP peering sessions per router within AS.
- Large no of iBGP sessions can consume bandwidth and cause high CPU utilization, so negatively affect the performance.
- Each sub-AS has different AS number.
- All peers in sub-AS are fully meshed in order to learn external routes from external sources.
- Every sub-AS is identified by its unique AS number(private: 64512 – 65535), the connection between them is always eBGP peering called Intra-Confederation eBGP.
- eBGP routes between sub-ASs called Confederation External Routes, are preferred over iBGP routes.
- If BGP has to choose between two paths, one leading inside sub-AS and other outside sub-AS, within confederation, it will choose the external path – to neighboring sub-AS.
- To choose between Confederation eBGP route and eBGP route leading outside of confederation, BGP will choose the second one.
- AS_PATH attribute contains AS_CONFED_SET parameter which is modified inside the confederation only
- In case the confederation runs one IGP, NEXT_HOP, MED, LOCAL_PREF do not change when routing update traverses Intra-Confederation eBGP
|This section is under construction.|
Routing Information Base (RIB)
BGP Routing Information Base consists of three parts as explained below:
The Adj-RIBs-In: BGP RIB-In stores BGP routing information received from different peers. The stored information is used as an input to BGP decision process. In other words this is the information received from peers before applying any attribute modifications or route filtering to them. The Local RIB: The local routing information base stores the resulted information from processing the RIBs-In database’s information. These are the routes that are used locally after applying BGP policies and decision process. The Adj-RIBs-out: This one stores the routing information that was selected by the local BGP router to advertise to its peers through BGP update messages. Do not forget; BGP only advertises best routes if they are allowed by local outbound policies.
- A numerical value that can be assigned to a specific prefix and advertised to other neighbors.
- When the neighbor receives the prefix it will examine the community value and take proper action whether it is filtering or modifying other attributes.
- By default the community attribute is removed from the update before being sent to the neighbor.
- To allow community values to be sent to a specific neighbor
neighbor x.x.x.x send-community
- BGP has default 4 well known communities that can be used to mark prefixes:
Internet: advertise these routes to all neighbors. Local-as: prevent sending routes outside the local As within the confederation. No-Advertise: do not advertise this route to any peer, internal or external. No-Export: do not advertise this route to external BGP peers.
- Communities can be used to mark a set of prefixes that share a common property.
- Upstream providers can use these marks to apply a common routing policy such as filtering or assigning a specific local preference.
- Set community attribute values by:
Network command Aggregate address Neighbor command Redistribution
- R1 Config
ip bgp-community new-format route-map SETCOM set community 1:10 router bgp 12 neighbor 192.168.12.2 remote-as 12 neighbor 192.168.12.2 send-community network 220.127.116.11 mask 255.255.255.0 route-map SETCOM
- R2 Before applying any policies
R2# show ip bgp 18.104.22.168 BGP routing table entry for 22.214.171.124/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Not advertised to any peer Local 192.168.12.1 from 192.168.12.1 (192.168.127.1) Origin IGP, metric 0, localpref 100, valid, internal, best Community: 1:10
- R2 Config - Match the community using a standard community-list
ip community-list 1 permit 1:10 route-map COM match community 1 set metric 100 router bgp 12 neighbor 192.168.12.1 route-map COM in
- R2 After applying the policy
R2 #sh ip bgp 126.96.36.199/24 BGP routing table entry for 188.8.131.52/24, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x800 Not advertised to any peer Local 192.168.12.1 from 192.168.12.1 (192.168.127.1) Origin IGP, metric 100, localpref 100, valid, internal, best Community: 1:10
- Do not Use or Advertize to eBGP a route learned by iBGP unless the same has been learned by IGP as well.
- This is used to prevent the traffic form getting dropped by the intermediate routers, a method of circumventing black-holes in transit networks.
- This rule requires the redistribution of the BGP routes into the IGP in order to validate via the IGP.
- But this is non scalable due to size of Internet Routing Table therefore is disabled by default(since 12.2).
- To prevent black-holes in transit networks, iBGP needs to be run on all routers since BGP only can handle this amount of prefixes.
|This section is under construction.|
Next Hop Processing
eBGP: Changes next hop address on advertized routes. iBGP: Do not changes next hop address on advertized routes. iBGP was designed to be run in Frame Relay, Ethernet:
[R1] [R3] | | --------- | [R2]
Here if Peering is formed between R1-R2 & R2-R3. Traffic from R1 can reach R3 directly if the next hop IP is not changed. Else it needs to pass through R2 unnecessarily. Can be changed with: # neighbor 184.108.40.206 next-hop-self
BGP Split Horizon
Do not send updates that you receive from iBGP to other iBGP peers
neighbor IBGP_PEERS peer-group neighbor IBGP_PEERS remote-as 5500 neighbor IBGP_PEERS next-hop-self neighbor IBGP_PEERS update-source lo1
neighbor 220.127.116.11 peer-group IBGP_PEERS neighbor 18.104.22.168 peer-group IBGP_PEERS neighbor 22.214.171.124 peer-group IBGP_PEERS
MED vs Local Preference vs Weight
- Multi-Exit Discriminator
- The MED is an optional attribute that comes in handy when there are multiple entrance paths to an AS.
- The remote AS sets MED values to tell the other AS which path to use.
- The MED is passed between the two autonomous systems, but the value is not passed to any other ASs.
- The path with the lowest MED is the preferred path.
- This attribute is only used to influence entry INTO the AS.
- Local Preference
- LOCAL_PREF is a well-known attribute that is also used when multiple paths between autonomous systems exist.
- The LOCAL_PREF attribute is just that… local and exclusive to the AS.
- Routers within the local AS are told what path to use to exit that AS.
- The local preference value is passed only among iBGP peers, and this value never leaves the local AS.
- Weight is configured for Outgoing direction:
[R1]-------[R2] | |--------[R3]
If you want R1 to prefer R3, Configure more weight on R1 Configured on Per-Neighbor basis.
- Local Preference is configured in Incoming direction.
Configure Local Pref R3 so that R1 will prefer routes learned via R3. Local Pref stays inside AS only(use MED if you want to affect AS also). Configured for the whole BGP process on the router.
<--AS3--> <--AS100--> |------[R2]--------[R4] [R1] | |------[R3]--------[R5]
Weight R1 to R2 or R3:
Local Preference R2 to R1 or R3 to R1:
MED R4 to R2 or R5 to R3:
|This section is under construction.|
BGP Route Dampening
|This section is under construction.|
EBGP vs IBGP
|Peering is between two different AS||Peering is between same AS|
|Routes learned from eBGP peer will be advertised to other peers(EBGP or IBGP)||Routes learned from IBGP peer will not be advertised to other IBGP peers, can be advertised to EBGP peer.|
|EBGP peers are set with TTL = 1, neighbors are assumed to be directly connected.
Can change this behavior for EBGP by “neighbor x.x.x.x ebgp-multihop <TTL>”.
Multihop is the term used in EBGP only.
|For IBGP peers dont need to be directly connected.|
|Routes have AD of 20||Routes have AD of 200|
|Next hop is changed on advertised routers||Next-hop IP will not be changed when adv prefixes to another IBGP|
neighbor 126.96.36.199 weight 500
Temporarily disable a neighbor:
neighbor 188.8.131.52 shutdown
Clear BGP Process:
clear ip bgp *
|show ip bgp neighbor ip-address||Displays detailed neighbor information|
|show ip bgp||Displays all the routes in the BGP table|
|show ip bgp summary||Brief Neighbor Information|
|show ip bgp ip-prefix [mask subnet-mask]||Displays detailed information about all paths for a single prefix|
|debug ip tcp transactions||Displays all TCP transactions|
|debug ip bgp events||Displays significant BGP events|
|debug ip bgp keepalives||Debugs BGP keepalive packets|
|debug ip bgp updates||Displays all incoming or outgoing BGP updates|
|debug ip bgp updates acl||Displays all incoming and sent updates matching an ACL|
|debug up bgp ip-address update [acl]||Displays all BGP updates received from or sent to a specific neighbor|
- BGP route not installing, route reasons:
Synchronisation is enabled & route unknown by IGP(run 'no sync' command) Next Hop inaccessible (for iBGP run 'neighbor 184.108.40.206 next-hop-self' command) AS path includes the local AS Rejection by inbound policy
- Blackhole formed in iGBP if all internal routers not running BGP, Solution:
Redistribute into IGP: Full Routing Table redistribution not possible, Redistribute partial routing table/specific routes. Add a direct WAN Link between BGP Peers Run iBGP between Peers ?? Configure Route Reflector
- If any of the neighbors in below command output shows as in 'Active' state, it means some issue with the neighbor:
show ip bgp summary
- Use Loopback interface for forming peers in router having multiple links.
When using eBGP, peers will not come up when using loopback as they need to be directly connected and should not have a Hop. Use ebgp-multihop command to resovle this issue: # neighbor 220.127.116.11 ebgp-multihop 2
- There are 2 ways to advertise networks into BGP:
Network Command Redistribution
- When using Network command:
Below command will advertize 18.104.22.168/8 into BGP
Therefore advertize exact subnet only:
network 22.214.171.124 mask 255.255.255.0
- If the carot sign '>' is missing, the route is not the best one, so not installed in routing table:
* valid, > best, i - internal, r RIB-failure Network Next Hop Metric LocPrf Weight Path *> 10.1.1.1/32 0.0.0.0 0 32768 i *>i10.2.2.2/32 172.16.1.2 0 100 0 i
R&S Quick Notes
When using Communities, don’t forget “neighbor send-community” Know your attributes and the direction which applied, when to used what. “aggregate address” needs a more specific prefix in the BGP table for aggregate to be advertised. Synchronization issue has 3 solutions, 1- Load BGP on all transit routers, 2- GRE tunnel, 3- Redistribution BGP>IGP. “no bgp nexthop trigger” – Disables next-hop tracking between scanner intervals. “no bgp fast-ext-fallover” – Force the router to wait for the dead-timer to expire, before generating notification messages , when a connected peer goes down. “neighbor fall-over” – Will check neighbor connenctivity between scanner intervals, aka BGP Fast Peering. Only the Holdtime is sent in update-msg. Two neighbors will use the lowest holdtime and then calculate the keepalive from that. Know your Regular Expressions Know the difference between Peer-Groups and Peer-Templates
BGP Basic Lab
GNS3 File: File:cbt nuggets bgp lab.zip
- Configure iBGP & eBGP
- Establish Neighbors using Loopback interfaces
- Using Update-Source command
- Using eBGP-Multihop command
- Advertising Networks into BGP
- Turn off BGP Auto-Summary
- BGP Synchronization
- BGP Handling of Next Hop Address
- R1 Config
! interface Loopback1 ip address 126.96.36.199 255.255.255.255 ! ! interface Serial1/0 ip address 10.1.13.1 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.12.1 255.255.255.0 serial restart-delay 0 ! ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 ! router bgp 5500 no synchronization bgp log-neighbor-changes neighbor IBGP_PEERS peer-group neighbor IBGP_PEERS remote-as 5500 neighbor IBGP_PEERS update-source Loopback1 neighbor IBGP_PEERS next-hop-self neighbor 188.8.131.52 peer-group IBGP_PEERS neighbor 184.108.40.206 peer-group IBGP_PEERS neighbor 220.127.116.11 remote-as 5500 neighbor 18.104.22.168 update-source Loopback1 no auto-summary !
- R2 Config
! interface Loopback1 ip address 22.214.171.124 255.255.255.255 ! ! interface Serial1/0 ip address 10.1.24.1 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.12.2 255.255.255.0 serial restart-delay 0 ! ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 ! router bgp 5500 no synchronization bgp log-neighbor-changes neighbor IBGP_PEERS peer-group neighbor IBGP_PEERS remote-as 5500 neighbor IBGP_PEERS update-source Loopback1 neighbor IBGP_PEERS next-hop-self neighbor 126.96.36.199 peer-group IBGP_PEERS neighbor 188.8.131.52 peer-group IBGP_PEERS neighbor 184.108.40.206 peer-group IBGP_PEERS no auto-summary !
- R3 Config
! interface Loopback1 ip address 220.127.116.11 255.255.255.255 ! ! interface Serial1/0 ip address 10.1.13.2 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.34.1 255.255.255.0 serial restart-delay 0 ! ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 ! router bgp 5500 no synchronization bgp log-neighbor-changes neighbor IBGP_PEERS peer-group neighbor IBGP_PEERS remote-as 5500 neighbor IBGP_PEERS update-source Loopback1 neighbor IBGP_PEERS next-hop-self neighbor 18.104.22.168 peer-group IBGP_PEERS neighbor 22.214.171.124 peer-group IBGP_PEERS neighbor 126.96.36.199 peer-group IBGP_PEERS no auto-summary !
- R4 Config
! interface Loopback1 ip address 188.8.131.52 255.255.255.255 ! ! interface Serial1/0 ip address 10.1.24.2 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.34.2 255.255.255.0 serial restart-delay 0 ! interface Serial1/2 ip address 10.1.45.1 255.255.255.0 serial restart-delay 0 ! ! router ospf 1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 ! router bgp 5500 no synchronization bgp log-neighbor-changes neighbor IBGP_PEERS peer-group neighbor IBGP_PEERS remote-as 5500 neighbor IBGP_PEERS update-source Loopback1 neighbor IBGP_PEERS next-hop-self neighbor 184.108.40.206 peer-group IBGP_PEERS neighbor 220.127.116.11 update-source Loopback1 neighbor 18.104.22.168 peer-group IBGP_PEERS neighbor 22.214.171.124 peer-group IBGP_PEERS neighbor 126.96.36.199 remote-as 6500 neighbor 188.8.131.52 ebgp-multihop 2 neighbor 184.108.40.206 update-source Loopback1 no auto-summary ! ip route 220.127.116.11 255.255.255.255 10.1.45.2 ! !
- R5 Config
! interface Loopback0 ip address 18.104.22.168 255.255.255.255 ! interface Loopback1 ip address 22.214.171.124 255.255.255.255 ! interface Loopback2 ip address 126.96.36.199 255.255.255.255 ! interface Loopback3 ip address 188.8.131.52 255.255.255.255 ! interface Loopback4 ip address 184.108.40.206 255.255.255.255 ! interface Loopback5 ip address 220.127.116.11 255.255.255.255 ! interface Loopback6 ip address 18.104.22.168 255.255.255.0 ! interface Loopback7 ip address 22.214.171.124 255.255.255.255 ! interface Serial1/2 ip address 10.1.45.2 255.255.255.0 serial restart-delay 0 ! ! router bgp 6500 no synchronization bgp log-neighbor-changes network 126.96.36.199 mask 255.255.255.0 redistribute connected route-map FILTER neighbor 188.8.131.52 remote-as 5500 neighbor 184.108.40.206 ebgp-multihop 2 neighbor 220.127.116.11 update-source Loopback7 no auto-summary ! ip route 18.104.22.168 255.255.255.255 10.1.45.1 ! ! ! access-list 50 permit 22.214.171.124 access-list 50 permit 126.96.36.199 access-list 50 permit 188.8.131.52 access-list 50 permit 184.108.40.206 ! route-map FILTER permit 10 match ip address 50 !
BGP Attributes Lab
GNS3 Project File:CBT Nuggets BGP Attributes Lab.zip
Configure below Attributes:
Weight AS-Path Next Hop Address Origin Local Preference Metric
- R1 Config
! interface Serial1/0 ip address 10.1.12.1 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.13.1 255.255.255.0 serial restart-delay 0 ! ! router bgp 5500 no synchronization bgp log-neighbor-changes neighbor 10.1.12.2 remote-as 5500 neighbor 10.1.13.3 remote-as 5500 no auto-summary !
- R2 Config
! interface Serial1/0 ip address 10.1.12.2 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.23.2 255.255.255.0 serial restart-delay 0 ! interface Serial1/2 ip address 10.1.24.2 255.255.255.0 serial restart-delay 0 ! ! router bgp 5500 no synchronization bgp log-neighbor-changes neighbor 10.1.12.1 remote-as 5500 neighbor 10.1.12.1 next-hop-self neighbor 10.1.23.3 remote-as 5500 neighbor 10.1.24.4 remote-as 777 no auto-summary !
- R3 Config
! interface Serial1/0 ip address 10.1.23.3 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.13.3 255.255.255.0 serial restart-delay 0 ! interface Serial1/2 ip address 10.1.36.3 255.255.255.0 serial restart-delay 0 ! router bgp 5500 no synchronization bgp default local-preference 700 bgp log-neighbor-changes neighbor 10.1.13.1 remote-as 5500 neighbor 10.1.13.1 next-hop-self neighbor 10.1.23.2 remote-as 5500 neighbor 10.1.36.6 remote-as 777 neighbor 10.1.36.6 route-map LOCAL_PREF in default-metric 200 no auto-summary ! ! ip access-list standard ROUTES_FOR_R2 permit 220.127.116.11 0.255.255.255 ip access-list standard ROUTES_FOR_R3 permit 18.104.22.168 0.0.0.255 permit 22.214.171.124 0.0.0.255 ! route-map LOCAL_PREF permit 10 match ip address ROUTES_FOR_R3 set local-preference 1000 ! route-map LOCAL_PREF permit 20 match ip address ROUTES_FOR_R2 set local-preference 10 ! route-map LOCAL_PREF permit 30 !
- R4 Config
! interface Serial1/0 ip address 10.1.45.4 255.255.255.0 serial restart-delay 0 ! interface Serial1/2 ip address 10.1.24.4 255.255.255.0 serial restart-delay 0 ! router bgp 777 no synchronization bgp log-neighbor-changes neighbor 10.1.24.2 remote-as 5500 neighbor 10.1.45.5 remote-as 911 no auto-summary !
- R5 Config
! interface Loopback0 ip address 126.96.36.199 255.255.255.0 ! interface Loopback1 ip address 188.8.131.52 255.255.255.0 ! ! interface Serial1/0 ip address 10.1.45.5 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.57.5 255.255.255.0 serial restart-delay 0 ! ! router bgp 911 no synchronization bgp log-neighbor-changes redistribute connected route-map FILTER neighbor 10.1.45.4 remote-as 777 neighbor 10.1.57.7 remote-as 711 no auto-summary ! ! access-list 50 permit 184.108.40.206 access-list 50 permit 220.127.116.11 no cdp log mismatch duplex ! route-map FILTER permit 10 match ip address 50 !
- R6 Config
! interface Serial1/0 ip address 10.1.67.6 255.255.255.0 serial restart-delay 0 ! interface Serial1/2 ip address 10.1.36.6 255.255.255.0 serial restart-delay 0 ! ! router bgp 777 no synchronization bgp log-neighbor-changes neighbor 10.1.36.3 remote-as 5500 neighbor 10.1.67.7 remote-as 711 no auto-summary !
- R7 Config
! interface Ethernet0/0 ip address 18.104.22.168 255.255.255.0 half-duplex ! interface Ethernet0/1 ip address 22.214.171.124 255.255.255.0 half-duplex ! ! interface Serial1/0 ip address 10.1.67.7 255.255.255.0 serial restart-delay 0 ! interface Serial1/1 ip address 10.1.57.7 255.255.255.0 serial restart-delay 0 ! ! router bgp 711 no synchronization bgp log-neighbor-changes network 126.96.36.199 network 188.8.131.52 neighbor 10.1.57.5 remote-as 911 neighbor 10.1.67.6 remote-as 777 no auto-summary !
blog comments powered by Disqus