Routing

Hello everyone. Gotta an issue I've been struggling with. I have this iBGP peering taking place between a QFX5100 and a MX104. Goal is to grab IX routes from one of my POPs, get them into VRF, export routes to be able to import directly into other VRF enabled POPs, and finally inject into my MX routers in another city. I'm stuck with a VR on the MXs for another 6 months, else I'd be running into VRF on those as well and would only have to import the target communities... I dabbled with rib groups but it's not doing it for me for many reasons, so I went for the iBGP peeing instead.

QFX: Peering taking place from inside VRF

MX: PEering taking place from insidei VR

QFX is advertizing a route to MX and we can see it's sent, but MX doesn't see the route coming in from QFX even in hidden route.

==============================

#run show route advertising-protocol bgp 50.21.165.2 detail

TORIX.inet.0: 167 destinations, 169 routes (167 active, 0 holddown, 0 hidden)
* 1.0.4.0/24 (2 entries, 1 announced)
BGP group BGP-BLENDED type Internal
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65401] 29909 11670 6939 4826 38803 38803 38803 38803 56203 I (Originator)
Cluster list: 10.24.0.5 10.25.0.1
Originator ID: 10.25.0.4
Communities: 65401:11670 target:65401:11670 target:65401:11674 target:65401:11677

==================================

# ... bgp 50.21.165.3 table BGP-BLENDED.inet.0 hidden extensive

BGP-BLENDED.inet.0: 681709 destinations, 3409260 routes (681700 active, 0 holddown, 139 hidden)
50.21.165.2/31 (2 entries, 1 announced)
Nexthop: 50.21.165.3
Localpref: 100
AS path: I
Hidden reason: rejected by import policy

206.108.34.0/23 (1 entry, 0 announced)
Nexthop: 50.21.165.3
Localpref: 100
AS path: I (Originator)
Cluster list: 10.24.0.5 10.25.0.1
Originator ID: 10.25.0.4
Communities: target:65401:11670 target:65401:11672
Hidden reason: rejected by import policy

=========

I know why the two routes on there are rejected by MX, but that's ok. What I want to know if why MX isn't seeing the 1.0.4.0/24 route, which is clearly sent.

So, what can I show you to check this out. I was hoping I wouldn't have to open another ticket with tac, giving it a shot here.

Thanks.

Hi,

Few things wanted to clarify:

1. The route 1.0.4.0/24 on QFX - what is the origin of this route. How is QFX learning this route?

2. If you do a "show route receive-protocol bgp 50.21.165.3" do you see this route in the BGP RIB In? If QFX is advertising this route, then on MX, it will first come in BGP RIB in and then it will evaluate if there is any import policy applied.

3. Long shot, but if you do a "show route 1.0.4.0/24" on MX, do you see this route anywhere in any table?

4. If would be good to have the BGP configuration of both QFX and MX for quick reference.

Thanks

1- Route is learned this way:

IX --  eBGP -- QFX -- VRF MP-BGP target:XXXX:XXX export -- import -- QFX -- iBGP -- MX (VR)

2- The output of that command is in my first post, route is not seen in received-routes.

3- It is in the routing table, learned from T1 ISPs... And oh my, I can see it now when it wasn't for the last two days...

metronoc@cr1080bgp> show route 1.0.4.0/24

