Hey!
Being a bit unsatisfied with a pair of MX104 turning themselves as a
blackhole during BGP convergence, I am trying to reduce the size of the
FIB.
I am in a simple situation: one upstream on each router, an iBGP session
between the two routers. I am also receiving a default route along the
full feed.
I have tried the simple approach of rejecting routes learned from BGP
with a combination of prefix length and AS path length:
https://github.com/vincentbernat/network-lab/blob/c4e7647b65fb954afbfc67378171451e967a4b9b/lab-vmx-fullview/vMX2.conf#L63-L122
I didn't try for real, but on a small lab using vMX, the FIB size is
divided by 20, which should be quite enough.
I have tried a smarter approach:
https://github.com/vincentbernat/network-lab/blob/c4e7647b65fb954afbfc67378171451e967a4b9b/lab-vmx-fullview/vMX1.conf#L71-L121
Unfortunately, the condition system seems not powerful enough to express
what I want:
1. Accept the default route.
2. Reject any small route (ge /25).
3. Reject any route with the same next-hop as the default route.
4. Accept everything else.
Currently, I was able to achieve this:
3. Reject any route using upstream as next-hop (with the assumption
that we have a default route to upstream since it would come from
the same eBGP session).
4. Accept everything else.
This is not satisfactory because if upstream becomes unavailable, a lot
of routes will be programmed in the FIB.
If the condition system would allow me to match a next-hop or an
interface in addition to a route, I could do:
3. Reject any route with upstream as next-hop if there is a default
route to upstream.
4. Reject any route with peer as next-hop if there is a default route
to peer.
5. Accept everything else.
This way, only routes to peer would be put in FIB (and they are far less
numerous than routes to upstream). Eventually, those routes could be
trimmed down with prefix-length and AS path-length too.
The condition could look like this:
#v+
policy-options {
condition default-to-upstream {
if-route-exists {
0.0.0.0/0;
next-hop 192.0.2.0;
}
}
condition default-to-peer {
if-route-exists {
0.0.0.0/0;
next-hop 192.0.2.129;
}
}
}
#v-
I think that I will simply keep the first approach (just using AS
path-length and prefix-length of individual routes) but I would welcome
any comments and tips on how to optimize the FIB (notably prior work).
Thanks!
--
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Being a bit unsatisfied with a pair of MX104 turning themselves as a
blackhole during BGP convergence, I am trying to reduce the size of the
FIB.
I am in a simple situation: one upstream on each router, an iBGP session
between the two routers. I am also receiving a default route along the
full feed.
I have tried the simple approach of rejecting routes learned from BGP
with a combination of prefix length and AS path length:
https://github.com/vincentbernat/network-lab/blob/c4e7647b65fb954afbfc67378171451e967a4b9b/lab-vmx-fullview/vMX2.conf#L63-L122
I didn't try for real, but on a small lab using vMX, the FIB size is
divided by 20, which should be quite enough.
I have tried a smarter approach:
https://github.com/vincentbernat/network-lab/blob/c4e7647b65fb954afbfc67378171451e967a4b9b/lab-vmx-fullview/vMX1.conf#L71-L121
Unfortunately, the condition system seems not powerful enough to express
what I want:
1. Accept the default route.
2. Reject any small route (ge /25).
3. Reject any route with the same next-hop as the default route.
4. Accept everything else.
Currently, I was able to achieve this:
3. Reject any route using upstream as next-hop (with the assumption
that we have a default route to upstream since it would come from
the same eBGP session).
4. Accept everything else.
This is not satisfactory because if upstream becomes unavailable, a lot
of routes will be programmed in the FIB.
If the condition system would allow me to match a next-hop or an
interface in addition to a route, I could do:
3. Reject any route with upstream as next-hop if there is a default
route to upstream.
4. Reject any route with peer as next-hop if there is a default route
to peer.
5. Accept everything else.
This way, only routes to peer would be put in FIB (and they are far less
numerous than routes to upstream). Eventually, those routes could be
trimmed down with prefix-length and AS path-length too.
The condition could look like this:
#v+
policy-options {
condition default-to-upstream {
if-route-exists {
0.0.0.0/0;
next-hop 192.0.2.0;
}
}
condition default-to-peer {
if-route-exists {
0.0.0.0/0;
next-hop 192.0.2.129;
}
}
}
#v-
I think that I will simply keep the first approach (just using AS
path-length and prefix-length of individual routes) but I would welcome
any comments and tips on how to optimize the FIB (notably prior work).
Thanks!
--
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp