Solved: MP-BGP query need help

marcusbrutus · ‎03-28-2013

Hi Experts,

I've gone through so many mpls documents and I believe i have a decent grasp of how it works but applying those principles i appear to be stuck in a setup that just won't work.

The setup is pretty straigh forward: R1 is connected to R2 and R2 is connected to R3.

R1 has ospf peering with R2 and R2 has ospf peering with R3.

OSPF working fine and connectivity via Lo on all routers working.

R1 has MP-BGP bgp peering with R3 where R1 and R3 is advertising its Lo100 interface to each other.

BGP working fine and I can see from R1 the Lo100 ip of R3 on the vrf myvrf routing table of R1.

When I do a show ip route vrf myvrf on R1, route to Lo100 of R3 (99.1.1.3) has an egress of 5.1.1.3 (default global table).

But when i try to ping from R1, 'ping vrf myvrf 99.1.1.3 source 99.1.1.1' , ping fails.

Documentation says that this should work but apparently it doesn't for me; am not sure what i am missing here.

I even tried to leak the route on both R1 and R3. But still no go.

R1:

ip route vrf myvrf 5.1.1.3 255.255.255.255 f0/0 1.1.1.2

R3:

ip route vrf myvrf 5.1.1.1 255.255.255.255 f0/0 2.1.1.1

Don't know what i am doing wrong here. And to be honest am getting confused. Please help.

Setup is as follows:

R1:

int f0/0

ip 1.1.1.1 255.255.255.0

mpls ip

int Lo0

ip add 5.1.1.1

int Lo100

ip vrf forwarding myvrf

ip add 99.1.1.1 255.255.255.255

ip vrf myvrf

rd 10:20

route-target both 10:20

router ospf 1

router-id 5.1.1.1

network 1.1.1.0 0.0.0.255 area 0

network 5.1.1.3 0.0.0.0.0 area 0

router bgp 10

neighbor 5.1.1.3 remote-as 10

no neighbor 5.1.1.3 active

neighbor 5.1.1.3 update-source Lo0

address-family vpnv4

neighbor 5.1.1.3 activate

neighbor 5.1.1.3 send-community both

address-family ipv4 vrf myvrf

network 99.1.1.1 mask 255.255.255.255

------------------------------------------------------------------

R2:

int f0/0

ip add 1.1.1.2 255.255.255.0

mpls ip

int f1/0

ip add 2.1.1.1 255.255.255.0

mpls ip

int Lo0

ip add 5.1.1.2 255.255.255.0

router ospf 1

router-id 5.1.1.2

network 1.1.1.0 0.0.0.255 area 0

network 2.1.1.0 0.0.0.255 area 0

network 5.1.1.2 0.0.0.0 area 0

---------------------------------------------------

R3:

int f0/0

ip add 2.1.1.2 255.255.255.0

mpls ip

int Lo0

ip add 5.1.1.3 255.255.255.0

int Lo100

ip vrf forwarding myvrf

ip add 99.1.1.3 255.255.255.255

router ospf 1

network 2.1.1.0 0.0.0.255 area 0

network 5.1.1.2 0.0.0.0 area 0

router bgp 10

neighbor 5.1.1.1 remote-as 10

no neighbor 5.1.1.1 activate

neighbor 5.1.1.1 update-source Lo0

address-family vpnv4

neighbor 5.1.1.3 activate

neighbor 5.1.1.3 send-community both

address-family ipv4 vrf myvrf

network 99.1.1.3 mask 255.255.255.255

Giuseppe Larosa · ‎03-30-2013

Hello Marcusbrutus,

blau grana is right you have an issue with loopback addresses subnet masks.

Your control plane looks like fine because you have all the expected MP BGP VPNv4 routes in place, but the forwarding plane is broken.

MPLS L3 VPN packets are sent within the LSP with destination the remote PE loopback address so from R1 point of view is R3's L0.

If you go on R2 device and you check the state of MPLS forwarding for R3 L0 IP address you will see that instead of seeing a POP TAG action you will see an untagged action.

The reason for the wrong LSP binding is the subnet mask on R3 loopback address: OSPF advertises all loopback addresses with a /32 mask by default, but the subnet mask is different. LDP carries the configured subnet mask. But installation of labels is made after check with IGP (OSPF in this case).

As a result of this the R2 router cannot install the correct POP TAG = implicit null label as action to do to reach R3 L0.

With POP TAG action the R2 router removes the external label (POP a label) and sends a packet (with MPLS ethertype on ethernet) with a single label MPLS stack to the egress PE R3. R3 sees a label associated to the VRF and it is able to route the packet to the appropriate interface.

With untagged action R2 removes a label take all the packet content and sends it as it was an IP packet to the downstream device. (with ethertype 0x800 on ethernet) The downstream device finds a packet that is supposed to be an IP packet but it isn't (for the inner label still there) and silently drops it.

This is what we had seen in lab tests.

To solve this issue you should:

use /32 loopback addresses this the recommended best practice

or you can still use non overlapping non /32 loopback addresses but you need to add the command ip ospf network point-to-point under loopback configuration as this makes OSPF to advertise the true IP subnet mask

Hope to help

Giuseppe

View solution in original post

blau grana · ‎03-29-2013

Hello marcus,

Please for next time try to provide configuration without mistakes/typos. If you used this configuration I do not believe that you saw any routes in routing table and it is really hard to help you because we do not know if you made real configuration mistakes or just typos during copying.

I assume all mistakes were made during copying cause you saw routes in VRF routing tables. But to be sure, check one more time that both routers have prefixes in their particular VRF routing tables.

And change network mask on Loopback 0 interface on R3, IT HAS TO BE /32.

R3

int Lo0

ip add 5.1.1.3 255.255.255.255

I hope this wil solve your problem

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

marcusbrutus · ‎03-31-2013

Sorry for the typo blau. Lo0 does have the correct subnet.

nandan12.11.88 · ‎03-29-2013

Hi,

Kindly apply "redistribute connected" under "address-family ipv4 vrf myvrf" for both R1 & R3. You have advertised the routes but you need to redistribute them in order to pass the route in MP-BGP peers.

Kindly update the result.

Regards,

Nandan

Giuseppe Larosa · ‎03-30-2013