BGP CheatSheet.

While I was doing some casual surfing, this is what I found. It made me remind of the texbuddy charts that I use to use for my CCNA prep/quick revision. Well inspite of it being of very basic nature, I still thought its a good one.

Wouldn't we all love one for all the technologies including all the details about them at the CCIE level, I mean a one stop chart. Makes me wonder what that chart would be like!? Perhaps, its time for those CCIE course prep vendors to come up with. :P

And ya, all credits for the work go to Jeremy Stretch. If you want a pdf version of it you can get one from his site.

Internetwork Expert WB VOL 1 - BGP Lab 10

10)BGP Bestpath Selection – Origin

Objective: Modify the BGP Origin code in AS 2 so that traffic from R3’s Ethernet segment going to VLAN 5 is first sent to R1.

Ok, when it comes to ORIGIN ..here is the order of preference IGP-> EGP-> INCOMPLETE. Using this logic I first examined the routing table of R3 and configured it with the below shown configuration.

access-list 1 permit 155.1.5.0 0.0.0.255

route-map NEW_ORIGIN permit 10
set origin egp 1

router bgp 2
neighbor 155.1.0.5 route-map NEW_ORIGIN in
end

Worked like a charm, although over here the WB changes the ORIGIN to ? ie INCOMPLETE!! And also since our objective clearly says that this only needs to be done for traffic going to VLAN 5 from R3, it wouldn’t hurt to match on that specific network prefix using that mentioned access list 1. I just left it out here though, hmm ok next.

Internetwork Expert WB VOL 1 - BGP Lab 9

9)BGP Bestpath Selection – MED

Objective: Configure the BGP MED in AS 1 so that traffic from R3’s Ethernet segment going to VLAN 5 is first sent to R1.

Ok, this above objective is slightly tricky! Actually before I give my solution for this problem I would like to throw some quick light on concept of WEIGHT, LOCAL_PREFERENCE and MED.

Now this is what, WEIGHT is used for: When we have two paths/links ending up on a single router, and you want to influence the way your traffic leaves your AS from this router then you can make use of the WEIGHT attribute. Higher the value of WEIGHT, the more likelihood of that path being chosen or in other words higher the WEIGHT better it is.

LOCAL PREFERENCE, is just like WEIGHT ..the only difference here is that in case of WEIGHT its scope was restricted to a router which in case of LOCAL PREFERENCE is restricted to an entire AS! So, when we have multi-homed AS we can change the LOCAL PREFERENCE attribute to influence how traffic leaves our AS. Again higher the value of LOCAL PREFERENCE better it is.

In case of MED, it is an attribute that you use to manipulate how traffic enters your multi-homed AS! Lower value of MED the better it is, and scope is only limited to an AS.

Now, let us carefully read our objective ..What it is asking you is to influence the way traffic leaves AS 2 and you know you need to achieve this by using MED, but what you can’t do is change this value of MED on the routers of AS 2. Hence we change the value of MED on AS 1 routers and then have them send these changes in the outbound updates. This is the config that was done on R5 and R4, actually its really not required on R4 ..but no harm with some extra configuration and getting in lines with the objective.

On R5,

access-list 1 permit 155.1.37.0 0.0.0.255

route-map NEW_MED permit 10
match ip address 1
set metric 100

router bgp 1
neighbor 155.1.0.3 route-map NEW_MED out
end

And on R4,

access-list 1 permit 155.1.37.0 0.0.0.255

route-map NEW_MED permit 10
match ip address 1
set metric 50

router bgp 1
neighbor 155.1.146.1 route-map NEW_MED out
end

Right, now on to the next lab.

Internetwork Expert WB VOL 1 - BGP Lab 8

8)BGP Bestpath Selection – Local Preference

Objective: Configure the BGP Local Preference attribute in AS 2 so that traffic from R3’s Ethernet segment going to VLAN 5 is first sent to R1.

Ok, this was simple as well. Below is the config,

route-map NEW_LOCAL_PREF permit 10
match ip address 1
set local-preference 50

access-list 1 permit 155.1.5.0 0.0.0.255

router bgp 2
neighbor 155.1.0.5 route-map NEW_LOCAL_PREF in

I could have also, applied slightly different logic. Instead, increase the local-pref value for updates being received from R1. That also would have served the purpose.

Bgp topics to be covered!

1) Establishing Peerings

• TCP Transport
• Update Source

2) Authentication

3) EBGP

4) iBGP

• Route Reflection
• Confederation
• Next-Hop Processing

Next-Hop Self
Route-Map

• iBGP Synchronization

Redistribution into IGP
BGP over GRE

5) Bestpath Selection

• Weight
• Local Preference
• AS-Path Prepending
• MED

6) Originating Prefixes

• Network Statement
• Redistribution
• Aggregation

Summary-Only
Suppress-Map
Unsuppress-Map
Filtering Specifics
Filtering Aggregate

• Conditional Route Injection

7) Default Originate

8) Communities

• No-Export
• No-Advertise
• Local-AS
• Numbered
• New Format
• Local AS

9) Conditional Advertisement

10) Outbound Route Filtering

11) Dampening

12) Peer Groups

13) Regular Expressions

14) Remove Private AS

16) Timers

17) Fast External Fallover

18) Max Prefix

Hmm, I plan on completing all this in around next 12 days! Let's see how far can I get.

Internetwork Expert WB VOL 1 - BGP Lab 7

7)BGP Bestpath Selection – Weight

Objective: Configure the BGP Weight attribute on R3 so that traffic from R3’s Ethernet segment going to VLAN 5 is first sent to R1.

