BGP Split Horizon rule or rules?

hasitha257

I am just curious if its safe to say BGP split horizon rule is two fold

1. I will not advertise routes learned via IBGP to other IBGP neighbors because there should be a full mesh IBGP topology or use reflectors etc. ok.......

How about # 2 ? isn't this considered BGP split horizon rule too?

2. I will not advertise a prefix to another EBGP neighbor if I am learning the prefix infact from that neighbor ? ........


or is it , #1 is IBGP split horizon rule , #2 is EBGP split horizon rule ?

Forsaken_GA

EBGP rules are pretty simple - it will not advertise a prefix to a peer that it doesn't already have a route for. ie, I need to have learned it from another source before I'll tell an EBGP peer about it. Whether that source is from an IGP, a static route, or another EBGP peer makes no difference.

So for example lets say I have 3 routers in different AS's

If R1 is sending a prefix to R2 and R3, R3 *will* advertise R1's prefix to R2, and R2 will advertise the same prefix to R3. BGP can hold multiple routes. It will just use the path seleciton algorithim to determine what it will actually install in the routing table.

So R2 and R3 would tell each other about prefix's they already have, that way if the link between R1 and R3 goes down, R3 can still reach R1 via R2. If the link between R1 and R2 goes down, R2 can still reach R1 via R3.

Now, in the real world, if R3 is an end user network, it wouldn't tell R2 about R1's routes because R3 probably doesn't want to be used as a transit AS. But if all of them belonged to service providers instead of end user networks, they're all transit networks, and probably will tell each other about all their routes (all depends on their individually negotiated peering agreements)

So BGP doesn't really have a split horizon rule. iBGP refuses to talk to anybody except it's friends unless you specifically tell it to via route reflector or confederation. EBGP doesn't care, it'll take any route from anyone unless specifically configured to ignore them, and then just decides what is the best path and drops that into the routing table. If the best path goes away, if it has other routes, it'll insert the next best path into the routing table.

Forsaken_GA

And actually, I guess my example isn't complete, as there is loop detection.

If R3 sends a route to R1, and then R1 sends that to R2, and then R2 sends that to R3, that would cause a routing loop. But because of the way BGP works, when R2 tries to send the prefix that R3 originated back to R3, R3 will drop it because it will see it's own AS number in the AS_PATH list. This will prevent the routing loop.

So BGP doesn't really care about which interface a route advertisement came in on, it just cares about whether the path is a duplicate, regardless of where it comes in from. It is perfectly valid for EBGP to send a route out one interface and then receive the same route back over that same interface.

hasitha257

|
R1

---

R2

---

192.168.1.0/24
|


R1 and R2 have EBGP running. R2 has 192.x.x.x attached to its LAN interface. R1 is learning the prefix from R2. will R1 advertise the prefix back to R2 ?

networker050184

hasitha257 wrote: »

|
R1

---

R2

---

192.168.1.0/24
|


R1 and R2 have EBGP running. R2 has 192.x.x.x attached to its LAN interface. R1 is learning the prefix from R2. will R1 advertise the prefix back to R2 ?

No, when a router walks the table to form updates it will not send an update to an eBGP peer if that peers AS is in the AS_PATH attribute.

hasitha257

thanks guys. I was under impression that R1 will send updates to R2 anyway and R2 will drop the update when it sees its own AS in the AS Path. Makes sense for R1 not to advertise prefix to R2.

Forsaken_GA

hasitha257 wrote: »

thanks guys. I was under impression that R1 will send updates to R2 anyway and R2 will drop the update when it sees its own AS in the AS Path. Makes sense for R1 not to advertise prefix to R2.

It depends on the implementation of BGP. It makes sense to not send updates that are just going to get dropped, as it's a waste of bandwidth and processing power, but if you decided to peer with someone who's implementation didn't play nice, your side will make sure there's no routing loop.

APA

Forsaken_GA wrote: »

It depends on the implementation of BGP. It makes sense to not send updates that are just going to get dropped, as it's a waste of bandwidth and processing power, but if you decided to peer with someone who's implementation didn't play nice, your side will make sure there's no routing loop.

+1

But to be honest I'm not aware of many NOS' that walk the BGP table to detect AS LOOPs before forming updates........

