Routing

Hello Guys

1-Why don't we use the multihop option in junos for ibgp peerings based on loopbacks.We know that it is necessary for ebgp peerings on loopbacks.

2-Is it necessary to advertise the loopbacks in igp can't we redistribute them directly in internal bgp process.

3-If bgp is a routed protocol then how does it routes IP.We know that routing protocols route routed protocols such as IP isn't it the reverse process.

Thanks & Regards

malik

Hey there,

1. You don't need to configure multihop for iBGP (bgp internal type) peerings, this is enabled by default.

2. If you're using interface addresses for iBGP (which, IMHO is wrong in so many ways) then yes. Apart from a theoritical exercise, I don't see any benefit in doing so.

3. BGP is a vector routing protocol. In other words, the contributing nodes will exchange reachability information with the closest neighbors. A main difference is that where BGP speakers exchange routes (a set of addresses with next-hops for) with one another, the IGP speakers will exchange topology information and then do the calculation locally themselves.

Cheers,

Hi Malik,

[1] By default, for eBGP TTL value is set to 1 while for iBGP it is not. Hence in order to have eBGP peering with loopback address, you need to configure multihop.

[2] There are some protocols which are dependent on IGP learned loopback routes like RSVP, LDP. Though you can redistribute these routes through BGP, you may not be able to run RSVP or LDP like protocols. (It isn't a comparsion between IGP and BGP, but I am telling the consequence if you had used BGP).

[3] BGP is a routing protocol (though few may debate on this) but atleast it not a routed protocol for sure.

Regards

Surya

Many Thanks Surya/erdems

Can you guys please further comment on point 2 separatly

Erdems for point 2 can you please further explain

2. If you're using interface addresses for iBGP (which, IMHO is wrong in so many ways) then yes. Apart from a theoritical exercise, I don't see any benefit in doing so.

Q-Can you please give me some example of why is it wrong.By interface addresses you mean loopback address also.Right?

Surya can you please further reply on my question for point 2.

[2] There are some protocols which are dependent on IGP learned loopback routes like RSVP, LDP. Though you can redistribute these routes through BGP, you may not be able to run RSVP or LDP like protocols. (It isn't a comparsion between IGP and BGP, but I am telling the consequence if you had used BGP).

Q-So it means we can not run mpls applications by using IBGP only why rsvp or ldp wont consider loopback learned via ibgp?.Please clear one more thing that for ibgp peerings on loopbacks is it necessary to introduce the loopback in the igp? What if we redistribute loopback interface in ibgp process.Does recursive lookup has anything to do with this scenario?

Thanks & Regards

Malik

Hey Malik,

 By "interface address", I mean physical (ethernet, sonet etc.) interface, not the loopback. In a iBGP environment, you'll probably have more than a single link between the routers and if you use the physical ifl addresses for iBGP, the session would flap each time said physical ifl/ifd does. When you establish iBGP sessions over loopback interfaces, your IGP is most likely to take care of the path change, without damaging BGP.

 I think I've answered your question about iBGP and reachability already (maybe in another thread).

 As for the MPLS applications, the short answer is that you can run MPLS applications without a label exchange/distribution protocol (either RSVP or LDP).

 By the way, is there a particular reason you're reluctant to have loopbacks in IGP ? I'm curious as to which requirement/scenario generates the question 🙂

 Cheers,

Hello Erdems

1-I am reluctant to advertise the loopback interface in ibgp deirectly via some policy assuming no igp in use.
Is it possible to advertise loopback in ibgp if there is no igp ?

2-By running MPLS application without rsvp/ldp you mean GRE tunnels i guess this will be the only method but will we be able to provide traffic engineering easily then or even possible coz then we will solely depend on igp??

3-Also,as surya said rsvp/ldp must learn loopbacks via igp for their operation i dont understand why is this necessary what if ldp learns the loopback via iBGP.

The scenario is 3 routers A,B& C are connected as shown below

A----b---C  now the assumption is that a,b and c are running ibgp only & we require a full ibgp mesh.

First question is if it is possible to have full mesh in this scenario using loopbacks.

Second lets say we introduce RR i.e. B acts as RR then in that case will we need to change the next-hop to self.

Hope it is not getting tedious

Thanks & Regards

Malik

Hey Malik,

 Allright, I'll try to tackle your questions in a logical order:

1: Is it possible to advertise loopback in ibgp if there is no igp ?
Of course it is. As long as you have IP reachability towards your neighbor _before_ your session establishes, you're fine.

2. You can run VPN applications without MPLS of course (e.g. GRE tunnels, as you've pointed out). To make use of MPLS,
you need a protocol to exchange labels across routers. If you go with the GRE tunnels option, you will very limited (I'd almost
call 'manual') TE capabilities since you won't be able to use CSPF.

3. RSVP/LDP can't (and should not) learn prefix information from BGP.

In your scenario, it is possible to have iBGP sessions using loopbacks as long as you have, as I' said,
"IP reachability towards your neighbor _before_ your session establishes", a static route to the other guy's
loopback IP, in your case.

If you decide to have "B" as RR for A and C, you will need to do a next-hop-self yes, because A and C won't
know about each other in your setup, since there is no IGP.

 Technically, it is of course possible to do almost everything, especially if you're willing to have lots of static routes and complex policies laying around, but why would you want to go there? 🙂

I would recommend having a nice IGP with TE capabilities (either OSPF with LSA / rfc3630) or ISIS, have RSVP or LDP exchanging your labels and then start iBGP the way you see fit.

Cheers,

Thanks again Erdems

1-I want to know why can't we provide IP reachability via ibgp by redistribution.I think i am missing something very basic here.It seems bgp is a routed protocol so a routed protocol can't route another routed protocol i.e. IP.

3-What will happen if they somehow learn prefix information from BGP what is the secret problem behind this :).Is this anything to do with internal and external labels say in L3VpN's where internal label is assigned by bgp seems suspecious though.

4-I wonder why IGP can't use the cspf itself to optimize the IP routing rather than passing results to rsvp.Say wont it be wonderful for GRE tunnel to use igp traffic engineered path provided by ospf opaque lsa.

5-last i am deviating from my basic question now but how can we made a clear distinction b/w igp-te capability and rsvp-te capability i mean why cant we use igp-te instead of rsvp-te for l3vpn's.I think the only differnce is the label allocation but can't bgp assign both the internal and external labels for l3vpn's.One differnce is that without rsvp-te P routers will have to maintain the cutomer routes which is not scalable.

Regards

malik

> 1-I want to know why can't we provide IP reachability via ibgp by redistribution.I think i am missing something very basic here.It seems bgp is a routed protocol so a routed protocol can't route another routed protocol i.e. IP.

iBGP ist not a routed protocol.

BGP is a Layer 5 Protocol which is based on the Layer 4 Protocol TCP, which in turn uses the (routed) Layer 3 Protocol IP.  So if you say BGP is a routed protocol, then you might mean that the needed IP is routed.

now you have the following options:

 - use BGP on p2p Links, i.e. both routers are exactly one hop from each other.

 - use BGP on shared links, i.e. both routers are exactly one hop from each other, but share Layer 2 with other devices

 - use BGP on "remote" links, i.e. both routers are several hops from each other

in Option 1 (p2p) you would use the ip adresses of the physical Ports to establish the BGP Session.  This is because using loopback adresses might add overhead (extra host routes), but then again there is no gain, because if the link fails, it fails.

Option 2 doesnt differ much.

Option 3 you have to differ again between alternate paths or wether this is a single path which has no redundancy whatsoever.  

In the latter case use interface ips, they wil make handling easier.

In the former case however, IGP will solve two problems for you:

 - First when you use your IGP to announce loopback adresses to the relevant routers (in OSPF for example divided by Areas) the IGP will automatically find a path between any given two routers for you.  If you used static routes to route either Interface-IPs OR loopback addresses (this doesnt matter here) then this would mean that one link down will bring your network down in worst case.

 - Second, you use your IGP so that iBGP will know which router is the actual next-hop in a multihop session. So Router A will learn the Prefix from Router C, which it reaches only over Router B;  Through the IGP Router A will know that to get to Router C it will need to set the next-hop (or "gateway") to B.

NB: a multihop session doesnt mean that you will create a session over multiple BGP Hops, it means that you create the session over multiple IP-Hops - that is, the routers cannot(!)  reach each other at layer 2 - which in turn means that if one router learns a route from another router it will not know where to set the gateway because it cant route a network to a gateway A OVER another gateway B, instead it will need to replace (for the given prefix) the next-hop "A" by next-hop "B" (which in turn knows how to reach "A", either by Layer 2 (i.e. shared or p2p network) or will have learned how to route packets to A).

Now you could try replacing the IGP by iBGP, but that *might* only work on p2p links, it will not work properly on MH-BGP Sessions, and even if you did, you will lose the automatic failovers that the IGP provides to you.  On the other hand, if you configured the necessary routes statically, you might not need your "IGP Replacement" anyway.  Also, this approach will always present kinda chicken-egg problem to you, because BGP relies on that your routers can reach each other at layer 3 already.

This is why the most common approach is to use an IGP to announce 

 - internal networks 

 - loopback addresses

who basically form your critical infrastructure itself.

.. and use BGP to announce

 - customer-relevant network (though this might also be "just" in your IGP)

 - external networks

who basically form the service you provide.

i hope this helps and wasnt too lowlevel (i take into consideration that i completely misunderstood your problem 😉

 -R

Many Thanks RiGloe

I have following questions on your comments below.

Now you could try replacing the IGP by iBGP, but that *might* only work on p2p links, it will not work properly on MH-BGP Sessions, and even if you did, you will lose the automatic failovers that the IGP provides to you.

1-Why it won't properly work on mh-bgp.

2-Are automatic failover's not provided by BGP??How does failover occurs then in ebgp multihoming scenarios.

3-what benifits do we achieve by advertising the bgp peering addresses in igp just the automatic failover or bgp free core concept has anything to do with this??

4-Some people say that ldp should learn the peering addresses via IGP only what will be the drawback when these addresses be learned via bgp.

There is a heck lot confusion about these on my mind :D.

Regards

Malik

Hey Malik,

 I think you might be over-thinking this a bit 🙂

1. Without IGP, you have to rely on static and/or directly connected routes for IP reachability. In my opinion, replacing IGP with static routes in a network is asking, or often even begging for trouble.

2. BGP can automatically failover only when it has multiple routes for the neighbor address, which is not the case on p2p link. In other words, if you have R1---R2 connected with two links, you will need to either:

2a: Establish iBGP over loopbacks, with static routes via both interfaces, with equal metric; or run IGP.

2b. Establish two iBGP sessions, one per interface. Then deal with the load balancing and failover problems with possibly metrics (see my 'opinion' on point #1 :-))

3. "BGP free core" has not much to do with this, or is at least irrelevant.

4. As I've previously said, LDP can't populate its database with prefixes learnt from xBGP, it just doesn't.

To summarize all, I would recommend:

a. Pick an IGP with TE capabilities, and implement it. Make sure you have loopback configured as passive.

b. Configure your routing-options router-id to be the same as the loopback address on all routers.

c. Pick a label distribution protocol (LDP or RSVP).

d. Configure iBGP with proper address families (e.g. inet any, inet-vpn unicast, l2vpn signalling etc.) with source-address loopback_IP on every router.

e. Enjoy.

Cheers,