Solved: BPG ipv4 labels do not appear in LFIB

Sherif Atef Ahmed Ismail · ‎11-23-2012

Dears

I have a question and would like your assistance please

As you know in Inter-As Option C, you use bgp+label (extended BGP rfc 3107) to advertize loopback with labels between AS

Consider below topology

RR1 loopback -->> 100.100.100.100

RR2 loopback -->> 200.200.200.200

Between RR1 & RR2 -->> ebgp vpnv4

Between PE2 & PE3 -->> ebgp ipv4 + label to advertize RR loopbacks

Between PE2/RR1, RR1/PE1, PE3/RR2 & RR2/PE4 -->> ibgp ipv4 + label to cascade RR loopback

Everything is working fine however I have a question

Why RR2 loopback does not appear in LFIB table (show mpls forwarding-table) @ RR1 as shown below

And why when I do show mpls forwarding-table RR2 loopback it gives me an O/P !!

The reason why I am asking this cause as I know, during forwarding router inspects LFIB when it receives labeled packets ... So I expected to found loopback in LFIB

Am i missing something ?

||||||

RR1#sh ip route 200.200.200.200

Routing entry for 200.200.200.200/32

Known via "bgp 1", distance 200, metric 2

Tag 2, type internal

Last update from 23.23.23.3 00:08:17 ago

Routing Descriptor Blocks:

* 23.23.23.3, from 2.2.2.2, 00:08:17 ago [23.23.23.3 -->> PE3 , 2.2.2.2 -->> PE2]

Route metric is 2, traffic share count is 1

AS Hops 1

Route tag 2

MPLS label: 16

RR1#

RR1#sh ip bgp 200.200.200.200/32

BGP routing table entry for 200.200.200.200/32, version 6

Paths: (1 available, best #1, table default)

Not advertised to any peer

2

23.23.23.3 (metric 20) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 2, localpref 100, valid, internal, best

mpls labels in/out nolabel/16

RR1#

RR1#sh ip cef 200.200.200.200

200.200.200.200/32

nexthop 12.12.12.2 FastEthernet1/1 label 16 16

RR1#

RR1#sh mpls forwarding-table <<<---- 200.200.200.200 is not present !!

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

16 Pop Label 1.1.1.1/32 0 Fa1/0 11.11.11.1

17 Pop Label 2.2.2.2/32 0 Fa1/1 12.12.12.2

19 20 1:1:10.10.10.0/24 \

0 Fa1/0 11.11.11.1

20 Pop Label 23.23.23.0/24 0 Fa1/1 12.12.12.2

21 16 23.23.23.3/32 0 Fa1/1 12.12.12.2

RR1#

RR1#sh mpls forwarding-table 200.200.200.200 detail <<<--- gives an O/P !!

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

None 16 200.200.200.200/32 \

0 Fa1/1 12.12.12.2

MAC/Encaps=14/22, MRU=1496, Label Stack{16 16}

CA06156C001CCA091CC0001D8847 0001000000010000

No output feature configured

RR1#

Many Thanks

Sherif Ismail

shivjain · ‎11-24-2012

Hi

In control Plane we have

1. Routing infomration database Which helps the router to build the RIB.

2. We have LIB normally called label bindings received from the other peers.

In Forwarding Plane we have

1. FIB which populates its infromation from RIB

2. LFIB which populates its table from the combination of (FIB + LIB)

So in your case the route 200.200.200.200/32 is no where present in the RIB, this is the probably reason that you are not able to find its entry in LFIB which is normally called forwading table.

Hope the infomration is useful to you.

regards

shivlu jain

http://www.mplsvpn.info

LFIB = FIB + LIB

FIB comes directly from RIB

View solution in original post

Olivier ARRIGHI · ‎11-23-2012

Hi

I guess BGP routes never get an entry in the LFIB.as 200.200.200.200 learnt in RR1 is done via BGP, you won't see a service label.It does not mean though that it can't have a vpn label.

you might want to redistribute the loopbacks to IGP to get this achieved.

Now with your config :

So the label 16 you see in :

RR1#sh mpls forwarding-table 200.200.200.200 detail <<<--- gives an O/P !!

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

None 16 200.200.200.200/32 \

is associated to a vpn, (label given by opposite RR)

then other label 16 is associated to the path to the next hop 23.23.23.23

so it gives 2 you still 2 level of tag.

I may be wrong as i had just a few time to review your message and did not test it in a lab.

have fun

shivjain · ‎11-24-2012

Hi

In control Plane we have

1. Routing infomration database Which helps the router to build the RIB.

2. We have LIB normally called label bindings received from the other peers.

In Forwarding Plane we have

1. FIB which populates its infromation from RIB

2. LFIB which populates its table from the combination of (FIB + LIB)

So in your case the route 200.200.200.200/32 is no where present in the RIB, this is the probably reason that you are not able to find its entry in LFIB which is normally called forwading table.

Hope the infomration is useful to you.

regards

shivlu jain

http://www.mplsvpn.info

LFIB = FIB + LIB

FIB comes directly from RIB

Sherif Atef Ahmed Ismail · ‎11-24-2012

Thanks Olivier/Shivlu

@ Olivier

Yes you are correct when it is distributed into IGP it appeared in LFIB.

Seems that LFIB only have subnets that are learnved via LDP or MP-BGP but not extended BGP (bgp ipv4 + label) !

But still I am confused about what the router will do when it receives labeled packets.

As I know with unlabeled packets router fetches FIB tabel (cef) however with labeled packets router fetches LFIB tabel (mpls forwarding-table). Now problem that subnet is not present in LFIB and packets received are labeled !

||||

@ Shivlu

- Why route is not present in RIB since it is known from BGP and present in routing table

- As I know when router receives labeled packets, it inspects LFIB so not having this route in LFIB I believe this should makes problems !

- Finally why "show mpls forwarding-table 200.200.200.200" gives an O/P and route is not present in LFIB ! .. Is this a bug ?

Many Thanks for your assistance

Sherif Ismail

shivjain · ‎11-24-2012

Hi Sherif

I believe that you are aware about the tables used by BGP. I am explaining it if you don;t know, BGP maintains three table one for storing incoming routes from neighbours, one for sending the routes to neighbours and one for installing the routes where you actually find the routes with next-hop address (In your case next hop is reachable as it is being learned via IGP). The BGP tables are given below:-

a) Adj-RIB-in

