• Thanks for making your code available! I’ve linked it from the POX manual.

  • It sounds like from peer1, you’re telnetting to 192.168.0.4/peer2, but… is probably reaching peer1 (itself). And from peer4, it seems like you can’t reach peer1.

    These results don’t make a lot of sense to me unless you have your peers/IPs mixed up, or something very unexpected is happening.

  • Offhand, the above looks right to me, so I have no simple explanation here.

    Is the code you’re trying exactly the code you posted above? I copy/pasted it into a new file and it doesn’t seem to have the issue.

    Also, does the forwarding/hub.py component that comes with POX work for you?

  • Are you running curl from the same machine you’re trying to telnet from?

    I suggest the following test:

    Get the latest POX dart.

    Run POX with
    ./pox.py log.level –DEBUG openflow web

    From the same machine, try:
    telnet localhost 6633

    It should connect.

    From the same machine, try:
    telnet localhost 8000

    It should connect.

    Now from the remote…[Read more]

  • Just to be sure: you were running POX at the time, right? You should run POX on your controller machine (“./pox.py log.level –DEBUG openflow” is a good place to start if you’re using POX dart), and then try “telnet 6633″ from the switch machine.

    If that doesn’t work, the problem would seem to be in the network configuration — the switch…[Read more]

  • From the machine that’s supposed to be running the switch, see if you can connect to the controller using telnet… telnet 6633

    If it connects, hit enter a bunch of times. POX will probably give you an error message about a bad OpenFlow version. If this all happens, then the problem is probably in the switch configuration.

    If that doesn’t…[Read more]

  • Why not just install them to use the right queues in the first place? Or if the queues are changing, have the controller track which entries should be there, and just reinstall them using the right queues, rather than installing them from the controller, reading them back into the controller from the switch, altering them, and writing them back.

  • You’re creating an ofp_flow_mod and setting msg to be a reference to it. You’re then throwing it away and making msg reference f which is an ofp_flow_stats. But ofp_flow_stats isn’t an OpenFlow command/message. You don’t want to send it.

    Additionally, it’s not clear what you’re really trying to do here. You’re only sending one thing, which…[Read more]

  • 1) Yes, it’s possible to set two controllers for a single Mininet topology. In general, Mininet just uses Open vSwitch, so you can always simply run ovs-vsctl to configure the switches however you want — including using different controllers. I think you can actually do it with the Mininet Python API too, but don’t remember how off the top of…[Read more]

  • Murphy started the topic Read before posting here! in the forum NOX 3 months, 1 week ago

    Just a note that the best way to get support for current versions of NOX is through the issue tracker on the github repository. You’re welcome to post here, you just might wait a long time for a reply. :)

    (NOX-Classic and POX posts are still answered here relatively quickly, though nox-dev and pox-dev mailing lists are probably faster.)

  • The issue is with OpenFlow 1.0. It doesn’t do matches based on IPv6 — it’s simply not part of the specification. As far as I can figure, the flows being installed will just be matching ethernet addresses and the IPv6 ethertype — not the IP addresses. This seems very likely to be very problematic.

    Possible solutions are:
    1) Use something…[Read more]

  • Ah, that’d do it.

    First, the updated DNS parser should be in the POX dart branch. You’d need to ugprade. dns_spy hasn’t been updated to handle IPv6, though. You’d have to modify it to track AAAA records.

    Also, you can’t base such a solution on l2_learning while using IPv6. l2_learning only uses OpenFlow 1.0, which has no IPv6 support, so the…[Read more]

  • I hadn’t tested it at all. I’ve tested and made a minor fix now. It works for me. Try it again?

  • What does this do?
    ./pox.py forwarding.l2_learning no_facebook proto.dns_spy

    # ext/no_facebook.py

    from pox.core import core
    import pox.forwarding.l2_learning as l2l

    class BlockingSwitch (l2l.LearningSwitch):
    def _handle_PacketIn (self, event):
    ipp = event.parsed.find(‘ipv4′)
    if ipp:
    for name in…[Read more]

  • Try simplifying things. Don’t use a browser; just use telnet or something.

    Deactivate your blocking code. Try connecting to a server by its IP address and sending a GET request by hand. It should work.

    Activate your blocking code, but hardcode a block for a specific IP address. Try connecting with telnet to that IP address. It should trip…[Read more]

  • Are you sure you haven’t installed a table entry that matches the right packets?

    Are you sure the packet you’re looking at is the correct one? Check that it’s TCP with a destination of port 80, for example. Check the TCP payload. Is it an HTTP request?

    And what *is* the IP you’re looking at? Do a reverse lookup or something to figure out…[Read more]

  • There are some complicating factors here.

    First, your hosts may be caching the DNS replies. So when you restart POX, you may be losing the ones the host has already seen and cached. The best I’ve done to combat this in the past is to have POX save its mappings to a file (with a timestamp) when it closes and reload them when it starts…[Read more]

  • Adding a WAN port and a LAN port, running l2_learning, and DHCPing from a machine connected to the LAN port should work. You could simplify this even more by running forwarding.hub –proactive or whatever that is. If this doesn’t work, I think something strange is happening. I’d run Wireshark or something on the interfaces and see what’s…[Read more]

  • 1. As far as using a second OVS just to assign it an IP… okay. Though this isn’t especially necessary. If you have a single OVS, add the WAN port to it, have flow rules to allow the local port to communicate with the WAN port, and then run a DHCP client on the local port, it’ll work. Maybe your way is slightly easier.

    2. Yeah. So when…[Read more]

  • 1) Why have two OVS instances? Why not just one? And why is connecting to the internet any different than connecting to another host? You might have good answers to these questions, but I don’t think you’ve told me what they are.

    2) I am suggesting that you *modify* the proxy to do rate limiting or whatever you want. What you’re proposing…[Read more]

  • Load More