CTs take on BGP.

cisco_trooper

Well, it looks like I'm bored at work today, so it is time to begin soaking up BGP. I only hope it is as much fun as redistribution and route-maps were. Hopefully I'll be able to knock this exam out of the park in the next few weeks. I'll undoubtedly need to revisit some of the topics I have studied a couple months ago, but I should be ok overall as I think I have exceeded the scope of the BSCI on every topic but EIGRP, and EIGRP is simple. Anyway, this is where you will find my thoughts on BGP for those of you who care... for those of you who don't, you don't have to read this...

APA

Man... I need a job like yours so I can fit in the extra CCNP study.... although working on routers and switches all day long is probably of benefit to me

Look forward to reading your BGP summary......... I'm still on BCMSN... can't wait to hit BSCI!!!

cisco_trooper

A.P.A wrote:

Man... I need a job like yours so I can fit in the extra CCNP study.... although working on routers and switches all day long is probably of benefit to me

Look forward to reading your BGP summary......... I'm still on BCMSN... can't wait to hit BSCI!!!

Yeah, I'm just waiting on people right now. Around here the left sometimes doesn't know what the right is doing. I guess that is what happens with multinational operations....

cisco_trooper

Umm. Yeah. Maybe my standards are a little high here, but the BSCI book has left me hungry. I will have no choice but to hammer Routing TCP/IP, Volume II.

Humper

BGP is alot of fun...I love route-maps!!!!!

cisco_trooper

Well, judging from my lack of participation in my own thread I'm going to have to say I really need to get back on task here. Have barely touched BGP, or anything else for that matter all week long, although I've spent an inordinate amount of time thinking about how I should be doing so. I'm finding my brain seems to be locked up. I'm stressed out. I'm manufacturing my own stress. I think I'm putting too much pressure on myself now. Unfortunately for me I do NOT know when to quit. Hell, I don't know HOW. I'm freaking out for no reason. Someone help me....Please god help me.....I'm trying to take it all away....I don't want to..FAIL.

How do you guys calm down? I seriously lose sleep over this crap. Seriously type-7 LSAs attack me in my sleep. Route-Maps go bad and routing loops happen. Have I gone insane?

Paul Boz

Study the concepts before you study how the concepts work.

My best advice about learning BGP is to subscribe to the NANOG mailing list. There's no better way to learn something than to see it in action and see how people discuss policy about it.

If you want some supplemental reading check out BGP Design and Implementation by Cisco Press.

cisco_trooper

Holy smokes my brain hurts. I just finished reading Chapters 2 and 3 in Routing TCP/IP Vol II. These are the BGP chapters. BGP is some good stuff brother. Too bad I'm not going to absorb most of what I just read. If the Cisco Press BSCI is good baseline for what a CCNP caliber individual needs to know in daily life, then I am going to have to stick to that for now. I will revisit this topic at a later time, especially if I am offered the job I interviewed for recently. In the meantime I want to start making some progress through this certification track, as there is a nice chunk of change waiting at the end of it. It is time to lab up the relevant information from Cisco Press BSCI. Wish me luck. I intend to regurgitate what I learn for those of you who care.

cisco_trooper

Ok. So far this evening I feel pretty good about the progress I have made with the hands-on portion of my studies in regard to BGP. I have created an 8 router scenario that covers the different scenarios that immediately came to mind as I read through the material. I have BGP1, BGP2, IGP1, and IGP2, all members of autonomous system 1200 (AS1200). I have BGP3, and IGP3, both members of AS300. I have BGP4, and IGP4, both members of AS400. Each AS is running EIGRP internally as its IGP. Each router is configured with loopback addresses, which I am using when I create my BGP peers. This allowed for a little extra redundancy within AS1200. AS1200 is fully meshed physcially, minus a link between IGP1 and IGP2. This missing link allowed me to confirm that you can indeed peer between two devices that do not share a physical link. AS300 has two connections to AS1200: BGP3 -> BGP1, BGP3 -> BGP2. AS400 has two connections to AS1200: BGP4 -> BGP1, BGP4 -> BGP2. The way the lab is sitting right now, AS300 and AS400 are not adjacent to each other. Rather, AS1200 currently acts as a transit AS between AS300 and AS400. I intend to correct this tomorrow, where the real fun should begin, since there will be the opportunity for routing loops to form. I'm still trying to figure out how I am going to make this fail.

