Routing

I'm learning a /24 route dynamically (OSPF) and when (and only when) I learn this route, I want to advertise a /32 that is part of the /24 to an eBGP neighbor. I do not want to send them the entire prefix (What if it was a /8 route or something). This is a redundant path, so I do not want to configure a static route for the host. 

 

Is there a solution for this beyond sending them the entire /24 route?

A generated route does not seem to work unless the contributing routes are part of the generated route. For instance it seems I could generate a 0.0.0.0/0 for any route I want to match, but theoretically a generated route could never be a host route.

 

Thanks in advance.

@ChoWZa-

 

One way that this can be accomplished is through the use of static routes.

 

Consider the following topology:

 

R1_ge-0/0/1 <OSPF> ge-0/0/1_D1_ge-0/0/3 <OSPF> ge-0/0/3_D2_ge-0/0/2 <eBGP> ge-0/0/2_D6

 

R1 is advertising 192.168/24, and D2 wants to advertise 192.168.0.5/32 to D6 only when it has a route to 192.168/24.

 

In this example, D2 has a static route that looks like this:

 

root@D2# show routing-options static
route 192.168.0.5/32 {
    next-hop 192.168.0.1;
    resolve;
}
[edit]

 

 This means that as long as D2 has a route to 192.168.0.1, it will install 192.168.0.5/32 in its routing table.  Since 192.168.0.1 is contained with 192.168/24, then whenever there is a route to 192.168/24, 192.168.0.5 will be installed in the routing table.

 

This can clearly become an issue--what if there are multiple next hops (well, you could just add them, but this is clumsy), what if the route is getting advertised from the OSPF neighbor but the next-hop you specified isn't reachable, and so on.  It obviously fails your criteria of "I don't want a static route."

 

One way to get around the above shortcomings is to use a combination of "receive" and "conditions."  See below:

 

 

root@D2# show policy-options
prefix-list 192_168_0_5 {
    192.168.0.5/32;
}
policy-statement ADV_192_168_0_5 {
    from {
        prefix-list 192_168_0_5;
        condition IF_192_168_0_0_24;
    }
    then accept;
}
condition IF_192_168_0_0_24 {
    if-route-exists {
        192.168.0.0/24;
        table inet.0;
    }
}

[edit]
root@D2# show routing-options
static {
    route 192.168.0.5/32 receive;
    route 0.0.0.0/0 discard;
}

[edit]

 

This sort of violates your "I don't want static routes" requirement, but it does so in what should a (more or less) harmless manner as the router will pass it along to whatever route it's supposed to use.

 

I haven't tested this in a live, production environment.  It has been tested in a lab environment, though, and appears to work as intended.  When I shut down the /24, the /32 route is no longer advertised via BGP.  As soon as I bring the /24 back up, the /32 is once again advertised via BGP.

 

[edit]

For future clarity, the `no-install` knob should be added to the `receive` route.  It's all discussed later in the thread.

[/edit]

Great idea. 

I was unaware of the condition option.. Does next-hop receive direct the device to treat the IP as if it were assigned to the device itself (as in the loopback?). I appreciate it if you tested this, however, I might expect the static receive route to black hole actual transit traffic to that IP address based on next-hop receive, as it may bypass normal routing and send it to the routing engine as if it were traffic destined to an interface. Did you actually try to ping an IP address or just test the actual exporting of the route? I think I can run with this idea regardless using a static route pointing to a different routing instance, and only export it based on the condition of an "if-route-exists" of a dynamically learned /24.

 

Another thought would be to create the static route, with a no-install option, to prevent it from being used for forwarding look-ups. Then the normal dynamic routes would be used, if I understand it correctly.

 

Any further input would be appreciated.

 

Thanks!

@ChoWZa

 

I did test this in a lab environment.  I pinged from D6 to 192.168.0.5 (which is configured on R1, passing through both D2 (where the `receive` route is configured) and D1.  I only meant that I have not tested a setup like this in a production environment (and have no plans to as I have no need for it:)).

 

D6

root@D6> show route 192.168.0.5/32 terse | find next
A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 192.168.0.5/32     B 170        100                             65000 I
  unverified                                       >172.16.0.0

root@D6> ping 192.168.0.5 count 1
PING 192.168.0.5 (192.168.0.5): 56 data bytes
64 bytes from 192.168.0.5: icmp_seq=0 ttl=64 time=14.275 ms

