Routing

Hi,

I am looking for a way of removing local /32 routes whenever a irb interface goes down. I have the setup in the picture. R3 runs LDP VPLS towards a primary Edge router (R1) and has a backup-neighbor to a secondary Edge router (R2). Irb interface on the secondary router remains down until the primary VPLS circuit fails. However the local /32 route (1.1.1.1/32) of the irb interface is still present in the routing table with next hop type "reject" even when the irb interface is down. At the same time R2 receives the bigger block (/29) from R1 via BGP which I want to be preferred. Is there anyway to remove the local route from the routing-table on R2 whenever the irb interface is down so that the BGP route from R1 will be used?

***** R2 show route *****
1.1.1.1/32 *[Local/0] 05:28:06
Reject

BGP route from R1:
***** R2 show route*****
1.1.1.0/29 *[BGP/170] 05:29:04, localpref 100, from x.x.x.x
AS path: I, validation-state: unverified
> to x.x.x.x via lt-1/1/0.4000

************ R1 CONFIGURATION ************

R1> show configuration routing-instances CUSTOMER_ACME
apply-groups INTERNET_VPLS_BACKHAUL_ER;
protocols {
vpls {
vpls-id 100;
neighbor 10.10.10.3 {
pseudowire-status-tlv;
}
}
}
bridge-domains {
CUSTOMER_ACME {
domain-type bridge;
vlan-id 100;
routing-interface irb.100;
}
}
}
}

R1> show configuration interfaces irb.100
description CUSTOMER_ACME;
family inet {
address 1.1.1.1/29;
}
mac 44:f4:77:12:d3:58;

************ R2 CONFIGURATION (same as R1) ************
R2> show configuration routing-instances CUSTOMER_ACME
apply-groups INTERNET_VPLS_BACKHAUL_ER;
protocols {
vpls {
vpls-id 100;
neighbor 10.10.10.3 {
pseudowire-status-tlv;
}
}
}
bridge-domains {
CUSTOMER_ACME {
domain-type bridge;
vlan-id 100;
routing-interface irb.100;
}
}
}
}

R2> show configuration interfaces irb.100
description CUSTOMER_ACME;
family inet {
address 1.1.1.1/29;
}
mac 44:f4:77:12:d3:58;

************ R2 CONFIGURATION ************

R3> show configuration routing-instances CUSTOMER_ACME
apply-groups INTERNET_VPLS_BACKHAUL_PE;
interface ge-0/0/0.100;
protocols {
vpls {
vpls-id 100;
neighbor 10.10.10.1 {
pseudowire-status-tlv;
revert-time 20;
backup-neighbor 10.10.10.2;
}
}
}
}
}

Hello,

Short answer - filtering of local and direct routes from their primary RIB is not supported.

Long answer - I wonder what exact problem You are trying to solve? I understand that perhaps ISP2 cannot "ping" the 1.1.1.1 IRB IP on R2 (albeit they should receive ICMP Unreach instead of Echo Reply) - other than that, is there any other actual issue You haven't mentioned ?

HTH

Thx

Alex

Hi Alex,

Ok then I know it's not possible to filter out local and direct routes.

But you are absolutely right. Pinging 1.1.1.1 is the only thing that doesn't work, in the cases the ping comes from the Internet from ISP2 (from ISP1 it works fine obviously).

Traffic towards the customer firewall 1.1.1.2 works from any direction. But still it is still a very 'nice to have' to be able to ping the 1.1.1.1 from anywhere. Mostly for trouble-shooting reasons. But as I inderstand there is no way to get that to work in the current design then.

Just to get some background on the design in case you can suggest a better way of doing this.

We are a provider of mostly L2/L3 VPN's. However some customer's requires Internet circuits aswell. Given the lack of public IP space these days we are very short of public IP adresses (we are in Europe and RIPE will not hand out any more blocks). That's why we can't 'afford' to waste the space we have to have public IP addresses all over our network (approximately 100 MX104 PE routers). And that is why we want to backhaul all Internet traffic via L2 to two MX's which carries all the public IP's. 

And to be able to use two ISP's for redundancy this is the only way I can think of. I like the concept of pseudowire redundancy connecting to L3 interfaces although I can't find a good way of doing it in Junos. I have previously worked a lot with Nokia/Alcatel which has a very good implementation for this in their routers.

Given this information. Is there another way you would consider doing this Alex?

Reccy

Hello,

AFAIK, "connectivity-type permament" knob should solve Your immediate ping problem by keeping the IRB IFL Up

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/connectivity-type-edit-protocols-vpls.html

But I would argue that allocating /29 per customer is a monumental waste of IPv4 address space.

I understand the demand for L2 separation but ideally You should allocate /32 which is possible with PPPOE subscriber management or at least /31 which is possible with same IP+same MAC on IRB, with exceptions for customers requiring more than 1 public IPv4 address. 

In the longer term, You should look at running IPv4 as a service across IPv6-only network. Some US providers are already doing it, and it is bound to grow. 

HTH

Thx

Alex

Ok. Yes I do have the "connectivity-type permament" in the apply-group in the routing-instance. Sorry for not showing that configuration.

Usually we use /31 link to our customers so the /29 was a bad example.

Running IPv4 over IPv6 sounds really like an interesting way to go. I will read more on that.

Thanks a lot for all the help Alex!