One problem that left me scratching my head for a little while had to do with advertising default routes from BGP1 and BGP2 to IGP1 and IGP2. Remember, this is a (almost) fully meshed AS, so each IGP element is receiving two default routes (actually, not relevant to the problem, but anyway). Now for the background: BGP1 and BGP2 had full knowledge of the BGP routes originating from AS300 and AS400 since they had been configured as eBGP neighbors, but I found myself trying to figure out why IGP1 and IGP2 did not also receive these routes, since they were peered directly to BGP1 and BGP2 within the same AS. Now, I'm still not entirely sure if IGP1 and IGP2 should have been learning the routes from AS300 and AS400 (from BGP1 and BGP2) since they are not peered with any BGP routers within AS300 and AS400, but I decided I would come back to nailing that down. This is where I decided a default route would be appropriate for the time being. So I configured default routes on BGP1 and BGP2, and advertised them to both IGP1 and IGP2. Can you guess what happened on the routing tables of IGP1 and IGP2? Not only did IGP1 and IGP2 now have default routes to BGP1 and BGP2, but they also had the BGP routes that originated from AS300 and AS400. So that is where I have given up for the evening.

More testing to come on whether IGP1 and IGP2 and receive the AS300 and AS400 routes from BGP1 and BGP2 (without using the default route). Also more testing on this default route phenomenon; I have not yet confirmed if this behavior is by design, or if I managed to screw something up, or if Cisco has screwed something up (which I doubt given the maturity of the protocol).

Anyway, I know that was a lot of rambling, but no one is shoving it down your throat. One of these days I will locate somewhere to upload network diagrams and such, saving about 75% of what is written above. If nothing else, I hoped I sparked an idea or two for someone...

kryolla

yeah BGP is a different beast, wait until you start learning expressions now that is a lot of fun

cisco_trooper

kryolla wrote:

yeah BGP is a different beast, wait until you start learning expressions now that is a lot of fun

yeah i saw those in bgp design and implementation. yikes.

cisco_trooper

Ok CCIEs out there. I think this question is for you, since I don't recall seeing anything about it in the CCNP material.

I have BGP1, BGP2, IGP1, and IGP2 all in BGP AS 1200. BGP1 and BGP2 both have eBGP to BGP3 in AS 300, and eBGP to BGP4 in AS 400. As a result BGP1 and BGP2 have routes to all the routes originating from AS 300 and AS 400. These routes are not being propogated to IGP1 and IGP2. Upon advertising a default route to IGP1 and IGP2, IGP1 and IGP2 both get the default route entry, but they also then get the more specific routes to those networks that reside in AS 300 and AS 400. This occurs when I use BGP to advertise the default routes, and it also occurs when I use the IGP (in this case EIGRP).

So the question is this: IS THIS THE WAY BGP OPERATES? IN THIS CASE I FIND THIS BEHAVIOR TO BE DESIRABLE, BUT IS THERE A WAY TO DISABLE THIS WITHOUT USING A ROUTE FILTER OF SOME KIND?

networker050184

How are you advertising the default route into the IGP from BGP?

cisco_trooper

networker050184 wrote:

How are you advertising the default route into the IGP from BGP?

What I have is a full mesh between BGP1, BGP2, IGP1, and IGP2. Each of these routers knows all the internal paths to each other through an EIGRP routing process. Each of these routers is then configured as a bgp neighbor to each other using the loopback interfaces for redundancy.

On BGP1 and BGP2 I have a static
ip route 0.0.0.0 0.0.0.0 null0

Then in the BGP routing process (or EIGRP process, i did it both ways with the same results)
network 0.0.0.0

IGP1 and IGP2 then get the approprate default routes. But they also get the more specific BGP routes from AS 300 and AS400.

Hope that makes sense.

dtlokee

Without really knowing the topology you are using and the configs you have it's a tough call

It seems you are redistributing between the IGPs in each autonomous system AND using BGP between them, this is not a typical setup. Usually the function of BGP is to connect seperate autonomous systems together. That would mean the IGPs are not sharing routes between them.

Since the EBGP routes will have an administrative distance of 20 which is lower than you IGP of 90, that is why they will show up instead of the EIGRP rotues. Now why they don't show up without the default route sounds like you have an issue with the BGP next hop is not know to the router and/or synchronization to the IGP.

cisco_trooper

dtlokee wrote:

Without really knowing the topology you are using and the configs you have it's a tough call

It seems you are redistributing between the IGPs in each autonomous system AND using BGP between them, this is not a typical setup. Usually the function of BGP is to connect seperate autonomous systems together. That would mean the IGPs are not sharing routes between them.

Since the EBGP routes will have an administrative distance of 20 which is lower than you IGP of 90, that is why they will show up instead of the EIGRP rotues. Now why they don't show up without the default route sounds like you have an issue with the BGP next hop is not know to the router and/or synchronization to the IGP.

I am not using redistribution right now.

I think the routes do not show up on the IGPs until they have a default route because BGP will not enter the routes into the routing table until it knows the path from somewhere other than BGP.