Hmm, over here ..I was again in line not with the solution though. The WB solution is more general, where as I decided to come up with the a more specific solution that only modifies the weight for VLAN_5 prefix!! I am more correct here, being more specific on the lab always helps.

Anyways this is what I Have done,

ip prefix-list VLAN_5_PREFIX seq 5 permit 155.1.5.0/24

route-map MODI_WEIGHT permit 10
match ip address prefix-list VLAN_5_PREFIX
set weight 100

router bgp 2
neighbor 155.1.13.1 route-map MODI_WEIGHT in
end

Worked like a charm! Hmm seven labs for the day, with some theory of bgp are good enough. I will call it a day, will try to do more tomorrow.

Internetwork Expert WB VOL 1 - BGP Lab 6

6)Transiting Non-BGP Speaking Devices – Tunneling

Objective: Configure the network so that hosts on VLAN 5 can reach hosts on VLAN 43. R3 will not participate in BGP routing. Configure a GRE tunnel between R1 and R2 to accomplish this.

Alright, I will try and make some quick changes to the previous lab config and see if I get this correct.

Yep, It’s correct! Had no difficulties at all. Next please.

Internetwork Expert WB VOL 1 - BGP Lab 5

5)Transiting Non-BGP Speaking Devices – Redistribution

Objective: Configure the network so that hosts on VLAN 5 can reach hosts on VLAN 43. R3 will not participate in BGP routing. Redistribute BGP into IGP in AS 2 to accomplish this.

Ok, see here ..that makes my job easier and saves time too! This scenario maps to solution 2 mentioned in the previous lab post. Nice! Let's hit it.

Yeah I nailed it straight, I mean I did configure this same thing in the previous lab just out of curiosity. The only difference between me and the solution in the WB was that, I dint find necessary to resolve the next-hop ip address as they were ending up as rib failed routes. The book does use the next-hop-self command, hmm fair enough!

Next.

Internetwork Expert WB VOL 1 - BGP Lab 4

4)iBGP Synchronization

Objective: Configure BGP per the diagram to obtain connectivity from AS 1 to R4 and R5's loopback interfaces. R4 and R5 should have static default routes pointing towards R1 and R2 respectively. BGP synchronization should be enabled on R1 and R2.

Wow, this was a big step ..the topology was much better here. Let me get moving and then blog more on this one. Well to understand this lab better here is the bgp rule of synchronization, as quoted by Brian of IE:

‘Paths marked as "not synchronized" in the show ip bgp longer-prefixes output. If BGP synchronization is enabled, which it is by default in Cisco IOS® Software, there must be a match for the prefix in the IP routing table in order for an internal (iBGP) path to be considered a valid path. If the matching route is learned from an OSPF neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization using the no synchronization BGP subcommand. See the Synchronization section in Using the Border Gateway Protocol for Interdomain Routing for more information.
• Note: Synchronization is disabled by default in Cisco IOS Software version 12.2(8)T and later.’

Actually it’s a legacy rule, which was designed for a specific purpose, which is “Designed to prevent traffic black holes, in an transit AS”. As CCIE candidates it’s important to understand its purpose and how it works, irrespective of whether it is on or off and what are the possible solutions to prevent black-holes in our transit AS!!

And yes, btw what are black-holes?! In an transit AS, whenever you see a non-BGP speaker chances are that the packets will be dropped.

To prevent this black-hole problem, I am going to go ahead and list some of the possible solutions,

1) Run full mesh iBGP within the transit AS. (synchronization is off)
2) Redistribute BGP into the IGP, thereby making the two to be in sync with each other. (synchronization is on)
3) Impelement tunnels, (synchronization is off)

• Gre
• IPIP
• MPLS ..et all

I went ahead and using the same topology, I did make all the three above mentioned solutions work!! Towards, the end of the day I will again work with solutions, as I really want to have it wrapped around my head.

Let’s proceed to our next lab.

Internetwork Expert WB VOL 1 - BGP Lab 3

3)BGP Update Source Modification

Objective: Configure a BGP peering relationship between R1 and R3. R1 should peer with R3's Ethernet interface, while R3 should peer with R1's Serial interface. R1 should use the source address 31.0.0.1 when sending BGP packets to R3.

Ok, this I had already done in the above lab, one good point to note here is that the update-source command will still work if its present on just one router, I mean after all we only need one active tcp session between the two routers. So we are good here, in the lab though it would definitely be better to configure the update-source command on both R1 and R2!

Internetwork Expert WB VOL 1 - BGP Lab 2

2)BGP Update Source Mismatch

Objective: Configure a BGP peering relationship between R1 and R3. R1 should peer with R3's Ethernet interface, while R3 should peer with R1's Serial interface.

Yep yep, I did this lab and it did take not more than 10 minutes! I know too much time there ..an ip on the fa 0/0 of R1 cuased me some problem, but nothing major. I need to be a bit more attentive whilst doing these labs I guess.

Anyways configuration was correct, I did it w/o any problems ..infact I went ahead and used the neighbor 13.0.0.3 update-source serial 1/1 command, which actually fixed and made the bgp peering come-up successfully.

Internetwork Expert WB VOL 1 - BGP Lab 1

1)Establishment of BGP Peering Relationships

Objective: Configure a BGP peering relationship between R1 and R2

Hmm, about this lab, well what can I say ..very very basic. Was done in about 5 minutes, after that I did explore some more about bgp using these three debug commands ..

debug ip packet detail
debug ip bgp events
debug ip tcp transactions

Ok, so onto the next one ..Yep btw, I did answer all the questins that followed with ease. I am really looking forward to reading the breakdown of these labs!