b) Adj-RIB-out

c) Loc-RIB

Adj-RIB-in stores the unprocessed information received from its peers. Here the best path selection occurs as per BGP attributes and after conformation path is entered into the local bgp table i.e Loc-RIB. From the local RIB table it conform the next-hop address if it reachable by IGP then the route is entered into the main routing table. In your case the consistency is not maintained between the IGP and BGP table. This could be the cause of not getting the stuff in MPLS forwarding table.

As per the suggested by others, you could either redistribute it or use the next-hop-self command to maintain the consistency.

For more deep dive you can read the paper regarding the use of next-hop-self from http://www.mplsvpn.info/2008/09/bgp-next-hop-self.html

regards

shivlu jain

Mohamed Sobair · ‎11-24-2012

Hello Sherif,

The Next-Hop in the BGP Table of RR1 is not known by CEF, from your output of the show verfication command, the CEF Table doesnt know how to reach 200.200.200.200/32 which is installed with a nexthop of 23.23.23.3 (PE3). showing inconsistency between the BGP nexthop and CEF nexthop for 200.x Prefix.

You can correct this by issuing the (neigbor x.x.x.x next-hop-self) bgp command on RR1 to maintain consistency at the Data plane.

Regards,

Mohamed

Sherif Atef Ahmed Ismail · ‎11-26-2012

Dears/All

Many thanks for your assitance

Actually everything is working fine as mentioned previously (CEs are pingable) however I wanted to know how it was working

Good news .. I figured it out .. Whole issue is that with extended BGP you have 3 labels so thats why 200.200.200.200 is not present in LFIB @ RR1

|||||||

PE1#sh mpls forwarding-table vrf BLUE 20.20.20.20 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

None 20 20.20.20.0/24[V] 0 Fa1/1 11.11.11.100

MAC/Encaps=14/26, MRU=1492, Label Stack{18 18 20}

CA0517F8001CCA0306B8001D8847 000120000001200000014000

VPN route: BLUE

No output feature configured

PE1#

PE1#sh ip cef vrf BLUE 20.20.20.20

20.20.20.0/24

nexthop 11.11.11.100 FastEthernet1/1 label 18 18 20

PE1#

|||

Here I should care about label 18 & not prefix 200.200.200.200

RR1#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

16 Pop Label 2.2.2.2/32 0 Fa1/1 12.12.12.2