Let me attempt to gather some configs for your viewing pleasure....

networker050184

You have me confused. Are you trying to advertise the default route to the igp or to the other as?

cisco_trooper

I think a drawing is in order here....

dtlokee

cisco_trooper wrote:

I think the routes do not show up on the IGPs until they have a default route because BGP will not enter the routes into the routing table until it knows the path from somewhere other than BGP.

It needs to know a path to the next hop of the eBGP connection before it is allowed into the routing table. Since you are using loopbacks, if the loopback address you are peering with is unknown it will not enter it into the routing table. A possible solution on the iBGP sessions is to use the "neighbor x.x.x.x next-hop-self" to see if this fixes it. The otehr problem may be IGP synchronization if it's on. This feature is disabled in recent versions of the IOS but not on older ones.

cisco_trooper

dtlokee wrote:

cisco_trooper wrote:

I think the routes do not show up on the IGPs until they have a default route because BGP will not enter the routes into the routing table until it knows the path from somewhere other than BGP.

It needs to know a path to the next hop of the eBGP connection before it is allowed into the routing table. Since you are using loopbacks, if the loopback address you are peering with is unknown it will not enter it into the routing table. A possible solution on the iBGP sessions is to use the "neighbor x.x.x.x next-hop-self" to see if this fixes it. The otehr problem may be IGP synchronization if it's on. This feature is disabled in recent versions of the IOS but not on older ones.

I will try next-hop-self. I am using 12.4.18 Enterprise so synchronization is not on.

Just FYI, next-hop-self can't be used on peer group members. Reconfiguration will have to occur.

Blah. Since I'm peering on loopback addresses, using next-hop does put the route into the routing table, however it is invalid because it is going through the loopback address.

cisco_trooper

!
interface Loopback0
ip address 192.168.255.17 255.255.255.252
!
interface Loopback1
ip address 192.168.255.21 255.255.255.252
!
interface FastEthernet1/0
description BGP2:fa1/0
ip address 172.16.4.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
description BGP4:fa2/0
ip address 172.16.8.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/1
description BGP3:fa2/1
ip address 172.16.7.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/0
description IGP2:fa3/0
ip address 172.16.1.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/1
description IGP1:fa3/1
ip address 172.16.0.2 255.255.255.252
duplex auto
speed auto
!
router eigrp 1200
passive-interface Loopback0
passive-interface Loopback1
network 172.16.0.0 0.0.0.3
network 172.16.1.0 0.0.0.3
network 172.16.4.0 0.0.0.3
network 192.168.255.16 0.0.0.3
network 192.168.255.20 0.0.0.3
no auto-summary
!
router bgp 1200
no synchronization
bgp log-neighbor-changes
network 0.0.0.0
network 192.168.255.0 mask 255.255.255.252
network 192.168.255.4 mask 255.255.255.252
network 192.168.255.8 mask 255.255.255.252
network 192.168.255.12 mask 255.255.255.252
network 192.168.255.16 mask 255.255.255.252
network 192.168.255.20 mask 255.255.255.252
network 192.168.255.24 mask 255.255.255.252
network 192.168.255.28 mask 255.255.255.252
aggregate-address 192.168.255.0 255.255.255.248 summary-only
aggregate-address 192.168.255.8 255.255.255.248 summary-only
aggregate-address 192.168.255.16 255.255.255.248 summary-only
aggregate-address 192.168.255.24 255.255.255.248 summary-only
neighbor AS1200 peer-group
neighbor AS1200 remote-as 1200
neighbor AS300 peer-group
neighbor AS300 remote-as 300
neighbor AS400 peer-group
neighbor AS400 remote-as 400
neighbor 172.16.7.2 peer-group AS300
neighbor 172.16.8.2 peer-group AS400
neighbor 192.168.255.1 peer-group AS1200
neighbor 192.168.255.1 update-source Loopback0
neighbor 192.168.255.9 peer-group AS1200
neighbor 192.168.255.9 update-source Loopback0
neighbor 192.168.255.25 peer-group AS1200
neighbor 192.168.255.25 update-source Loopback0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 Null0
!

cisco_trooper

