0

I have setup with several routers where 1 is external eBGP router with 2 iBGP routers. Here the topology

Routes are coming from eBGP peer are landing to Routing-Instance Ext and after that their are moved to inet.0 or master table. Then you can see iBGP peering via inet.0 and external routes that are accepted from eBGP neighbour accepted in eBGP last neighbour without next-hop self policy.

This is simple GNS3 based test lab. First router is ios vm, but vendor doesn't matter for this case:

ip route 5.0.0.0 255.255.255.0 Null0
router bgp 1
 bgp log-neighbor-changes
 network 5.0.0.0 mask 255.255.255.0
 neighbor 10.0.0.1 remote-as 2

vMX which has several RIs looks like this and no special policies exist on all routers so no next hop self statements exists:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.0.0.1/31;
            }}}
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.0.100.0/31;
            }}}
}
routing-options {
    instance-import route_import_master;
}
protocols {
    bgp {
        group iBGP {
            local-as 2;
            neighbor 10.0.100.1 {
                peer-as 2;
            }}}
}
policy-options {
    policy-statement route_import_master {
        term From_Ext {
            from {
                instance Ext;
                protocol bgp;
            }
            then accept;
        }
        then reject;
    }
}                                       
routing-instances {
    Ext {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        protocols {
            bgp {
                group eBGP {
                    local-as 2;
                    neighbor 10.0.0.0 {
                        peer-as 1;
                    }}}}}}

Here the result routes where we can se route 5.0.0.0/24 exported to master routing table:

>show route 

inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.0.0.0/24         *[BGP/170] 00:02:13, MED 0, localpref 100
                      AS path: 1 I, validation-state: unverified
                    > to 10.0.0.0 via ge-0/0/0.0

Ext.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.0.0.0/24         *[BGP/170] 00:02:13, MED 0, localpref 100
                      AS path: 1 I, validation-state: unverified
                    > to 10.0.0.0 via ge-0/0/0.0

Next my iBGP only router:

interfaces {
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.0.100.1/31;
            }}}
}
protocols {
    bgp {
        group iBGP {
            local-as 2;
            neighbor 10.0.100.0 {
                peer-as 2;
            }}}}

Next we can see that 5.0.0.0/24 accepted and installed to routing table


inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 5.0.0.0/24              10.0.100.0           0       100        1 I

root> show route 5.0.0.0/24                         

inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.0.0.0/24         *[BGP/170] 00:13:10, MED 0, localpref 100
                      AS path: 1 I, validation-state: unverified
                    > to 10.0.100.0 via ge-0/0/1.0

Moreover when I issue ping to my topmost eBGP neigbour to IP 5.0.0.1, looks lite packet reaches eBGP router.

BGP1#debug  ip icmp 
ICMP packet debugging is on
BGP1#
*Dec 26 18:22:06.191: ICMP: dst (5.0.0.1) host unreachable sent to 10.0.100.1
*Dec 26 18:22:07.179: ICMP: dst (5.0.0.1) host unreachable sent to 10.0.100.1

Does this breaks essential iBGP rules?

Improve this question
3
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin ♦
    Dec 31, 2020 at 20:47
  • @RonMaupin Sorry no, there is no answer. I try to find id by myself or delete post if I don't find the answer.
    – Tomato
    Jan 1, 2021 at 20:26
  • OK, thanks. I was doing the year-end cleanup to see if we could resolve open questions with answers. The last I looked, we have 666 questions with no answers or no accepted answers. I have answered some with no answers, and I have posted in chat to see if other can look at the questions with no answers.
    – Ron Maupin ♦
    Jan 1, 2021 at 20:29

1 Answer 1

Reset to default
2

What rule do you think it breaks?

Note, when leaking BGP routes from your Ext VRF to master.inet.0 you need to take care to also leak the routes used by BGP as next-hops. If you neglect this, the leaked BGP routes may not be valid for master.inet.0.

Improve this answer
3
  • I mean when we advertise something in iBGP then the next hop IP address doesn't change and we can change this with the next-hop-self command. This works as expected in case using one routing instance but when looks like after importing routes from different RI this behaviour changes. BTW I add additional info to first post ;-)
    – Tomato
    Dec 26, 2020 at 18:39
  • 1
    @Tomato, you should include BGP and Interface configuration so we know exactly what next hops we're looking for.
    – ditrapanij
    Dec 27, 2020 at 4:49
  • @ditrapanij of course. Maybe this is default behaviour but I can't find it in docs. If you can please drop link to documentation, thanks.
    – Tomato
    Dec 27, 2020 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.