17 Pop Label 1.1.1.1/32 0 Fa1/0 11.11.11.1

18 17 23.23.23.3/32 0 Fa1/1 12.12.12.2

19 Pop Label 23.23.23.0/24 0 Fa1/1 12.12.12.2

20 21 1:1:10.10.10.0/24 \

0 Fa1/0 11.11.11.1

RR1#

RR1#sh mpls forwarding-table labels 18

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

18 17 23.23.23.3/32 0 Fa1/1 12.12.12.2

RR1#

|||

PE2#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

16 No Label 3.3.3.3/32 0 Fa1/1 23.23.23.3

17 Pop Label 23.23.23.3/32 5690 Fa1/1 23.23.23.3

18 Pop Label 100.100.100.100/32 \

4520 Fa1/0 12.12.12.100

19 Pop Label 11.11.11.0/24 0 Fa1/0 12.12.12.100

20 17 1.1.1.1/32 0 Fa1/0 12.12.12.100

PE2#

PE2#sh mpls forwarding-table labels 17

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

17 Pop Label 23.23.23.3/32 5690 Fa1/1 23.23.23.3

PE2#

|||

PE3#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

16 No Label 2.2.2.2/32 0 Fa1/0 23.23.23.2

17 Pop Label 23.23.23.2/32 0 Fa1/0 23.23.23.2

18 Pop Label 200.200.200.200/32 \

6121 Fa1/1 32.32.32.200

19 Pop Label 24.24.24.0/24 0 Fa1/1 32.32.32.200

20 18 4.4.4.4/32 0 Fa1/1 32.32.32.200

21 18 100.100.100.100/32 \

4197 Fa1/0 23.23.23.2

PE3#

PE3#sh mpls forwarding-table labels 18

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

18 Pop Label 200.200.200.200/32 \

6175 Fa1/1 32.32.32.200

PE3#

|||

RR2#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

16 Pop Label 3.3.3.3/32 0 Fa1/0 32.32.32.3

17 Pop Label 23.23.23.0/24 0 Fa1/0 32.32.32.3

18 Pop Label 4.4.4.4/32 0 Fa1/1 24.24.24.4

19 21 100.100.100.100/32 \

0 Fa1/0 32.32.32.3

20 21 1:1:20.20.20.0/24 \

0 Fa1/1 24.24.24.4

RR2#

RR2#show mpls forwarding-table labels 20

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

20 21 1:1:20.20.20.0/24 \

0 Fa1/1 24.24.24.4

RR2#

RR2#sh ip bgp vpnv4 all labels

Network Next Hop In label/Out label

Route Distinguisher: 1:1

10.10.10.0/24 100.100.100.100 nolabel/20

20.20.20.0/24 4.4.4.4 20/21 <<<---- here RR2 assigns a new label as this is MP-eBGP

RR2#

|||

PE4#show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

16 Pop Label 200.200.200.200/32 \

0 Fa1/0 24.24.24.200

17 16 3.3.3.3/32 0 Fa1/0 24.24.24.200

18 17 23.23.23.0/24 0 Fa1/0 24.24.24.200

19 Pop Label 32.32.32.0/24 0 Fa1/0 24.24.24.200

20 19 100.100.100.100/32 \

0 Fa1/0 24.24.24.200

21 No Label 20.20.20.0/24[V] 0 aggregate/BLUE

PE4#

PE4#show mpls forwarding-table labels 21

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

21 No Label 20.20.20.0/24[V] 0 aggregate/BLUE

PE4#

PE4#sh ip bgp vpnv4 all labels

Network Next Hop In label/Out label

Route Distinguisher: 1:1 (BLUE)

10.10.10.0/24 100.100.100.100 nolabel/20

20.20.20.0/24 0.0.0.0 21/nolabel(BLUE)

PE4#

Once more thanks for your time

Olivier ARRIGHI · ‎11-26-2012

Hi Sherif.

If I may, 200.200.200.200 is not missing from forwarding table because it has three label stacked, but only because this is a route learnt from BGP, and this is a very clear statement that BGP routes in the RIB are never sent to the LFIB.

You will find in the LFIB only routes learnt from IGP and VPN labels from BGP( like BLUE vpn).and labels for traffic engineering also if I recall correctly.

cheers

Sherif Atef Ahmed Ismail · ‎11-26-2012

Hi Olivier

I had my doubts regarding this and now you confirmed it .. Thanks