cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1575
Views
0
Helpful
2
Replies

IBGP into OSPF redistribution

Good day.

I got some problems with IBGP into OSPF redistribution, for introduction consider following scheme :

case_ospf.jpg           

R_D1, R_C1, R_C2 and R_D2 all running multiple VRFs and use MPLS\BGP over "black" links to propogate label information and multiple adress-family  vrf bgp instances to propogate information about prefixes inside VRFs.

R_D0, R_C1, R_C2 and R_D2 besides runs OSPF inside one of VRFs (lets call it TECH) over "orange" liks. In other words - "orange" links belongs only to one vrf  and have ospf enbled over it. This scheme is not well designed, but we are in migration stage so temporary we have some non consistient segment.

Ok, getting closer to subject - R_D1 have a few subnets from 192.168.16.0/24 range connected to it in VRF TECH and announce it to R_C1, R_C2 and R_D2  using bgp adress-family ipv4 vrf TECH. Cos all 4 switches belongs to one AS (autonomus system), R_D2 have those networks installed with AD (administrative  distance) equal to 200 due to IBGP.

But we need R_D2 use "orange" link to get to subnets from 192.168.16.0/24 range (no time to explain ), so we redistributed those subnets on R_C1, R_C2 into  OSPF process using redistribute bgp 65388 metric 100 subnets command and going to R_D2 to check - but still see that it install bgp route in RIB:

R_D2#sh ip route vrf TECH | i 192.168.16.0

B      192.168.16.0/29 [200/0] via 10.11.11.11

Where 10.11.11.11 - R_D1.

Hm, lets see is R_D2 receives LSA with those route by ospf:

R_D2#sh ip ospf database external 192.168.16.0

            OSPF Router with ID (10.10.10.12) (Process ID 22)

                Type-5 AS External Link States

  LS age: 220

  Options: (No TOS-capability, DC)

  LS Type: AS External Link

  Link State ID:  192.168.16.0 (External Network Number )

  Advertising Router: 10.10.10.13

  LS Seq Number: 800007AE

  Checksum: 0x720F

  Length: 36

  Network Mask: /29

        Metric Type: 2 (Larger than any link state path)

        TOS: 0

        Metric: 100

        Forward Address: 0.0.0.0

        External Route Tag: 3489726316

  LS age: 297

  Options: (No TOS-capability, DC)

  LS Type: AS External Link

  Link State ID:  192.168.16.0 (External Network Number )

  Advertising Router: 10.10.10.14

  LS Seq Number: 800007AE

  Checksum: 0x6C14

  Length: 36

  Network Mask: /29

        Metric Type: 2 (Larger than any link state path)

        TOS: 0

        Metric: 100

        Forward Address: 0.0.0.0

        External Route Tag: 3489726316

R_D2#

Where 10.10.10.12 - R_D2, 10.10.10.13 - R_C1, 10.10.10.14 - R_C2.

Hm, so it receive but not install, lets check why - mb smth wrong with AD?

R_D2#sh ip protocols vrf TECH

*** IP Routing is NSF aware ***

Routing Protocol is "ospf 22"

    ----ommited----

  Routing Information Sources:

    Gateway         Distance      Last Update

    10.10.10.14        110      1w5d

    10.10.10.13        110      1w5d

   ----ommited----

  Distance: (default is 110)

Routing Protocol is "bgp 65388"

  ----ommited----

    Gateway         Distance      Last Update

    10.10.10.14        200      1y1w

    10.10.10.13         200      1y1w

  ----ommited----

  Distance: external 20 internal 200 local 200

We have as well distribute list under OSPF process on in direction of orange link, but it permits installing of subnetsfrom  192.168.16.0/24 range.

router ospf 22 vrf TECH

----ommited----

distribute-list prefix redistr-from-ospf22 in GigabitEthernet1/5 (Orange link)

----ommited----

exit

ip prefix-list redistr-from-ospf22 seq 5 permit 192.168.16.0/24 le 32

So R_D2 receives routes with OSPF add it LSDB but didnt install into RIB.I cant understand why. Can smb help here? Seems some loop-prevention mechanism in use but cannot find anything sufficient yet.

2) During googling possible causes I found following article Redistributing Internal BGP Routes Into OSPF due to it redistribution IBGP routes into ospf must not wotk at all on R_C1 and R_C2 cos them dont have bgp redistribute-internal command entered but have 12.2(33)SRB4 IOS version so regarding the document this command required to enable redistribution. But as you can see on output of LSDB adduced above - redistribution works, besides if we check RIB on R_D0 - it have all redistributed on R_C1 and R_C2  routes installed. So whats wrong here? Why redistribution works?

1 Accepted Solution

Accepted Solutions

Hello Alexey,

your understanding is correct, the bgp redistribute-internal applies only to address family ipv4 unicast, it is not needed for VPNv4 address family as there are underlying import and export procedures from /to specific VRFs that work in the background.

Hope to help

Giuseppe

View solution in original post

2 Replies 2

I found answer on first question - the reason of such behaviour is in ospf capability vrf lite.

But  second question still actual. Can smb clarify - there is no need for bgp redistribute-internal in MPBGP environment or what?

Hello Alexey,

your understanding is correct, the bgp redistribute-internal applies only to address family ipv4 unicast, it is not needed for VPNv4 address family as there are underlying import and export procedures from /to specific VRFs that work in the background.

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: