18 Nov
2014
18 Nov
'14
11:05 a.m.
Brian, Chris, thank you for your efforts.
I took a look at the latest sent encap info and I want to bring in
discussion the way how some gateways are announced.
route addprivate 44.24.240/20 encap 44.24.221.1
Now this one is ok. The gateway (44.24.221.1) is BGP announced, but not in
the encap file. Everything ok and working.
Now to the other two IMHO are wrong:
route addprivate 44.151.94.28/32 encap 44.151.94.28
So this host expects to get encapsulated traffic to a gateway which is the
host itself. This leeds to a routing loop and is not possible with a regular
setup.
This encap entry is in fact plain and simple useless: It states 'you can
reach me via me' which gives not much information.
route addprivate 44.140/16 encap 44.140.0.1
The
same applies to the above, just that the whole subnet is routed to a
gateway which is part of that subnet itself.
The idea is that a route can not point to a gateway for which the route is
resolved by the route itself.
It may be said that those are BGP routed subnets and the gateway is directly
reacheable.
But the routing is resolved by the route with the most specific netmask. In
this case exactly the one which defines the host (or subnet) itself.
Unless there is a mechanism available to mark those gateways and create a
higher priority route to them so they can be reached directly, this is not
functional.
Please comment on a possible sollution/approach on those setups.
73s de Marius, YO2LOJ