Injecting 0.0.0.0/1 into BGP

I have a curious case that I wanted to share and get some feedback. Its a simple lab setup:

 

CE---------CE

-             -

-             -

-             -

PE-MPLS--PE

 

The PE/CE is OSPF. 

There are other sites that are also part of the VPN (but are not relevant to this).

 

One of the CEs is injecting a few loopbacks into OSPF as external (redistribute connected subnets). The loopback are as follows:

int loopback 50

ip add 50.1.1.1/32

int loopback 100

ip add 192.168.50.1/32

 

This same CE is doing the following into OSPF:

summary address 0.0.0.0 128.0.0.0

summary address 128.0.0.0 128.0.0.0

 

Both PEs receive these summaries and istall them into the RIB as E2. There is mutual redistribution between OSPF and MP-BGP, however, only the 128.0.0.0/1 gets put into BGP. 0.0.0.0/1 does not! 

I know that BGP needs the "default-information originate" command in order to originate a default...but this is not a default! Its the closest thing to one, but still it is not. I am really curious as to why the 128.0.0.0/1 does make it into BGP (both PEs inject it when they do OSPF to MP-BGP redisti), but the 0.0.0.0/1 does not make it into MP-BGP from either side.

Thanks for your feedback! =) 

 

Comments

  • bgp has auto summary?? hmm not sure

     

    Can you supply configs for a PE and CE?

  • Sure,

    This is one of the PEs, just basic OSPF and BGP...nothing fancy:

    PE1:

    PE1#show run | s router ospf

    router ospf 1 vrf A

     domain-tag 100

     prefix-suppression

     log-adjacency-changes

     redistribute bgp 100

     network 0.0.0.0 255.255.255.255 area 0

    !

    PE1#show run | s router bgp

    router bgp 100

     no bgp default ipv4-unicast

     bgp log-neighbor-changes

     neighbor 3.3.3.3 remote-as 100

     neighbor 3.3.3.3 update-source Loopback0

     !

     address-family vpnv4

      neighbor 3.3.3.3 activate

      neighbor 3.3.3.3 send-community extended

     exit-address-family

     !

     address-family ipv4 vrf A

      no synchronization

      redistribute ospf 1 vrf A match internal external 1 external 2

    !

     

    This is the RIB of the PE before the CE does the summary:

     

    PE1#show ip route vrf A ospf  | b Gate

          1.0.0.0/32 is subnetted, 1 subnets

    O        1.1.1.1 [110/21] via 10.19.20.20, 00:02:56, Ethernet1/1

          20.0.0.0/32 is subnetted, 1 subnets

    O        20.20.20.20 [110/11] via 10.19.20.20, 00:02:56, Ethernet1/1

          50.0.0.0/32 is subnetted, 1 subnets

    O E2     50.20.20.20 [110/20] via 10.19.20.20, 00:01:05, Ethernet1/1

          192.168.20.0/32 is subnetted, 1 subnets

    O E2     192.168.20.20 [110/20] via 10.19.20.20, 00:01:05, Ethernet1/1

     

     

    Both of these prefixes are getting redistributed into BGP via the redistribution:

     

    PE1#show bgp vpnv4 unicast all | b Ne

       Network          Next Hop            Metric LocPrf Weight Path

    Route Distinguisher: 10:10 (default for vrf A)

    * i1.1.1.1/32       2.2.2.2                 11    100      0 ?

    *>                  10.19.20.20             21         32768 ?

    *>i10.1.2.0/24      2.2.2.2                  0    100      0 ?

    *> 10.19.20.0/24    0.0.0.0                  0         32768 ?

    *> 20.20.20.20/32   10.19.20.20             11         32768 ?

    * i50.20.20.20/32   2.2.2.2                 20    100      0 ?

    *>                  10.19.20.20             20         32768 ?

    * i192.168.20.20/32 2.2.2.2                 20    100      0 ?

    *>                  10.19.20.20             20         32768 ?

     

     

    Now the CE does the summarization...it will advertise 0.0.0.0/1 and 128.0.0.0/1 (a default route broken up into 2). The CE is redistributing loopbacks in each half (the 50.20.20.20 falls in the 1st half, and the 192.168.20.20 falls into the second half).

     

     

    CE2#show run | s router ospf

    router ospf 1

     log-adjacency-changes

     prefix-suppression

     summary-address 0.0.0.0 128.0.0.0

     summary-address 128.0.0.0 128.0.0.0

     redistribute connected subnets route-map CONNECTED_OSPF

     

    Now PE1's RIB looks like this:

     

    PE1#sh ip route vrf A ospf | b Gate

    O E2  0.0.0.0/1 [110/20] via 10.19.20.20, 00:01:39, Ethernet1/1

          1.0.0.0/32 is subnetted, 1 subnets

    O        1.1.1.1 [110/21] via 10.19.20.20, 00:01:51, Ethernet1/1

          20.0.0.0/32 is subnetted, 1 subnets

    O        20.20.20.20 [110/11] via 10.19.20.20, 00:01:51, Ethernet1/1

    O E2  128.0.0.0/1 [110/20] via 10.19.20.20, 00:01:39, Ethernet1/1

     

    Both of the redistributed loopbacks have been suppressed by these large summaries (the other PE has the same output). 

     

    Now the interesting part...all of the OSPF routes "should" be redistributed into MP-BGP. However, look at what makes it in:

     

    PE1#show bgp vpnv4 unicast all | b Net

    Route Distinguisher: 10:10 (default for vrf A)

    * i1.1.1.1/32       2.2.2.2                 11    100      0 ?

    *>                  10.19.20.20             21         32768 ?

    *>i10.1.2.0/24      2.2.2.2                  0    100      0 ?

    *> 10.19.20.0/24    0.0.0.0                  0         32768 ?

    *> 20.20.20.20/32   10.19.20.20             11         32768 ?

    * i128.0.0.0/1      2.2.2.2                 20    100      0 ?

    *>                  10.19.20.20             20         32768 ?

     

    The 0.0.0.0/1 did NOT make it in!...however, its other half counterpart made it into BGP with no issues. 

     

    I decided to try this:

    PE1:

      router bgp 100

      address-family ipv4 unicast vrf A

      default-information originate 

     

     

    PE1#show bgp vpnv4 unicast all | b Net 

       Network          Next Hop            Metric LocPrf Weight Path

    Route Distinguisher: 10:10 (default for vrf A)

    *> 0.0.0.0/1        10.19.20.20             20         32768 ?

    * i1.1.1.1/32       2.2.2.2                 11    100      0 ?

    *>                  10.19.20.20             21         32768 ?

    *>i10.1.2.0/24      2.2.2.2                  0    100      0 ?

    *> 10.19.20.0/24    0.0.0.0                  0         32768 ?

    *> 20.20.20.20/32   10.19.20.20             11         32768 ?

    * i128.0.0.0/1      2.2.2.2                 20    100      0 ?

    *>                  10.19.20.20             20         32768 ?

     

     

    There is it!

     

    So why does BGP think that this is a default route, when its really not. I am going to try this out by dividing a default route into quarters (0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, 192.0.0.0/2)

     

  • So why does BGP think that this is a default route, when its really not. I am going to try this out by dividing a default route into quarters (0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, 192.0.0.0/2)

    Hi,

    Yes whatever the mask is,  if the network is 0.0.0.0/X it's considered as default-route anyway.

    That's why BGP considere doesn't install.

  • Can you please share with me where you read this from (what document/book, etc)? 

    Thank you!

    I also tried it with the quarters and still same result, the 0.0.0.0/2 does not get brought into BGP (the behavior that you are describing)

  • Hi Lucas

     

    I think this is correct.

     

    Essentially the mask does not matter.  If the network is 0.0.0.0 regardless of the mask then BGP will not include it in the BGP table unless you include the network 0.0.0.0 statement (with matching mask) or the default-information originate.

     

    Nick

  • Can you please share with me where you read this from (what document/book, etc)? 

    Thank you!

     

    I've no documment on that but its related to 0/0 network. The 0 in the mask is called "don't care" whille other value than 0 is called "care, match". So because the 0.0.0.0 all bits are 0 so there are all " don't care".

    So 0.0.0.0/1= 0.0.0.0/2=0.0.0.0/255===0.0.0.0/X.

    So all protocol considere 0/X as default route. Not only BGP. But the behaviour (treatement) of default route in each protocol is different.

     

    Don't hesitate if further explanation is needed.

    Thanks,

     

     

     

  • Hi Lucas

     

    I think this is correct.

     

    Essentially the mask does not matter.  If the network is 0.0.0.0 regardless of the mask then BGP will not include it in the BGP table unless you include the network 0.0.0.0 statement (with matching mask) or the default-information originate.

     

    Nick


     

    They say you can't argue with the facts. But I still don't agree with the reasoning though :) To me 0.0.0.0/1 is definitely not the same as 0.0.0.0/8. How do you represent all subnets in the lower half of IPv4 address space?

  • To me 0.0.0.0/1 is definitely not the same as 0.0.0.0/8. How do you represent all subnets in the lower half of IPv4 address space?

    Hi,

    Please refer to my answer above.

    yes 0.0.0.0/1= 0.0.0.0/2=0.0.0.0/255===0.0.0.0/X. It's specific to 0.0.0.0 network where dont care bit = care bit.

  • Hi,

    Please refer to my answer above.

    yes 0.0.0.0/1= 0.0.0.0/2=0.0.0.0/255===0.0.0.0/X. It's specific to 0.0.0.0 network where dont care bit = care bit.

    Yes, it would be considered as the default route because the prefix-length refers that the first bit would be checked which doesn't make any difference than a normal 0.0.0.0/0 default route. There can be either 0 or 1 as the first bit. So, this prefix has all 0s which makes it 0.0.0.0/0.

    HTH

  • To me 0.0.0.0/1 is definitely not the same as 0.0.0.0/8. How do you represent all subnets in the lower half of IPv4 address space?

    Hi,

    Please refer to my answer above.

    yes 0.0.0.0/1= 0.0.0.0/2=0.0.0.0/255===0.0.0.0/X. It's specific to 0.0.0.0 network where dont care bit = care bit.


     

    Consider the following prefix

    10.0.0.4/30

    Are you saying that both of the two "0" mean "don't care"?

  • Consider the following prefix

    10.0.0.4/30

    Are you saying that both of the two "0" mean "don't care"?

    Hi ,

    It is not the same subject we speack about the 0/X network not the 10 network or any other network.

    The 0.0.0.0/x is considered as default-route for any protocol (BGP, EIGRP, OSPF, RIP...) whatever the /x is.

    If you have any doubt, please lab it  and let us kow the result.

    Thanks,

  • Hi,

    If you were allowing 0.0.0.0/1 prefix into the routing domain, it would allow either 0 or 128 network since it could have 0 or 1 as the first bit. 

    So, here is the example, I hope it would clarify the doubt more effectively.

    R1#sh ip route ospf

         128.1.0.0/32 is subnetted, 1 subnets

    O       128.1.1.1 [110/11] via 10.1.12.2, 00:07:44, Ethernet0/0

    O*E2 0.0.0.0/0 [110/1] via 10.1.12.2, 00:07:44, Ethernet0/0

     

    R1#sh run | sec router ospf

    router ospf 1

     log-adjacency-changes

     network 10.1.12.1 0.0.0.0 area 0

     distribute-list 1 in

     

    R1#sh access-lists

    Standard IP access list 1

        10 permit 0.0.0.0, wildcard bits 128.255.255.255 (12 matches)

     

    R1#sh ip ospf database router 10.1.12.2

        Link connected to: a Stub Network

         (Link ID) Network/subnet number: 11.1.1.1

         (Link Data) Network Mask: 255.255.255.255

          Number of TOS metrics: 0

           TOS 0 Metrics: 1

    Since we have 11.1.1.1/32 network as well which is coming from R2, its not being installed into the routing table just because it doesn't match the ACL. :)

     

    Hope this helps!

     

  • Hari,

    I don't get it. 0.0.0.0/1 means the first bit is always 0,, right? And your ACL 1 supposed to be 127.255.255.255 since it is an inverse mask. Please clarify.

    Thanks,

    TVS

  • The 0.0.0.0/x is considered as default-route for any protocol (BGP, EIGRP, OSPF, RIP...) whatever the /x is.

    If you have any doubt, please lab it  and let us kow the result.

     

    I tend to think it's the 0 in /0 that makes a prefix match anything aka default route.

    What i'm getting at is the logic behind it, not what or how it's currently done. 

    Ultimately it's not an important issue.

     

  • Hari,

    I don't get it. 0.0.0.0/1 means the first bit is always 0,, right? And your ACL 1 supposed to be 127.255.255.255 since it is an inverse mask. Please clarify.

    Thanks,

    TVS

    Yes, you are right. It was mistakenly configured but the working one seamlessly :) because high order 7 bits were being matched which would also give the same result. But, it should be 127.255.255.255 that would match 0 or 128 network correctly. [8-|]

    Thanks! 

  • Hari,

    I don't get it. 0.0.0.0/1 means the first bit is always 0,, right? And your ACL 1 supposed to be 127.255.255.255 since it is an inverse mask. Please clarify.

    Thanks,

    TVS

    Yes, you are right. It was mistakenly configured but the working one seamlessly :) because high order 7 bits were being matched which would also give the same result. But, it should be 127.255.255.255 that would match 0 or 128 network correctly. Geeked

    Thanks! 

     

    Hari,

     

    No, I think you're wrong on this one.

     

    The ACL indeed matches both prefixes, but not for the reason you highlighted. Let's take a closer look here.

     

    Prefix 128.1.1.1/32 is equivaent to the following in binary format:

    10000000.00000001.00000001.00000001

     

    And 0.0.0.0/0 is equivalent to the following in binary format:

    00000000.00000000.00000000.00000000

     

    access-list 1 permit 0.0.0.0 128.255.255.255  when represented in binary format is equivalent to the following:

     

    00000000.00000000.00000000.00000000  <<<<< pattern bits

    10000000.11111111.11111111.11111111  <<<<< match bits, 0 == must match, 1 == don't care

     

    What this means is that the ACL will match any bit string that has 0 in all lower 7 bits in the most significant byte. Guess what? That includes both 128.1.1.1 and 0.0.0.0 !

     

     

    And lastly, the care/don't care thingy is a notion that applies to access-list only. For prefix-list a.b.c.d/n, there must be an exact match on the first n bits and that's it. Apply this rule to 0.0.0.0/0, you got a bit string that must be matched on the first ZREO (0) bits. Of course that matches everything!

    Of course, there's also a prefix-length element in a prefix. But that's not important to the discussion here.

  • Hi HS,

    Agree; Good point! my second opinion was not correct.

    Thanks,

Sign In or Register to comment.