Hi, Habib
After establishing the peering between the controllers, it immediately
crashed with this error;
Sent notification to ('20.0.0.1', '179') >>
BGPNotification(data='',error_code=6,error_subcode=7,len=21,type=3)
I think that BGP connection collision occurred in your topology.
If this always occurs, I guess your controller receives the Open message
with the same source and destination address.
Please confirm your BGP config and your topology is right.
Thanks,
Fujimoto
On 2017年10月03日 21:00, Habib Mostafaei wrote:
Hi Fujimoto,
I added two more rules to the flow tables according to your
suggestion. Now, the peering can be established by modifying the mac
address of sender in the switch in my scenario.
After establishing the peering between the controllers, it immediately
crashed with this error;
Sent notification to ('20.0.0.1', '179') >>
BGPNotification(data='',error_code=6,error_subcode=7,len=21,type=3)
I was wondering what reason can cause this message.
Thank you,
Habib
On 10/2/2017 2:48 AM, Fujimoto Satoshi wrote:
Hi, Habib
Normally, when the BGP speaker sends an Open message, the source port
number is something other than 179 (like port 55555).
So, according to your table, the Open message will successfully
arrive at its peer,
but the reply from it will not return because the flows for it is not
installed in your flow tables.
I think you need to add more two flows for reply messages, like:
cookie=0x0, duration=11.287s, table=0, n_packets=0, n_bytes=0,
idle_age=11, priority=120,tcp,in_port=2,*tp_**src*=179 actions=output:1
cookie=0x0, duration=7.775s, table=0, n_packets=0, n_bytes=0,
idle_age=7, priority=120,tcp,in_port=1,*tp_src*=179 actions=output:2
I've confirmed that peering successfully established by adding this
two flows .
Could you try it?
Thanks,
Fujimoto
On 2017年09月29日 18:44, Habib Mostafaei wrote:
Hi Fujimoto,
This is the flow table in one of the switches;
root@sw1:/# ovs-ofctl dump-flows sw1
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=91.782s, table=0, n_packets=4, n_bytes=296,
idle_age=6, priority=120,tcp,in_port=2,tp_dst=179 actions=output:1
cookie=0x0, duration=91.781s, table=0, n_packets=12, n_bytes=888,
idle_age=14, priority=120,tcp,in_port=1,tp_dst=179 actions=output:2
cookie=0x0, duration=91.783s, table=0, n_packets=4, n_bytes=168,
idle_age=24, priority=70,arp,in_port=2 actions=output:1
cookie=0x0, duration=91.782s, table=0, n_packets=4, n_bytes=168,
idle_age=24, priority=70,arp,in_port=1 actions=output:2
Apparently, in this case the BGP packets can traverse through the
network but the controllers cannot detect it. You can see the
packets are matched in the flow table.
I did further changes on the TCP rules and I removed the destination
port check from the rule and after this elimination surprisingly the
peering established.
Probably, this is due to tcp communications among controllers which
are not performed through port 179 to establish a BGP peering. Is it
right?
Best regards,
Habib
On 9/29/2017 3:54 AM, Fujimoto Satoshi wrote:
Hi, Habib
If you installed rules for ARP and BGP correctly, the peering
should be established.
Could you let me see the whole of flow table in your switches?
Thanks,
Fujimoto
On 2017年09月28日 00:39, Habib Mostafaei wrote:
Hi,
I have created two controllers as two BGP speakers like ryu
documentation (i.e., by using application.py and
bgp_sample_conf.py files).
I have two switches which are connected to controllers and the
switches are connected to each other as well.
I would like to create a BGP peering between two controllers. To
create the BGP session between controllers I have the rules to
handle the ARP traffic and after solving ARP problem, I have
another two rules on each switch in order to allow tcp packets
(i.e., dst_port=179 for BGP packets) to enter the controller and
exit from it. The rules are also matched but the peering does not
established.
I was wondering how can I solve this problem.
Thank you.
Habib
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