BGP-BLENDED.inet.0: 681697 destinations, 3410324 routes (681688 active, 0 holddown, 139 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.4.0/24 *[BGP/170] 1d 11:47:55, MED 92, localpref 100
AS path: 3257 4826 38803 38803 38803 38803 56203 I, validation-state: unverified
> to 199.168.63.9 via ae0.401
[BGP/170] 1d 11:47:55, MED 92, localpref 100
AS path: 3257 4826 38803 38803 38803 38803 56203 I, validation-state: unverified
> to 50.21.172.228 via ae0.3
[BGP/170] 1d 11:47:55, localpref 100
AS path: 1299 4826 38803 38803 38803 38803 56203 I, validation-state: unverified
> to 213.248.86.225 via ae0.270
[BGP/170] 1d 11:49:40, localpref 100
AS path: 13768 4637 1221 38803 38803 38803 56203 I, validation-state: unverified
> to 66.199.136.25 via ae0.981
[BGP/170] 1d 11:47:56, MED 0, localpref 100
AS path: 6939 4826 38803 38803 38803 38803 56203 I, validation-state: unverified
> to 198.179.18.5 via ae0.300
[BGP/170] 1d 11:47:55, MED 0, localpref 100
AS path: 5580 3257 4826 38803 38803 38803 38803 56203 I, validation-state: unverified
> to 78.152.37.225 via ae0.3518
[BGP/170] 01:36:26, localpref 100
AS path: 29909 11670 6939 4826 38803 38803 38803 38803 56203 I, validation-state: unverified
> to 50.21.165.3 via ae0.833

metronoc@cr1080bgp> show route receive-protocol bgp 50.21.165.3 table BGP-BLENDED.inet.0

BGP-BLENDED.inet.0: 681691 destinations, 3410308 routes (681682 active, 0 holddown, 139 hidden)
Prefix Nexthop MED Lclpref AS path
1.0.4.0/24 50.21.165.3 100 29909 11670 6939 4826 38803 38803 38803 38803 56203 I

I'm baffled into how this could possibly be. I've been turning this one around for the last 2-3 days. I've added this is the BGP peering on MX earlier today, but the route was still not learned at that time:

family inet {
unicast {
loops 2;
}

Since I'm exporting and importing from VRF to hand over iBGP, QFXs on both sides were rejecting the routes because of seen loops, my underlay's ASN being private, it really gives something like 29909 [65401] 29909 BLAH BLAH. In this perticular case though, MX wasn't showing me the route as rejected, it was just NOT seeing the damned thing come in.

Yeah it was the loop thing, weird MX didn't let me know. **bleep** you MX.

BGP-BLENDED.inet.0: 681732 destinations, 3410466 routes (681723 active, 0 holddown, 139 hidden)
1.0.4.0/24 (7 entries, 1 announced)
Accepted
Nexthop: 50.21.165.3
Localpref: 100
AS path: 29909 11670 6939 4826 38803 38803 38803 38803 56203 I (Originator) (Looped: 29909)
Cluster list: 10.24.0.5 10.25.0.1
Originator ID: 10.25.0.4
Communities: 65401:11670 target:65401:11670 target:65401:11674 target:65401:11677

Hi,

Good to know you figured out that it is because of loops. Ideally if you turn on BGP traceoptions, we should see MX reporting some reason for not accepting that route.

Thanks

Hello,

---

@philippegirard wrote:

Yeah it was the loop thing, weird MX didn't let me know. 

 

 

---

I wonder what do You expect MX to do for You in this case (send email/flash lights/beep/spin fans at full speed/anything else?) and have You managed to read the documentation yet?

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/keep-edit-protocols-bgp.html

Default

By default, BGP retains incoming rejected routes in memory and hides them. If you do not include the keep statement, most routes are retained in the routing table. BGP keeps all route information that was learned from BGP, except for routes whose AS path is looped and whose loop includes the local AS.

Apart from the above link, "keep all" is discussed in JNCIP Study Guide by Harry Reynolds.

HTH

Thx
Alex

You know, your post would have been nice without the sarcasm. One would think that I've checked the documentation since I had actually found the solution.

QFX was hiding the route with something like this in extensive:

AS path: 29909 11670 6939 4826 38803 38803 38803 38803 56203 I (Originator) (Looped: 29909)
Cluster list: 10.24.0.5 10.25.0.1
Originator ID: 10.25.0.4
Communities: 65401:11670 target:65401:11670 target:65401:11677
Import
VPN Label: 2294
Router ID: 10.24.0.5
Hidden reason: AS path loop

MX was not showing the route wither in hidden or other queries.

I'd ask you not to answer my questions if you're to be insulting.