Perfect examples of why they shouldn't is MPLS VPNs for instance that use eBGP peering between CE and PE..... with the same AS used for all CE's in a specific MPLS VPN domain.

I've always believed (from what I've read) that the onus for AS Loop Detection was on the receiving BGP peer to detect that its AS was in the received update and thus rejects that specific NLRI announcement.

However if you wanted to bypass the loop detection and accept updates with your AS in the path (MPLS VPN example again), then 'allowas-in' is a feature in many NOS' for that exact reason.

networker050184

APA wrote: »

+1

But to be honest I'm not aware of many NOS' that walk the BGP table to detect AS LOOPs before forming updates........

Yeah, according to some documentation (and the CCIE R&S cert guide) the router walks the table and checks before sending the update. If you actually watch some debugs though you can see that the receiving router will drop it. I'm not sure if there are certain IOS that implement this and not others though. So I guess if you see that question on an exam your guess is as good as mine haha.

APA wrote: »

Perfect examples of why they shouldn't is MPLS VPNs for instance that use eBGP peering between CE and PE..... with the same AS used for all CE's in a specific MPLS VPN domain.

As-override is what would be used to get around that.

In the OPs example though, the router isn't going to send the update right back from where it was received.

APA

networker050184 wrote: »

As-override is what would be used to get around that.

In the OPs example though, the router isn't going to send the update right back from where it was received.

Not necessarily... you can use 'as-override' or 'allowas-in' it really depends on what the engineer chooses at that point in time as they achieve the same thing.... there are pro's and con's to both choices.....

MPLS and VPN architectures goes through both options in great depth...

Yeah I was using an example of why the updates shouldn't be dropped by the announcing router..... there is an interesting document by Geoff Huston somewhere out there which shows the process.

I had a dig through RFC1771 - it states that the update error message subcode 7 is used for 'AS Routing Loops' detected.

Thus an update error message subcode of 7 would only be sent by the receiving peer, who received the update which contains the AS routing loop.

You've got me wondering now networker, going to get some debugs happening with different IOS code and see whether IOS differs from this and performs a walk before announcing updates with loops to a peer.

deth1k

APA wrote: »

Not necessarily... you can use 'as-override' or 'allowas-in' it really depends on what the engineer chooses at that point in time as they achieve the same thing.... there are pro's and con's to both choices.....

MPLS and VPN architectures goes through both options in great depth...

Yeah I was using an example of why the updates shouldn't be dropped by the announcing router..... there is an interesting document by Geoff Huston somewhere out there which shows the process.

I had a dig through RFC1771 - it states that the update error message subcode 7 is used for 'AS Routing Loops' detected.

Thus an update error message subcode of 7 would only be sent by the receiving peer, who received the update which contains the AS routing loop.

You've got me wondering now networker, going to get some debugs happening with different IOS code and see whether IOS differs from this and performs a walk before announcing updates with loops to a peer.

Normally ISPs would use "as-override" on the PEs to avoid any issues in case of unmanaged CE routers (or managed for that matter). Allowas-in has to be done on CE router since it be the one rejecting the route from PE seeing its own ASN in the path.
Therefore "as-override" feature is more preferred and widely used.

APA

deth1k wrote: »

Normally ISPs would use "as-override" on the PEs to avoid any issues in case of unmanaged CE routers (or managed for that matter). Allowas-in has to be done on CE router since it be the one rejecting the route from PE seeing its own ASN in the path.
Therefore "as-override" feature is more preferred and widely used.

Yep that's correct.... however the fact they are both valid choices is the point I was alluding to...

allowas-in highlight why I think the BGP update with a looped AS_PATH attribute would still be passed to a BGP receiver.

To be brutally honest though.... if you're the SP... and you're managing the CPE.... there really is no difference whether you use one or the other.... as they both get you to the same end goal of permitting the route through.

However if unmanaged... then yes, assuming the SP knows a little more than the customer - as-override would be much better in this scenario.

I do admit one is a more elegant solution (as-override), however with allowas-in you have the option to also specify how many times the ASN can appear in the AS_PATH attribute before the route can really be considered looped and therefore dropped.

Anywhose.. I think I've gone off track enough in this thread.... I'll post back with my debugging of BGP updates, when I get some time...