5

I have two routers, AS50 and AS100, both are under my control. Since they are using different ASN, they should be eBGP routers. These two routers are connected by internet VPN and lease line, which means dual path between these two routers.

Lease line will take higher preference on packet routing while internet VPN will act as backup.

My questions:

  1. According to my reading, Local pref seems only applicable to iBGP not eBGP router, is this correct?

  2. I am currently using prepend AS-path out method on both router, so the packet cover bidirectional routing. It seems work fine and I tested couple time on connection lost, BGP pick up change very quickly. But it did have couple packet loss in between. So when internet backup link in service, the primary link is recover, it will take couple packet loss before switching to primary link, is it possible to tell BGP test and ensure the primary link is functional before switching back from internet VPN backup link?

  3. prepend always use "out" direction, is there have any real situation which prepend "in" could be use?

  4. what will happen if I accidentally use local pref on eBGP routers instead of prepend?

7

Most of your confusion seems to be related to your other duplicate question, which is the same as 3. above...:

prepend AS path usually running with route-map out to adjust outbound traffic from router which contain this option

I'm sorry, but you are mistaken; prepending your ASN out adjusts traffic inbound to your ASN.

Does prepend work with route-map in at all to adjust inbound traffic?

No, you don't prepend inbound, because you can only prepend with your own ASN. If you prepend your own ASN to inbound announcements, bgp would think this is a routing loop (because it sees its own AS in the AS-path) and drop the route.

Let's eliminate the confusion in the question...

  • neighbor x.x.x.x route-map FOO_out out adjusts traffic inbound to your ASN
  • neighbor x.x.x.x route-map FOO_in in adjusts traffic outbound from your ASN; use local-preference, med or some other criteria to influence your outbound traffic.

Example configuration:

ip prefix-list MATCH_ALL permit 0.0.0.0/0
!
route-map AS100_out
 match ip address prefix-list MATCH_ALL
 ! --> Prepend so other ASN don't prefer this path
 !     NOTE: don't do this... 20 prepends is absurd in the real world.
 !          Five or ten ASN prepends should be sufficient
 set ip as-path prepend 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 65001 
!
route-map AS100_in
 match ip address prefix-list MATCH_ALL
 ! --> Set local-pref lower than 100, so we don't prefer this peer
 set local-preference 50
!
router bgp 777
 ! insert other "normal" bgp configuration here, network statement, etc..
 !
 neighbor 192.0.2.2 remote-as 100
 ! --> AS100_out adjusts *inbound* traffic
 neighbor 192.0.2.2 route-map AS100_out out
 ! --> AS100_in adjusts *outbound* traffic
 neighbor 192.0.2.2 route-map AS100_in in

NOTE: Prepending is deceptive; it might seem like nobody should select a path if you have prepended a lot of ASNs to your announcements, but even if you did that's no guarantee that downstream routers won't send traffic to you over that prepended path. The reality is that internet routing is still a per-hop / per-ASN decision, and you're still somewhat at the mercy of the wisdom (or foolishness) of others. See below for an example.

Problems with AS-prepend traffic engineering

Strictly speaking, you loose complete control of inbound routing paths when you announce your prefix to multiple providers because there are independent routing decisions made downstream for return traffic to you. Furthermore, your announcements could even be modified by downstream providers after you send them.

Example

This is one example of what can happen. Continuing with the example configuration shown above...

  • Suppose you have AS 777; you got a portable address block (2.2.0.0/22) from AS 100.
  • You are dual homed to both AS 100 and AS 200
  • You have services that a company with Router A needs to access.
  • Assume that AS 100 doesn't have a good link to you (maybe it's intermittently corrupting traffic due to physical-layer problems you haven't been able to fix). So you think to yourself, "I'll just prepend all my announcements to AS100 with a large number of ASNs so nobody will prefer the AS100 link until I can fix this".

bgp asymmetric

The problem is that you only have complete control of your outbound routing decisions. You don't get complete control inbound... so let's suppose Router A's administrator doesn't know your link to AS100 is bad. They are dual-homed to AS200 and AS100, but AS100 offers much cheaper transit, per-Mbps; therefore Router A's engineer takes full routes from AS100 and only uses AS200 as a backup (taking only a default from them).

AS 100's engineering team decides to set a high local-pref for 2.2.2.0/22 announcements from you. As such , the combination of full routes at router A and AS 100’s local pref means that you’ve lost control for ingress traffic through AS 100 to AS 777.

To summarize, As the admin of AS 777, you can force AS 777’s egress traffic to Router A through AS 200, but traffic from Router A to 2.2.0.0/22 would still take AS 100 (because the best route is through AS 100, at Router A).

  • so how does prepend be useful if router A is out of our control? And localpref outbound traffic is a guarantee because I could control where does outbound traffic going, correct? – Thomas G. Lau Dec 27 '14 at 16:12
  • Remember, BGP attributes at best provide a suggestion for other AS's on how to access your network, they do not set the actual operational policy. If the owner of RouterA sets a higher "weight" or a higher "local preference" for Routes learned from AS100, then RouterA will always choose AS100 to get to AS777, regardless of how long the AS Path is. Both Weight and Local-Preference are considered before AS Path in making a BGP "best path" decision. – Eddie Dec 27 '14 at 16:37
  • @ThomasG.Lau, local-preference gives you 100% control of outbound traffic from your AS. Prepending your AS is useful for influencing inbound traffic. When we are talking about the BGP policies of other companies, all you can do is influence; we have no control. It's still worth the effort to influence others' behavior (i.e. prepending will reduce your inbound traffic); however, you shouldn't be deceived into thinking that you actually have 100% control over what other companies do. When I first started with bgp, I used to wonder why I still got traffic on heavily prepended links. – Mike Pennington Dec 27 '14 at 17:35
  • @MikePennington this part I also have same experience. So in my case if both routers under my control, and if both running route-map prepend out, I should be able to push traffic to primary link, right? – Thomas G. Lau Dec 28 '14 at 2:12
  • If you own routers analogous to both AS777 and router A in the diagram, you are correct as long as the traffic only exists between those two ASNs. As soon as any other company sends traffic to AS777, you no longer can rely solely on prepending without coordinating with the other companies – Mike Pennington Dec 28 '14 at 13:31
5
  1. Correct. localpref is not sent to eBGP peers.
  2. BGP by itself only checks that a route to the destination exists in the routing table. There are other ways to verify functionality. If you're using a Cisco router, you can use IP SLA and object tracking or Performance Routing. Other brands of routers have similar functions.
  3. No. Prepend doesn't modify received AS-PATH attributes.
  4. See #1. local pref is not sent to eBGP peers.

Since both routers are under your control, you can set the MED attribute with the command

bgp always-compare-med

instead of using as-path length.

  • Can you explain a bit about MED usage in my case? Anything else I need to config it? – Thomas G. Lau Dec 27 '14 at 2:14
  • Regarding the second question. The other pretty good way how to detect that line is down is Bidirectional Forwarding Detection (BFD). In my opinion this is the best way alongside with tracking (ip sla). – Daniel Blazek Dec 27 '14 at 8:25
  • 1
    @DanielBlazek Yes, you are right, but getting BFD to work over a VPN tunnel is more complicated than it's worth, IMO. – Ron Trunk Dec 27 '14 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.