!
interface Loopback0
ip address 192.168.255.1 255.255.255.252
!
interface Loopback1
ip address 192.168.255.5 255.255.255.252
!
interface FastEthernet2/0
description BGP2:fa2/0
ip address 172.16.2.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/1
description BGP1:fa3/1
ip address 172.16.0.1 255.255.255.252
duplex auto
speed auto
!
router eigrp 1200
passive-interface Loopback0
passive-interface Loopback1
network 172.16.0.0 0.0.0.3
network 172.16.2.0 0.0.0.3
network 192.168.255.0 0.0.0.3
network 192.168.255.4 0.0.0.3
no auto-summary
!
router bgp 1200
no synchronization
bgp log-neighbor-changes
network 192.168.255.0 mask 255.255.255.252
network 192.168.255.4 mask 255.255.255.252
network 192.168.255.8 mask 255.255.255.252
network 192.168.255.12 mask 255.255.255.252
network 192.168.255.16 mask 255.255.255.252
network 192.168.255.20 mask 255.255.255.252
network 192.168.255.24 mask 255.255.255.252
network 192.168.255.28 mask 255.255.255.252
aggregate-address 192.168.255.0 255.255.255.248 summary-only
aggregate-address 192.168.255.8 255.255.255.248 summary-only
aggregate-address 192.168.255.16 255.255.255.248 summary-only
aggregate-address 192.168.255.24 255.255.255.248 summary-only
neighbor AS1200 peer-group
neighbor AS1200 remote-as 1200
neighbor 192.168.255.9 peer-group AS1200
neighbor 192.168.255.9 update-source Loopback0
neighbor 192.168.255.17 peer-group AS1200
neighbor 192.168.255.17 update-source Loopback0
neighbor 192.168.255.25 peer-group AS1200
neighbor 192.168.255.25 update-source Loopback0
no auto-summary
!

cisco_trooper

!
interface Loopback0
ip address 192.168.255.33 255.255.255.252
!
interface Loopback1
ip address 192.168.255.37 255.255.255.252
!
interface FastEthernet1/0
description BGP4:fa1/0
no ip address
duplex auto
speed auto
!
interface FastEthernet2/0
description IGP4:fa2/0
no ip address
duplex auto
speed auto
!
interface FastEthernet2/1
description BGP1:fa2/1
ip address 172.16.7.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/0
description BGP2:fa3/0
ip address 172.16.9.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/1
description IGP3:fa3/1
ip address 172.16.5.1 255.255.255.252
duplex auto
speed auto
!
router eigrp 300
passive-interface Loopback0
passive-interface Loopback1
network 172.16.5.0 0.0.0.3
network 192.168.255.32 0.0.0.3
network 192.168.255.36 0.0.0.3
no auto-summary
!
router bgp 300
no synchronization
bgp log-neighbor-changes
network 192.168.255.32 mask 255.255.255.252
network 192.168.255.36 mask 255.255.255.252
network 192.168.255.48 mask 255.255.255.252
network 192.168.255.52 mask 255.255.255.252
aggregate-address 192.168.255.32 255.255.255.248 summary-only
aggregate-address 192.168.255.48 255.255.255.248 summary-only
neighbor AS300 peer-group
neighbor AS300 remote-as 300
neighbor AS400 peer-group
neighbor AS400 remote-as 400
neighbor AS1200 peer-group
neighbor AS1200 remote-as 1200
neighbor 172.16.7.1 peer-group AS1200
neighbor 172.16.9.1 peer-group AS1200
neighbor 192.168.255.49 peer-group AS300
neighbor 192.168.255.49 update-source Loopback0
no auto-summary
!

networker050184

If you are trying to advertise the default route to your bgp peer you can use the neighbor x.x.x.x default-originate command, but I don't think you can supress the more specific routes with out a route map.

cisco_trooper

Here is a drawing that should provide the physical layout and routing domains... http://www.ipnetworksllc.com/Drawing1.jpg

kryolla

copy and paste show ip bgp, sh ip route, and sh ip eigrp topol all links

cisco_trooper

kryolla wrote:

copy and paste show ip bgp, sh ip route, and sh ip eigrp topol all links

I'm changing my implementation of the iBGP peers from peering on loopbacks to peering on the physical interfaces so I can utilize next-hop-self. I think that will do the trick. If not then I'll come back to this.

kryolla

if it is in the BGP table but not in the unicast routing table then you can do a sh ip bgp 1.1.1.0 255.0.0.0 and it will tell you if the neighbor needs a next hop self. Also look into the theory on why you need next hop self

cisco_trooper

OK. So that takes care of that issue. Now I have to review Routing TCP/IP Vol II Chapters 2 and 3 again to see what I missed regarding peering on loopback interfaces. It was supposed to provide redundancy but seems to have caused some undesired outcomes.

Thanks all for your continued support. I know I can come up with some crazy crap and there is always plenty of help right behind me.

dtlokee

What was the issue? Next hop self on the iBGP peerings? you can do it this way when you peer off the loopbacks just make sure the loopback addresses are advertised into the IGP or you have a static route to them (deffault routes don't work for the peering itself).
Another alternate method would to be to use a route map to set the next hop to the IP address of the egress interface and apply that to the neighbor.

kryolla

dtlokee wrote:

What was the issue? .

Was it BGP adjacencies or routes from EBGP not going into the routing table