--- 192.168.0.5 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.275/14.275/14.275/0.000 ms

root@D6>

D2

root@D2> show route 192.168.0.5/32 terse | find next
A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 192.168.0.5/32     S   5                        Receive

R1

root@R1> show route 192.168.0.5/32 terse | find next
A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 192.168.0.5/32     L   0                        Local

Now, I show disabling the interface with the /24 route on D1 (it's an OSPF interface, so disabling from R1 is no good--this is simply because of the way I did this. If I had configured it as loopback on R1, I could just disable the loopback on R1.) and the effect is has elsewhere

D1

root@D1# deactivate interfaces ge-0/0/1

[edit]
root@D1# commit
commit complete

[edit]

R2

root@D2> show route 192.168.0.5/32 terse | find next
A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 192.168.0.5/32     S   5                        Receive

D6

root@D6> show route 192.168.0.5/32 terse

root@D6>

As you can see, this has the effect you were looking for. Note that D2 maintains the receive route, but since you shouldn't be exporting this policy in any other manner, it won't affect the rest of your topology.

 

[edit]

Regarding the actual function of `receive`, it is (unfortunately) very poorly documented.  It might get processed by the RE when locally generated but not when the flow is transit traffic.  This is somewhat supported by the fact that transit traffic passes without an issue, but locally-generated traffic fails, even when specifying a source:

 

root@D2> ping 192.168.0.5 source 10.1.2.2
PING 192.168.0.5 (192.168.0.5): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- 192.168.0.5 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

root@D2>

 

Again, this shouldn't have an impact if this is the way it works.  You should, however, thoroughly test this and possibly even open a JTAC case to determine the exact operation of the `receive` knob.

[/edit]

[edit 2]

Further digging is, unfortunately, not very fruitful.  The index of the next hop is `33`, but I can't find anything with an index of `33`.  I'm sure it's hiding somewhere, but I can't find it.  Maybe someone more knowledgeable than I will be able to help demystify the `receive` knob.

 

root@D2> show route forwarding-table destination 192.168.0.5
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
192.168.0.5/32     user     0                    recv    33     1

Routing table: __master.anon__.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            perm     0                    rjct   523     1

root@D2> show interfaces lo0 | match index
  Interface index: 6, SNMP ifIndex: 6
  Logical interface lo0.16384 (Index 64) (SNMP ifIndex 21)
  Logical interface lo0.16385 (Index 65) (SNMP ifIndex 22)
  Logical interface lo0.32768 (Index 66) (SNMP ifIndex 250)

root@D2> show snmp mib walk ifName | match 33

root@D2>

[/edit 2]

I did a bit of testing as well. I think I may use something very similar, except I will readvertise a discard/no-insall static route based on the if-route-exists condition. Using the "receive" route makes me a bit uneasy, I think i'd rather just use a route that exists always in the routing table but never in the forwarding table.

If you manage to get that to work, please post. I spent about two minutes trying to get it to work that way with no success. I'm sure there's an option in policies or BGP to advertise a static 'no-install' (I know of the 'advertise-inactive' knob, but don't think it works any magic for static 'no-install' routes).

A 'no-install' route isn't the same as an 'inactive' route, and you definitely do NOT want a static discard active in the RIB/FIB.

Sure, I tried something along these lines (haven't tried with actual transit traffic yet).. I deleted the bogus 4.2.2.2/32 static route that I had added and it stopped advertising my "1.1.1.1" route for example. In my test I was checking for a route existing in another routing-instance (source-vr), and advertising the static discard no-install route to a BGP peer on the test-vr. This was successful.

 

set routing-instances source-vr routing-options static route 4.2.2.2/32 next-hop x.x.x.x

set routing-instances test-vr routing-options static route 1.1.1.1/32 discard

set routing-instances test-vr routing-options static route 1.1.1.1/32 no-install

set policy-options policy-statement ADV_1_1_1_1 from instance test-vr
set policy-options policy-statement ADV_1_1_1_1 from protocol static
set policy-options policy-statement ADV_1_1_1_1 from route-filter 1.1.1.1/32 exact
set policy-options policy-statement ADV_1_1_1_1 from condition IF_ROUTE
set policy-options policy-statement ADV_1_1_1_1 then accept

set policy-options condition IF_ROUTE if-route-exists 4.2.2.2/32
set policy-options condition IF_ROUTE if-route-exists table source-vr.inet.0

 

If there are any transit traffic issues with my discard/no-install I can use a static next-table route in this scenario, however, I would like to find a solution for this type of setup that isn't dependent on multiple VR's for this sort of implementation, other than using the receive route.

Interesting. Does this only work with routing instances? I could've sworn I tried to advertise a static no-install route when I was testing and it didn't work, although maybe I was just in a hurry.

the static routes with receive nh are punted to RE:

 

[pfe-1]: 0x1081fad8a0000021
ModifyNH: Subcode=SetErr(2),Desc=0x7eb62,Data=0x21,NextNH=1
(queue:0, oif:131080 .punt.0, reason:32 host route)

 

RE can answer remote ping request even there are no local addresses configured ( with the source address - the primary system address) - so it will blackhole the transit traffic 

 

Krasi

---

@Krasi wrote:

the static routes with receive nh are punted to RE:

 

[pfe-1]: 0x1081fad8a0000021
ModifyNH: Subcode=SetErr(2),Desc=0x7eb62,Data=0x21,NextNH=1
(queue:0, oif:131080 .punt.0, reason:32 host route)

 

RE can answer remote ping request even there are no local addresses configured ( with the source address - the primary system address) - so it will blackhole the transit traffic 

 

Krasi

---

I hate to disagree, but all testing indicates that a `receive` next hop does not blackhole transit traffic.  I tested this in a serial topology in which the traffic could only possibly go through the router with the `receive` route, and traffic passed without any issue.  See my post above with the example ping output.

Tyler,

 

Is it possible the RE was actually replying to your pings? Maybe try SSH to the receive route IP, or dropping ICMP on the loopback interface if you still have this set up.

It's not impossible. I'll create some filters test later today.

@ChoWZa-

 

It seems that @Krasi was correct, although I suppose it depends on how you define black-holing traffic.

 

The RE on D2 was indeed responding to the ICMP requests, so they weren't reaching their intended destination.

 

I did some additional labbing and looking around, though.  You should be able to make it work with my solution if you add the `no-install` option on the static receive route.  This prevents the receive route from being installed in the FIB (although it will still appear in the RIB), which means no black-holing traffic.

 

D2

root@D2# run show route 192.168.0.5/32 terse | find next
A V Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* ? 192.168.0.5/32     S   5                        Receive

[edit]
root@D2# show routing-options static route 192.168.0.5/32
receive;
no-install;

[edit]
root@D2# run show route forwarding-table destination 192.168.0.5
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
192.168.0.0/24     user     0 10.1.2.1           ucst   560     3 ge-0/0/3.0

Routing table: __master.anon__.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            perm     0                    rjct   523     1

[edit]

D6

root@D6> ping 192.168.0.5 count 5
PING 192.168.0.5 (192.168.0.5): 56 data bytes
64 bytes from 192.168.0.5: icmp_seq=0 ttl=62 time=23.712 ms
64 bytes from 192.168.0.5: icmp_seq=1 ttl=62 time=20.609 ms
64 bytes from 192.168.0.5: icmp_seq=2 ttl=62 time=20.728 ms
64 bytes from 192.168.0.5: icmp_seq=3 ttl=62 time=20.717 ms
64 bytes from 192.168.0.5: icmp_seq=4 ttl=62 time=20.752 ms

--- 192.168.0.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 20.609/21.304/23.712/1.205 ms

root@D6>

R1

root@R1# show firewall
family inet {
    filter CATCH_192_168_0_5 {
        term if-192_168_0_5 {
            from {
                destination-address {
                    192.168.0.5/32;
                }
            }
            then {
                count MATCHED;
                accept;
            }
        }
        term else {
            then accept;
        }
    }
}

[edit]
root@R1# show interfaces ge-0/0/1
unit 0 {
    family inet {
        filter {
            input CATCH_192_168_0_5;
        }
        address 192.168.0.5/24;
    }
}

[edit]
root@R1# run show firewall filter CATCH_192_168_0_5 counter MATCHED

Filter: CATCH_192_168_0_5
Counters:
Name                                                Bytes              Packets
MATCHED                                               420                    5

[edit]

Okay glad we got to the bottom of it. I am using the discard/no-install route but receive/no-install would accomplish the same result.