Hi! When I list routes with "show ip route" I get a recursive route as in 202.168.1.1/32 [20,20] via 10.0.2.1 (recursive is directly connected, eth1) This route is imported via multi-hop eBGP. Is the recursive route a warning for a possible loop or is it just an indication that BGP has figured out the next-hop from the rest of the information in the routing table? Thanks, Dragos
This looks normal, if BGP installs a nexthop that is not directly connected, it needs to be recursively resolved via the routing table to an adjacent nexthop or (as in your case) to a connected interface route. Regards, Barry On Mon, Mar 1, 2010 at 8:13 AM, Dragos Ilie <dragos.ilie@...> wrote: > Hi! > > When I list routes with "show ip route" I get a recursive route as in > > 202.168.1.1/32 [20,20] via 10.0.2.1 (recursive is directly connected, eth1) > > This route is imported via multi-hop eBGP. Is the recursive route a > warning for a possible loop or is it just an indication that BGP has > figured out the next-hop from the rest of the information in the > routing table? > > Thanks, > Dragos > _______________________________________________ > Quagga-users mailing list > Quagga-users@... > http://lists.quagga.net/mailman/listinfo/quagga-users >
What version of Quagga are you running? The error indicates that the sanity check for MP_REACH_NLRI is failing in that the NLRI prefix length values add up to more than the attribute length (this is the overflow indicated in the error message). Can you post a tcpdump capture file of the BGP messages on the offending session (use -s 0 to get full packet captures)? Thanks, Barry On Sat, Feb 27, 2010 at 8:39 PM, Jan Hugo Prins <jhp@...> wrote: > Hello, > > This evening one of my BGP routers started misbehaving and I found the > following in my Debug logs: > > 2010/02/28 05:32:50 BGP: 2001:1540:800:4000::3:1 rcvd UPDATE w/ attr: , > origin i, mp_nexthop 2001:1540:800:4000::3:1(fe80::20c:dbff:fee0:7600), > path 16243 24875 2914 35320 > 2010/02/28 05:32:50 BGP: 2001:1540:800:4000::3:1 rcvd 2a02:5f0::/32 > 2010/02/28 05:32:50 BGP: 2001:1540:800:4000::3:1 rcvd UPDATE w/ attr: , > origin i, mp_nexthop 2001:1540:800:4000::3:1(fe80::20c:dbff:fee0:7600), > path 16243 13030 29056 44329 > 2010/02/28 05:32:50 BGP: 2001:1540:800:4000::3:1 rcvd 2001:67c:ac::/48 > 2010/02/28 05:32:50 BGP: 2001:1540:800:4000::3:1 rcvd UPDATE w/ attr: , > origin i, mp_nexthop 2001:1540:800:4000::3:1(fe80::20c:dbff:fee0:7600), > path 16243 6939 10026 9989 4844(Continue reading)
On 03/01/2010 09:04 PM, Barry Friedman wrote: > What version of Quagga are you running? > 0.99.15 > The error indicates that the sanity check for MP_REACH_NLRI is failing > in that the NLRI prefix length values add up to more than the > attribute length (this is the overflow indicated in the error > message). > > Can you post a tcpdump capture file of the BGP messages on the > offending session (use -s 0 to get full packet captures)? > I have send you an attachement in your personal mail. Greetings, Jan Hugo Prins
What foundry and what software rev? I think the XMRs need at least 3.6H before they can properly talk IPv6 BGP with quagga revs higher than 0.96.5, to avoid that NLRI bug we were experiencing. Jan Hugo Prins wrote: > On 03/01/2010 09:04 PM, Barry Friedman wrote: > >> What version of Quagga are you running? >> >> > > 0.99.15 > > >> The error indicates that the sanity check for MP_REACH_NLRI is failing >> in that the NLRI prefix length values add up to more than the >> attribute length (this is the overflow indicated in the error >> message). >> >> Can you post a tcpdump capture file of the BGP messages on the >> offending session (use -s 0 to get full packet captures)? >> >> > > I have send you an attachement in your personal mail. > > Greetings, > Jan Hugo Prins > > _______________________________________________(Continue reading)
Thanks I sent a unicast reply with the capture decode. It looks like a malformed bgp message from the Foundry to me with the mp_reach_nlri field ending at a non-zero prefix length and no prefix data. Regards, Barry On Tue, Mar 2, 2010 at 1:09 AM, Jan Hugo Prins <jhp@...> wrote: > On 03/01/2010 09:04 PM, Barry Friedman wrote: >> What version of Quagga are you running? >> > > 0.99.15 > >> The error indicates that the sanity check for MP_REACH_NLRI is failing >> in that the NLRI prefix length values add up to more than the >> attribute length (this is the overflow indicated in the error >> message). >> >> Can you post a tcpdump capture file of the BGP messages on the >> offending session (use -s 0 to get full packet captures)? >> > > I have send you an attachement in your personal mail. > > Greetings, > Jan Hugo Prins > >(Continue reading)
On 03/02/2010 07:40 PM, Barry Friedman wrote: > Thanks I sent a unicast reply with the capture decode. It looks like a > malformed bgp message from the Foundry to me with the mp_reach_nlri > field ending at a non-zero prefix length and no prefix data. > > Thanks for the clarifications and I will forward this information to my Transit profider. They allready told me that the version of their routers was to old and that they are currently in the process of replacing the complete routing core with new routers. Jan Hugo
Hi! What is a connected route in Quagga? My intuition tells me that the destination node is directly connected to a local interface (1 hop away). Is this correct? Also, I am not clear about the distinction between static/connected routes and kernel routes. Aren't static/connected routes automatically inserted into the kernel? If that is true, then doesn't "redistribute kernel" redistribute static and connected routes as well? Regards, Dragos
On 2010.03.04 08:20, Dragos Ilie wrote: > Hi! > > What is a connected route in Quagga? My intuition tells me that the > destination node is directly connected to a local interface (1 hop > away). Is this correct? Essentially, yes. A route will appear as connected even if it is on a virtual sub interface: C>* 208.70.111.36/30 is directly connected, em2.98 C>* 208.70.111.48/30 is directly connected, em5 > Also, I am not clear about the distinction between static/connected > routes and kernel routes. Aren't static/connected routes automatically > inserted into the kernel? If that is true, then doesn't "redistribute > kernel" redistribute static and connected routes as well? From what I can tell, a kernel route is a static route that has been assigned from within the Operating System space, outside of Quagga. All of my routes on my Quagga boxes are generated via the Quagga config files, so I had to test this for myself using a static route: os# route add 1.1.1.1/32 192.0.2.2 os# vtysh lanx-edge# sh ip route K>* 1.1.1.1/32 via 192.0.2.2, disc0(Continue reading)
RSS Feed30 | |
|---|---|
37 | |
50 | |
23 | |
18 | |
34 | |
59 | |
49 | |
20 | |
12 | |
19 | |
15 | |
35 | |
30 | |
70 | |
58 | |
61 | |
55 | |
45 | |
43 | |
58 | |
49 | |
32 | |
44 | |
54 | |
42 | |
97 | |
44 | |
34 | |
70 | |
67 | |
49 | |
103 | |
71 | |
58 | |
37 | |
65 | |
63 | |
55 | |
56 | |
43 | |
55 | |
61 | |
75 | |
23 | |
80 | |
136 | |
113 | |
168 | |
58 | |
104 | |
91 | |
83 | |
72 | |
75 | |
140 | |
95 | |
124 | |
44 | |
85 | |
48 | |
95 | |
56 | |
86 | |
81 | |
87 | |
105 | |
99 | |
123 | |
69 | |
151 | |
122 | |
154 | |
123 | |
111 | |
97 | |
111 | |
88 | |
103 | |
93 | |
118 | |
140 | |
196 | |
152 | |
180 | |
129 | |
124 | |
164 | |
177 | |
171 | |
272 | |
258 | |
277 | |
258 | |
117 | |
161 | |
239 | |
175 | |
322 | |
134 | |
312 | |
222 | |
229 | |
266 | |
166 | |
185 | |
173 | |
184 | |
246 | |
226 | |
127 | |
120 | |
147 | |
245 | |
199 | |
298 | |
143 | |
23 | |
1 | |
1 |
